NIP-71: NUDs #1214
NIP-71: NUDs #1214
Conversation
|
I think it's a good idea. I wish relays could indicate support. |
|
I am not sure if we need to change the name from NIP to NUD (to me they are the same thing), but great idea. We could migrate all NIPs to NUDs with a random key out there. Then we just need a way for Clients to declare compliance to each one and a website to rank them by compliance and boom, no need for this repo anymore. |
|
I like NUDs because NIPs have numerical IDs, eg |
|
Plus my wife will not roll her eyes every time I say NUDs. |
That's a stronger point than the original. |
You know this is going to be pronounced "nudes" right? The joke can't not be made, especially alongside "nips". |
|
SNED NUDS |
At this point, I think @fiatjaf does these things on purpose. It's all about marketing. -- Says the owner of "SheetStr" |
|
Alright, you ruined it. Thanks. 😃 |
100% |
|
i want to see the abolition of this repository in favor of a wikifreedia subject/entry and associated tree of linked articles (with human readable labels instead of stupid numbers) |
|
ACK!
It may be worth testing the idea of decentralizing Does wikifreedia have article comments? If not, meanwhile this repo could continue being used for new NUD discussions. |
|
The NIPs repo is one of the main things holding Nostr together. To abolish it would be brave but retarded. How about we see how well this new thing works first. Has anybody published a NUD yet? What is the best client for doing so? |
Yeah, seconded. We need the tools to publish and read nostr-native NIPs before it can become a useful source of information. Maybe wikifreedia can be co-opted to support them. But that has to be built first. |
|
I may be wrong but I think NUDs won't become a thing if this repo keeps accepting new NIPs. The current repo maintainers may curate NUDs by writing a "NUD" article with a shared key. |
|
I'm not fond of the kind-specific d-tag parsing. |
NIP numbers are scarce and they're about to end. |
Alright the 01 to 99 range I suppose. I guess niche specs such as #1094 don't deserve a rare NIP slot but are free to become NUDs. |
|
i like it, now we just need to get the wikifreedia polished up a bit more so this kind of thing can become normal i did a lot of work making a more human-readable way of mapping out the structure of the protocol, and it is a lot easier to navigate and learn i think the key thing to understand about this is that NIPs tend to be too narrow, with the exception of the first one, that you end up with this giant index in your memory "now what is 42? what is 59? what is 3?" instead of a mnemonic word or phrase that makes it patently obvious what it relates to, that can be stacked under subections like how i did with envelope types and the top level envelope parsing flow logic in my nostr library ( https://github.com/Hubmakerlabs/replicatr/pkg/nostr ) |
| ["d", "nud:ordinals-comments"] | ||
| ["title", "NUD: Ordinals Comments"] | ||
| ], | ||
| "content": "# NUD: Ordinals Comments\n\nThis NUD defines how to comment on Bitcoin Ordinals using Nostr events.\n\nEvents should be of kind 10773 and include a tag in the format [\"o\", \"1928604426675219\"] in which 1928604426675219 is the satoshi number given by `ord`. Aside from that these events follow the rules of kind 1.", |
There was a problem hiding this comment.
Like wikipedia that has a "Beer" article instead of "Beers"
| ["d", "nud:ordinals-comments"] | |
| ["title", "NUD: Ordinals Comments"] | |
| ], | |
| "content": "# NUD: Ordinals Comments\n\nThis NUD defines how to comment on Bitcoin Ordinals using Nostr events.\n\nEvents should be of kind 10773 and include a tag in the format [\"o\", \"1928604426675219\"] in which 1928604426675219 is the satoshi number given by `ord`. Aside from that these events follow the rules of kind 1.", | |
| ["d", "nud:ordinal-comment"] | |
| ["title", "NUD: Ordinal Comment"] | |
| ], | |
| "content": "# NUD: Ordinal Comment\n\nThis NUD defines how to comment on Bitcoin Ordinals using Nostr events.\n\nEvents should be of kind 10773 and include a tag in the format [\"o\", \"1928604426675219\"] in which 1928604426675219 is the satoshi number given by `ord`. Aside from that these events follow the rules of kind 1.", |
There was a problem hiding this comment.
I don't know, doesn't Wikipedia have any articles about plural things?
There was a problem hiding this comment.
What I said isn't strictly right. If it's a movie name like "Gremlins", the article name won't be in the singular. So yeah if you say the NUD name is Ordinals Comments, it won't be wrong.
Though imo trying to name things in singular could help preventing articles about the same thing with different d tags like ordinals-comments, ordinals-comment, ordinal-comments, ordinal-comment.
Another suggestion to help lowering d tag variation: while the title could keep being "NUD: Ordinal Comment", the d tag could have a convention that one or more non-word characters become a dash, so ["d", "nud-ordinal-comment"].
There was a problem hiding this comment.
This was unexpected but I guess the article from the screenshot isn't related to the movie. https://en.wikipedia.org/wiki/Gremlin_(disambiguation)
There was a problem hiding this comment.
I'm sorry, I was going to write that it was a joke, but I forgot to do that.
|
We can't fetch only NUDs, right? For example, do we need |
You can fetch by |
Can you? What is this |
Probably the |
|
|
||
| NUDs are defined as [NIP-54](54.md) **kind:30818** events. | ||
|
|
||
| They should have a `d` tag starting with `"nud:"` followed by a succinct and identifiable name so they can be referred to in other contexts. |
There was a problem hiding this comment.
I think this is a mistake. Having drafted a nud, I find myself at a loss of how to refer to it. NUD: custom feeds is unwieldy and potentially ambiguous. What if the d tag was a random 256-bit hex number? We could then refer to NUDs by the first n digits of the hex, for example NUD f38. This gives us 4096 3-digit short hand identifiers, which of course could be further disambiguated by including more digits. This would also accommodate situations where the name changes, which happens pretty commonly with NIPs.
There was a problem hiding this comment.
This is what FEPs do, but I don't know where the hex comes from. https://codeberg.org/fediverse/fep
There was a problem hiding this comment.
However, don't wiki's already use plain English d-tags?
There was a problem hiding this comment.
Yes, but the purpose of a wiki is to define a term. The only term involved in a NUD is the NUD itself, since the articulation of the purpose of the NUD may change. This is the same thing going on as with kind numbers and NIP numbers, which is a genius aspect of the protocol.
There was a problem hiding this comment.
@alexgleason Apparently it's the hash of the title, which does not solve the problem. Why not just pick a random 4 digit hex string? I guess 65536 are enough NUDs no? Also by restricting it to be outside the 1-99 range, we could keep calling them NIPs (I'm also with @vitorpamplona and @staab on this).
There was a problem hiding this comment.
For context, wikipedia also deals with name changes like https://en.wikipedia.org/wiki/Internet_celebrity that people want to change to https://en.wikipedia.org/wiki/Influencer (for now, Influencer redirects to Internet_celebrity).
If you ask me, I'd change d-tag from nud:orange-cars to orange-car and point the article to the nud article using something like these r tags. See, what makes it a NUD, is the reference to the NUD article.
Heheh everyone wants to do it differently
There was a problem hiding this comment.
NIPs get renamed all the time, it would be nice to be able to rename a NUD but keep references intact.
What @arthurfranca said.
You'll also have collisions if there end up being two distinct NUDs that are named the same thing (e.g. "NUD: Read Receipt").
That's why NUDs are tied to a unique owner. So we'll have Bob's Read Receipt and Carol's Read Receipt.
That would make it impossible to fork both NUDs under the same pubkey.
Yes, but it makes no sense to fork your own NUD. You can just edit it, or make a new thing with a slightly different name, be creative.
Hence my suggestion to use more randomness
Someone can just pretend to be generating random numbers and collide with all your NUDs on purpose, now what?
There was a problem hiding this comment.
Yes, but it makes no sense to fork your own NUD.
There might be a collision between two NUDs belonging to other people that you want to fork.
Someone can just pretend to be generating random numbers and collide with all your NUDs on purpose, now what?
Replaceable events were a mistake, we should just use e tags and build a tree.
There was a problem hiding this comment.
You can't build a tree, you can only plant a tree.
There was a problem hiding this comment.
You can't build a tree, you can only plant a tree.
you grow trees by attaching limbs to them at nodes, which you indirectly do by watering real trees, but data structure trees you grow by attaching limbs at nodes
Agree, it would get messy and confusing to have a two tier system. Just call it an early stage NIP. Right now getting a NIP through the NIP approval process is too heavy a lift for most developers. Let NIPs evolve like FEPs do. The whole point of Nostr was supposed to be an outlet for developers to experiment, tinker and express their creativity. It's not that at all, right now. The solution is to have NIPs go through stages of maturity, which is in the spirit of bottom-up open source development. |
Permissionless NIPs.
https://github.com/nostr-protocol/nips/blob/nuds/71.md
@pablof7z @mleku @jb55 @staab @vitorpamplona @Semisol @arthurfranca @mikedilger