I think the FEP numbering/naming scheme is better, and could be adopted for NIPs:

Codeberg.org

fep

Fediverse Enhancement Proposals

In short: don't use numbers, use the first few characters of a hash of the (initial) title. Much better to have an agreed-upon scheme than random/custom IDs.

The issue also leaks into kind numbers which would be better as self describing text.

Here’s a question: how should we go about transferring existing NIPs from the old system to the new? Would we like original authors to do it, since they’re replaceable events? Which just now makes me wonder: when we like or dislike a NIP, should the kind 7 event have both an a tag and an e tag? And leave it up to users to decide whether to pay attention to one or the other or both?

NIP numbers are live, what is change the discussioni Is more open. Lol "In an environment where ANY npub can propose a new standard".

- E tag is not appropriate for addressable events. - Kind 7 is not appropriate for NIPs published “on the web” somewhere (like a GitHub repo). - A tag is a nice standard … so let’s add this to the kind 17 “reply on external content”. Hmm … looks exactly like the change I proposed. 🤔

How should “official” nip numbers be assigned… without a central authority?

not appropriate? If Alice writes some piece of content that is a parameterized replaceable event, Bob likes the content, and then Alice updates it, I may want to know whether Bob liked the current version or a previous version. Suppose Alice turns out to be a bad actor. She vibe coded a good NIP, got some likes, then swapped it out for spam. If Bob endorses spam I’ll be inclined to think maybe he’s a bad actor too, but how do I know whether he liked the spammy version or a previous (non spammy) version? You’ll point out that the old event will be discarded, so we won’t be able to find the old version, so we won’t know what he liked. If so, we’ll at least know whether Bob liked the current version or some previous (no longer existing) version, information which may be useful even if it doesn’t tell the whole story. And there’s also the possibility that older versions of parameterized content get stored by design for some particular set of use cases, even if that’s not the usual practice.

And our goal is to stop publishing NIPs on a GitHub repo. I know you want backwards compatibility, and your changes to kind 17 allow that, which is fine. There’s going to end up being multiple ways for people to express their thoughts on custom NIPs. You have kind 17, maybe someone does kind 7, we’re going to need one or more methods for people to express more nuanced opinions than a simple binary up or down. GrapeRank can take them all in.

Yes. “Versioned specific” reactions would be nice … but I think (at best) this can only be accomplished on a “kind by kind” basis. If a NIP that specifies an addressable kind ALSO specifies that relays MUST NOT discard older versions of these events (which “as a convention” NIP-01 currently permits) then MAYBE relays will comply. But, also as it is, we currently have MANY ways to propose a NIP (two event kinds and counting, let alone “elsewhere” on the web). I don’t imagine that a single “NIP NIP” will ever be a standard.

You’re right. I did point out that old versions of addressable events might be discarded. And if so (like it’s not available anywhere) then an “e tagged reaction to an unspecified event will be orphaned and not show up anywhere … let alone be associated with “some older version” of a NIP spec. I’m not sure this can work in a reliable manner. UX is important. Sure “leave it up to users to decide” is always an answer, but not always a good answer.

By two event kinds you mean as a wiki entry or using @Alex Gleason ‘s NIP NIP. For now, the NIP NIP has advantages over the wiki entry method, like a specialized way to list all event kinds used by the NIP. Are the NIPs at the top of NostrHub pulled directly from GitHub or are they wiki events?

Backwards compatibility is not “what I want”. I hate managing legacy code. But it is necessary in an open and evolving standard. The NIP 73 update I proposed does not restrict, but opens up new possibilities. As far as reactions go, a single kind 17 (or 7) reaction can be EITHER a binary or can be an any emoji. This allows for having BOTH as options (two buttons) in a single UX. Great. NIP-73 is ALSO a way for comments to reference “external content”. Yes. Nostr can comment on anything … including arbitrary NIPs. The NIP-73 update simply adds a standard for ANY event to reference ANY arbitrary NIP. Imagine someone makes an approval flow NIP … for any kind. Instantly, an approval flow can be applied to any NIP proposal ANYWHERE simply by referencing. Imagine three different takes on this idea. Everyone can use this standard to reference “a NIP” and everybody wins.

If a reaction to an addressable event points to an e tag and that’s it, then I agree, that doesn’t make sense. If it points to the a tag as is the norm, then we avoid that problem of orphaned reactions. If it points to an a tag *and* an e tag, then we have an option that doesn’t exist if we use the a tag alone: Alice might choose to interpret a reaction to an outdated version as equivalent to a reaction to the current version; Bob may choose to interpret them as not equivalent. The first interpretation errs on the side of being too lax, the second of being too rigorous. Under standard practice, the first interpretation is the only choice.

They are scraped from GitHub. Would be nice to include the Wiki style also … Get this. 👀 By simply having a standard for referencing NIPs across arbitrary content kinds, then … Wait for it … ANY time ANY event is reference using this standard THEN IMMEDIATELY it can be pulled into NostrHub and displayed according to the users WoT algo settings (for interacting with NIP referenced content). 🫳🏼🎤

Ok. I’ll meet you half way. Carrots over sticks. Using a standardized way to reference NIPs (via NIP 73) assures that “your reaction” and “your comment” (ect…) will be available for a wider audience of “nip reviewers” (and robots) … cause the reference ITSELF is tagged with “nip”. It’s the easiest way! As it stands, NIP 73 style “external references” are only available when publishing reactions as kind 17 events. Go ahead. Put an e tag on it. I’ll even add this as a “suggestion” in the proposed spec for referencing NIPs. Everybody wins. 🔥

This will be tricky. 👆🏼 What a strange oversight for @fiatjaf (and everyone else … for years) to make. I can only assume that Nostr was never intended to be an “open protocol” … despite its being billed as such? 👀

I want to take a step back and consider a bigger question. It’s related and I don’t know the answer. Currently, a wiki entry or nip nip can be edited by the event author. So how can we enable the community to edit an existing NIP? One way would be something like git versioning, where your WoT decides what gets merged, but idk if that can work and even if it can, we’re far from ready to implement it. So here’s another idea. Take NIP-73 as an example. Take the existing version and express it using the nip nip. But we don’t copy the whole thing verbatim. Instead, we replace the table of Supported ID Types with a Decentralized List, one for each type. Each list item adds a row to the table and maybe also includes a corresponding explanation and example. So when it comes time for you to propose support for NIPs, you simply add another item to the list of supported types. The complexity would be we’d need a script to ingest the curated list and spit out a markdown file. We’d have to figure out how to make that work. And we will need to implement vanilla list curation first.

This is revolutionary! Take a look at Trusted assertions NIP and do the same for … all the different kinds for which one could request “trusted counts” and “trusted events”. 🤯

It's just documentation for what you've implemented and two or more developers agree.

I like the idea of “numbers alone” to identify NIPs. It’s clean. But where should these “documentations” reside to avoid conflict?

I mean, I think it's plenty open, people are free to do whatever they want without permission. From my experience it’s the event schema that has it's constraints in the wrong place resulting in unintended consequences for developers. If kind was text, content was json, and tags were an array of strings then you would have payloads that were self describing, indexable, and could be validated using json schema. Instead everything relies on NIPS and the bastardization of tag arrays which further cascades into relay complexity.

It's just a link to the NIPs repo, wiki or nostrhub