New spec in NIP 73 for referencing arbitrary NIP specifications

[manimejia]

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.

[luigi1256]

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

[staab]

This makes sense to me. Any implementations out there?

[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.

[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

[alejandro-runner]

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]

[staab]

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

[alejandro-runner]

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

[manimejia]

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.

[luigi1256]

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

[manimejia]

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

What doesn't make sense? Please elaborate.

[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

[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

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.

[luigi1256]

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