8000 Software applications events #1336
Conversation
|
hum.. isn't it possible to merge this with kind 31990? Kind 31990 is insufficiently defined on NIP-89 but most apps already have their entry due to https://nostrapp.link/ We could just add the additional tags needed by zap.store to that definition. |
|
NIP-89 is for apps that handle nostr events, isn't it? It's not at all what I'm defining here. In fact, 90%+ of the apps on zap.store do not handle nostr events. It feels very contrived to try to fit this simple definition on the complexity of NIP-89. |
|
Yes, that's what NIP-89 needed it for, but those app definitions don't need to exist to solely respond to Nostr events. Actually, I believe most apps don't event that "response" field setup correctly. Right now they are just there to receive reviews. DVMs also reuse the same kind to define their applications. Reusing the kind doesnt mean you have to implement NIP-89 to support yours. |
|
Are you saying I can keep my schema as-is and change 32267 to 31990? In such case I would have to change Or do you mean I should stuff all my metadata into a stringified metadata and put it in |
|
Hum.. yeah I missed the @pablof7z, do you see a possibility of merging those two? Or are we going to have to define our apps in two places? |
|
Do you know what is the rationale for putting stringified JSON in |
Dumb decisions. They probably just copied how kind 0 works :( |
|
I also need data to be in tags for full text indexing purpose. 31990 seems built for something else which is fine: all apps can sign a 32267 and if they want nostr interop also sign a 31990. I will keep using kind 32267 unless there's a better alternative to describe an application |
|
Love to see this and look forward to adding releases to nip34 clients. Instead of referencing a nip34 announcement event in The release event:
From a style point of view: I see most nips describe events using jsonc rather than a table of tags, which is easier to read. Is this now the standard? lastly, the app event could support the maintainers tag like nip34 announcements This means clients could optionally interpret app events by the pubkeys listed with identical |
Looking forward too!
Sounds great
Sure, I can do that
We're probably talking about different things. The release set is a NIP-51 replaceable event (kind 30063) that is simply a pointer to a set of software releases (binaries). Trust attestations should be applied to NIP-94 (kind 1063) events because they carry a checksum of the binaries. Moreover, if a developer made a mistake in the file collection or a typo in the release notes, it's useful that they can update the event.
Sure - in kind 1063s
I don't think we have a standard for whether to include tables or not. Other NIPs use bullet points.
This is currently done via attribution |
Sorry to go off topic, but what is so bad about putting stringified json in content? Why are tags better? |
|
@bezysoftware I would ask what is good about putting stringified JSON in |
|
I rewrote good part of this NIP. As suggested by @NielLiesmons application description should be a wiki article. With that, developers also get access to better tools for updating information. Presented the tags in Lastly, made a clarification on NIP-89. Events on relay.zap.store do not yet conform to this spec but will be migrated shortly. |
Co-authored-by: DanConwayDev <114834599+DanConwayDev@users.noreply.github.com>
d478cd7 to
bc53923
Compare
|
Updated the NIP to reflect the usage on Zapstore. Since it has been used for months now and it's pretty stable, can we get this merged? |
|
Is this in use by anyone other than zap.store? |
|
Normally NIPs are merged once there's some compatibility that needs to be ensured. It's good to have it documented in a draft, but update here when there are other apps using the standard |
|
This data structure will probably end up in NDK and used in Yana and probably in a relay-based community started by @NielLiesmons |
|
I am putting in on Amethyst right now. We can wait for the next release if we don't have any other client using this yet. |
|
I intend to with gitworkshop and ngit but haven't got around to it yet.
…-------- Original Message --------
On 22/01/2025 15:05, Vitor Pamplona wrote:
I am putting in on Amethyst right now. We can wait for the next release if we don't have any other client using this yet.
—
Reply to this email directly, [view it on GitHub](#1336 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3MDZJ5MAFJ5P3A7QHHGAUL2L6XT5AVCNFSM6AAAAABKCZBYVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGQ4TGMZQGE).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
That's good enough for me. Are you implementing as is? |
|
Just to display right now. I am not sure it makes sense to create it yet. |
|
can we publish cli applications using this nip? so a linux package manager can use it for example? |
|
@kehiy Absolutely, I am using it already for the Zapstore package manager (works on MacOS and Linux): https://zapstore.dev/docs/cli/manage/ -- it will get way more packages in the coming months |
|
There is no reason for the release sets to be replaceable, can that be changed now? |
|
Built a cli tool in rust to do publishing, no dependencies, no shell commands, only works for |
The first question would be what do we gain by changing it |
Cant be rugged, small benefit, there is no actual reason for it to be replaceable |
|
You did not ask, but I will explain for context. It started out as a set of artifacts, just like any other set and that is why it's replaceable. Developers sometimes make typos in release notes or want to add an artifact for another operating system. We discussed it with fiatjaf and others over a year ago and we agreed on it. It has been working well in production for about a year now. Would making it a regular event be more "correct"? Maybe. Not worth changing it in my opinion. |
|
Break things while you can. If there is no need for a replaceable event, let's get rid of it and clean up the spec. Also, does |
|
I don't have the energy to discuss this. Feel free to come up with something |
I keep events of kind 30063 around for every version. I only use the latest one in the UI (for now). Yes the d-tag is used for identifier and version ( I recall asking developers to use I know what will happen if we make this a regular event: they will end up asking me to delete the bad event from the relay so they don't have to bump and re-release |
|
Can you add more guidance to the |
Actually I think it's there simply for convenience because |
|
It would be nice to have a common way of doing. I could imagine switching back one version and having to "search" for what each store/publisher is using as dtag. |
|
Also missing some documentation about the NIP-94, i published events as per this PR but it doesnt open in Zapstore app, What is |
Should be |
|
Pictures and Videos were on NIP-94 and recently moved away from it into their own event kinds. That seems to have been a good move. The same can happen here if software applications need their own NIP-94-like kind where not only specialized tags (like |
|
+1 relay implementation: |
Makes sense. Should we have one NIP for all software package related things? How about adding those things here? |
|
Updating the NIP with:
And overall more clarity in the description. This is work in progress, I plan to finalize it over the next few weeks. |
Rendered
This event represents an application as used in Zapstore. It is actively being used in a production setting for many months already.
This relates to NIP-51 (kind 30063), those artifact sets point to their application (this event, kind 32267).
Feedback welcome