nips icon indicating copy to clipboard operation
nips copied to clipboard

New spec in NIP 73 for referencing arbitrary NIP specifications

Open manimejia opened this issue 6 months ago • 12 comments

Allows 'all of nostr' to reference, comment, and react on any published NIP spec in a standardized manner, regardless of which repo or nostr event kind they are posted to.

manimejia avatar Oct 31 '25 02:10 manimejia

You can probably change njump with wikistr.com/dtag*pubkey/

luigi1256 avatar Oct 31 '25 09:10 luigi1256

This makes sense to me. Any implementations out there?

I'm just wrapping up PR to implement WoT powered ranking of NIPs on nostrhub.io. @alexgleason should have this in hand by EOD today.

manimejia avatar Oct 31 '25 17:10 manimejia

This makes sense to me. Any implementations out there?

I'm just wrapping up PR to implement WoT powered ranking of NIPs on nostrhub.io. @alexgleason should have this in hand by EOD today.

pr submitted for NostrHub

manimejia avatar Oct 31 '25 19:10 manimejia

I want to incorporate this to NIP-RP and to the Synvya client so that profiles that support NIP-RP can signal such support using an i tag.

I do need help with the k tag. What happens when the profile has multiple i tags? How is the k tag mapped to the right i tag? Are we only supposed to have a single i tag? That seems restrictive.

I like using

["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]

without k tag since the value already tells me it's an isbn and so I see more intuitive something like

["i", "nip:101", https://github.com/nostr-protocol/nips/blob/master/101.md]

alejandro-runner avatar Nov 15 '25 01:11 alejandro-runner

Just include multiple k tags. They're for indexing, not for describing the tag values which should be unambiguous based on prefix.

staab avatar Nov 17 '25 18:11 staab

Just include multiple k tags. They're for indexing, not for describing the tag values which should be unambiguous based on prefix.

Ok. Implemented in Synvya as suggested

alejandro-runner avatar Nov 17 '25 22:11 alejandro-runner

I've updated the NIP referencing spec to allow for standardization (based on a tag spec) when referencing proposals from ANY external repository. Once this is approved and in use, variations of this a tag based standard can THEN be used in URLs and other cases where standardized referencing of NIPS is needed ... and we MIGHT be able to move beyond number based identifiers that are ONLY applicable within the GitHub.com/nostr-protocol repo.

manimejia avatar Dec 02 '25 01:12 manimejia

I think this proposal doesn't make much sense to add it to nip-73?

luigi1256 avatar Dec 03 '25 07:12 luigi1256

I think this proposal doesn't make much sense to add it to nip-73?

What doesn't make sense? Please elaborate.

manimejia avatar Dec 03 '25 13:12 manimejia

nip-73 is External Content ID, I don't think nips fall into this category, but you can use the same format in another nip

luigi1256 avatar Dec 03 '25 13:12 luigi1256

nip-73 is External Content ID, I don't think nips fall into this category, but you can use the same format in another nip

By definition, this very repository on GitHub is "External Content". While it (hopefully) will not be the canonical source of "official" NIPs in the near future, it is ALSO true that many different event kinds have been used to publish NIPs proposals on Nostr. On top of this, I've also seen NIPs proposed on OTHER repositories.

So yea ... how should we review and talk about all of these NIP proposals in a unified manner?

Happy to make a NEW NIP for this. But honestly, the i and k tag format proposed by this NIP work just fine.

manimejia avatar Dec 03 '25 13:12 manimejia

I'd just keep this version then ["i", "github.com:nostr-protocol/nips:25", "https://github.com/nostr-protocol/nips/blob/master/25.md"], ["k", "nip"] But if you want to refer to something other than a pull, or an issue, what do you do? or if I wanted to comment on a bud or a nut or a bip

luigi1256 avatar Dec 04 '25 10:12 luigi1256