nips
nips copied to clipboard
nostr-protocol
Software applications event
This event represents an application as used in zap.store. 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
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 content which will break other NIP-89 clients.
Or do you mean I should stuff all my metadata into a stringified metadata and put it in content?
Hum.. yeah I missed the content discrepancy.
@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 content (unless it has to be encrypted)? I've noticed the pattern in several places
Do you know what is the rationale for putting stringified JSON in content
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 repository tag it should be referenced with an a tag so it will be indexed by relays. clients should look for an a tag with 30617 kind if repository is omitted.
The release event:
- should be moved into this nip from the example section of nip51.
- should be immutable and not a replaceable event. then trust attestations could be placed on the event eg. validation that the checksums of a reproducible build match.
- should include an optional
["commit-id","<SHA1-commit-id-used-to-build-release>"]tag
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 d tags as referring to the same app. ["maintainers", "<other-recognized-maintainer>", ...]
Love to see this and look forward to adding releases to nip34 clients.
Looking forward too!
Instead of referencing a nip34 announcement event in
repositorytag it should be referenced with anatag so it will be indexed by relays. clients should look for an a tag with30617kind if repository is omitted.
Sounds great
The release event:
1. should be moved into this nip from the example section of nip51.
Sure, I can do that
2. should be immutable and not a replaceable event. then trust attestations could be placed on the event eg. validation that the checksums of a reproducible build match.
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.
3. should include an optional `["commit-id","<SHA1-commit-id-used-to-build-release>"]` tag
Sure - in kind 1063s
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?
I don't think we have a standard for whether to include tables or not. Other NIPs use bullet points.
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
dtags as referring to the same app.["maintainers", "<other-recognized-maintainer>", ...]
This is currently done via attribution p/zap tags. I think a better idea is to include maintainers in releases (not apps).
Do you know what is the rationale for putting stringified JSON in content
Dumb decisions. They probably just copied how kind 0 works :(
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 content. It makes no sense to encode JSON inside JSON for no gain (unless it needs to be encrypted) since values of that object are strings anyway. Tags can be indexed.
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 jsonc example format as suggested by @DanConwayDev
Lastly, made a clarification on NIP-89.
Events on relay.zap.store do not yet conform to this spec but will be migrated shortly.
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?
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, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I am putting in on Amethyst right now.
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 APK atm: https://git.v0l.io/Kieran/nap
There is no reason for the release sets to be replaceable, can that be changed now?
The first question would be what do we gain by changing it
There is no reason for the release sets to be replaceable, can that be changed now?
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