Make NIP-51 useful again

[fiatjaf]

https://github.com/nostr-protocol/nips/blob/save-nip-51/51.md

This NIP was a mess and wasn't being followed and there were many wild standards not documented. We should try to agree and actually follow some standards.

Also I've simplified the format to display some clearly defined simple tables so it's easier for people to add more stuff here.

We should stick to the 1xxxx range going forward for lists with standard meaning for which users are only expected to have one, 30001 for random lists and new 3xxxx lists for lists with standard meaning for which users are expected to have more than one.

---

Update:

This actually turned out to be a big movement involving tons of client developers in rehabilitating NIP-51, writing down old standards, creating new ones and cleaning up some mess from the past.

[mattn]

Sounds good to me.

[erskingardner]

This makes me sad. I know it's super common so we should document it but this feels very superfluous given we have 10000 mute lists.

[fiatjaf]

OK, I just learned that Snort used kind 30000/"mute" but has now changed to kind 10000, so tides are in our favor. I changed the NIP and let's try to get this right this time.

[mostafa-khaldi]

@fiatjaf We're gonna close this PR due to the new kind:30004 and we're gonna comply with its new standards, please confirm the new changes so we can close this PR

[fiatjaf]

Who is using kind 30000 with d set to "mute"? Can we work on a standardization plan here to move everybody to kind 10000? I know zap.stream, snort.social, coracle.social and nostrudel.ninja are using kind 10000.

[fiatjaf]

It would also be great if people could agree to move from kind 30001 with d tags "pin", "bookmark" and "communities" to dedicated kinds 10001, 10003 and 10004 respectively -- but I won't push for that. What apps are using these lists, in any case?

[vitorpamplona]

Looks good. If this gets sufficient support, I will switch Amethyst from using kind 30000's with d="mute" for mute lists to the 10000.

[staab]

It would also be great if people could agree to move from kind 30001 with d tags "pin", "bookmark" and "communities" to dedicated kinds 10001, 10003 and 10004 respectively -- but I won't push for that.

I will, I think it's important.

[jb55]

On Wed, Nov 15, 2023 at 05:38:29AM -0800, Vitor Pamplona wrote: Looks good. If this gets approval, I will switch Amethyst from using kind 30000's with d="mute" for mute lists to the 10000.

sure I will do the same.

[jb55]

It would also be great if people could agree to move from kind 30001 with d tags "pin", "bookmark" and "communities" to dedicated kinds 10001, 10003 and 10004 respectively -- but I won't push for that.

I will, I think it's important.

curious as to why? I haven't followed these discussions. @staab

[staab]

@jb55 see my explanation in this comment.

Since early on, user-defined lists in Coracle have been polluted with client-generated lists from other clients which don't make sense as user-generated lists (like "communities"). This is confusing to users because they never made those lists, and since clients can use any d tag they feel like, there's no way to really keep those things from showing up where they shouldn't.

[jb55]

@staab not sure what you mean, do you query 30000 without a #d tag?

[mikedilger]

Gossip has implemented categorized people list at 30000 with user-chosen 'd' tags. But the UI still hasn't exposed this implementation so nobody is using it yet, meaning we could still change things.

The only list that is widely used in gossip is the Mute list 10000.

[frnandu]

I'm now trying to use private relay set, kind 30002.
And since these are parameterized replaceable events, do I understand correctly that the d tag must be NOT PRIVATE in order for the replace ability to work?
First I assumed that d name of the set would also be encrypted in the content, and thus private, but now I'm not so sure anymore.
Or actually for the replace-ability to work it's needed an a tag according to NIP01 (deprecated NIP-33) ???

[vitorpamplona]

The only d-tag that matters is the public one. You can add one to private tag, but no relay will see it.

Lists can have parts that are public and parts that are private at the same time. It's the same list (same public d-tag)

[mbrat1]

All Primal clients already use kind 10000 for mute lists. We don't currently support pin, bookmark or communities lists, but once we do, we will go with the new 1000x kinds.

[monlovesmango]

Maybe too cryptic, but the contacts list is also a list. It would be nice to have private contacts as well. On face value this looks like a good match. It accommodates pure followers lists, but also tags, or other things and you can even have names contact lists.

@mutatrum the "follows sets" can accommodate private contact lists. Is this what you were looking for?

[gzuuus]

Sorry, @gzuuus, I didn't mean to tag you in a bad way, it was mostly a joke. I think everybody was using 30001 lists in a quite ad-hoc way and that we didn't know better -- but I hope we are agreeing on something.

No drama :) I like the proposal. ACK
However, in this effort to tidy up this nip I think it is worth mentioning some use cases that are not covered here and that are used in other clients, for example:

• Kind33888 and 33889 for boards and pins in pinstr
• Kind37777 for user cards in zap.stream

What should we do with these examples?

[fiatjaf]

However, in this effort to tidy up this nip I think it is worth mentioning some use cases that are not covered here and that are used in other clients, for example:

Kind33888 and 33889 for boards and pins in pinstr
Kind37777 for user cards in zap.stream

What should we do with these examples?

I think these do not fit into NIP-51, or do they? The Pinstr thing is more like a "spreadsheet table" NIP, and the the other one I don't get, where can I see it?

[fiatjaf]

What are Highlight lists @erskingardner? Was that a joke or do they exist?

[gzuuus]

However, in this effort to tidy up this nip I think it is worth mentioning some use cases that are not covered here and that are used in other clients, for example:
Kind33888 and 33889 for boards and pins in pinstr
Kind37777 for user cards in zap.stream
What should we do with these examples?

I think these do not fit into NIP-51, or do they? The Pinstr thing is more like a "spreadsheet table" NIP, and the the other one I don't get

Yes maybe pinstr ones do not fit in nip51 due to its totally different convention to structure the data, but zap.stream ones are more like kind30023 since they are editable and use markdown for formatting.

where can I see it?

https://github.com/v0l/zap.stream/blob/01eaf9996cfed9904906362c02597c65385102d1/src/const.ts#L9
https://njump.me/nevent1qqsgf58pds9la64vwcnxjwaat38f7dctk5x5gd0kquy0ug730fmw23g5ytm4f

[v0l]

• Kind37777 for user cards in zap.stream

The card itself is an event 37_777, the content can be updated, and the list of cards on a profile is the 17_777

[fiatjaf]

Any last additions or objections before we can merge this?

[vitorpamplona]

Can we get devs to declare their current compliance level to these new changes?

If 2+ clients are compliant, we merge.

I am running behind with Amethyst. :(

[hzrd149]

@vitorpamplona noStrudel is using:

• k:10000 for muting pubkeys
• k:10030 for users favorite emoji lists
• k:10004 and k:30001 "communities" for users communities (migrating to k:10004)

[staab]

Coracle's status:

• 10000 for muting pubkeys and events
• 30003 for bookmarks (I'll keep read-only support for 30001 for a while)
• 10004 for communities coming soon (probably December)

Kind of hard to really meet the threshold of "2 clients" for this one because there are so many different list kinds being merged. But the PR has a record amount of client dev buy-in so it's probably fine.

[gzuuus]

I will implement on nostree k30003 asap, but will continue to support k30001 read-only for a period of time.

[SnowCait]

How about adding NIP-65 kind:10002 relays to standard lists table as reference?

Public chats's kind:40 description seems to be wrong.

[fiatjaf]

What is wrong with the description?

[SnowCait]

Kind:40 is channel definitions, isn't it? (at L27)

"a" (kind:34550 community definitions)
"e" (kind:40 community definitions)

Seems to be copied from kind:34550 :)

[fiatjaf]

Oh, that took me a while to spot.

[erskingardner]

What are Highlight lists @erskingardner? Was that a joke or do they exist?

Sorry, didn't see this until now. They're not a joke, @pablof7z uses them in Highlighter I believe (unless he's changed that).

[erskingardner]

I will implement on nostree k30003 asap, but will continue to support k30001 read-only for a period of time.

Agreed. Going to implement these changes in Listr this week (including making 30001 lists read-only). I'll also be adding a merge tool to help people migrate faster/easier.

[pablof7z]

Ah yeah, I forgot I added those; 39802 (highlight is 9802 thus this number)