nips
nips copied to clipboard
nostr-protocol
NIP-61 - Event Sets
I like the idea of having something like this. It would be nice to have it more explicit that you might have public and encrypted data coexist in a list. I'm not sure why we need n and u tags in addition to d though. Didn't you start by defining a new range? It seems to me we could just pick a regular event kind (<10000), use d as the name, and a instead of u to refer to all events in the list.
It would be nice to have it more explicit that you might have public and encrypted data coexist in a list.
Added "Public and encrypted data can coexist in unbounded list events similar to NIP-51 lists." Thanks
Didn't you start by defining a new range? It seems to me we could just pick a regular event kind (<10000), use d as the name, and a instead of u to refer to all events in the list.
I realized we didn't need a new range; just reserving the n tag to mark an event as being part of a list would be enough. Adding/removing n tags from an event is needed, so most times the event needs to be replaceable.
I have read this today for the first time (sorry) and I think it's a very good idea.
Are there any downsides?
If we're switching from having lists be identified by event kind numbers (as in NIP-51) to sets that are identified by strings ("friend", "follow" etc) then I think this NIP should include a growing table of standard set names that can be reused across clients.
The only downside I see is a possible confusion between sets (n tags) and labels (l tags) even though I think they are clearly different on my mind.
The relationships event is very similar to what I'm doing here: https://gitlab.com/soapbox-pub/ditto/-/blob/main/docs/events.md?ref_type=heads#ditto-user-kind-30361
It's a "user role" event, pretty much. But I think I could just add a "role" tag and use kind 30382 events directly in my software.
We always end up developing similar things @vitorpamplona
The "user role" event is closer to the kind:24 on @staab's #875
But I guess if Ditto is a key, then it could use the relationship status to put keys into sets by role.
If we're switching from having lists be identified by event kind numbers (as in NIP-51) to sets [...] this NIP should include a growing table of standard set names
We have to think about how to migrate NIP-51 lists to event sets because it is not clear yet which event kind(s) and structure to use. Should we bend "relationship status" event to become a standard for other sets?
Should we keep using NIP-51 for small lists such as "Emoji sets" and "Search Relays"?
How NIP-51 follow sets (not kind:3) are supposed to be distinguished from the regular NIP-61 "follow" set? They shouldn't all use n-tag=follow, although they are from the same "category" or should they? I mean, how will clients know how to fetch all follow sets? Maybe a reserved kind range so all sets use n-tag=follow and the first kind from the range is the "default" follow set?
Need ideas.
how to migrate NIP-51 lists to event sets
I don't see the need to migrate. Lists and Sets solve different problems. Sets are just another tool that people can use to group events in Nostr. It works for large groups while lists work best for smaller groups.
I don't see the need to migrate. Lists and Sets solve different problems. Sets are just another tool that people can use to group events in Nostr. It works for large groups while lists work best for smaller groups.
If sets are better for large groups, aren't we migrating those NIP-51 lists that can grow too much like mute, follow sets (and kind:3), bookmark and bookmark sets?
If follow lists become larger, sure. But the lists I see tend to be small, 50-100 people max. I am not sure if it's worth migrating all follows lists to sets. But the larger ones (kind3) should be migrated.
We should probably think about a common migration path from NIP-51 lists to this PR's sets. I can see a lot of devs starting with small lists and then realizing some of them might be too big for a single replaceable.
I like this PR in theory, but the migration is the difficult thing, plus forcing everyone to support lists and sets violates the "multiple ways to do something" principle. With history as a guide, this will never happen. However you're right that small lists are better served with lists, so maybe this PR could be articulated as an extension to lists, with all the same semantic kinds (incremented by 1000 or something?), for use with lists > 1000 items?
BTW, while we're talking theory, check my advanced Nostr philosophy idea about event sets: https://nostrify.dev/store/memory#event-sets
We are using the phrase to mean two different things. Sort of.
One disadvantage is having to download the bloated part of the event JSON and verify multiple event signatures instead of just one.
If you're fetching contact lists from many people and each of these people follow hundreds then amount of events downloaded may go very large, no?
@vitorpamplona hat to use kind:30382 template with different d tag values (instead of just pubkey) to be able to accommodate NIP-51 lists. Also had to change the event name... looks like #761 should be merged with this PR?
@fiatjaf One disadvantage is having to download the bloated part of the event JSON and verify multiple event signatures instead of just one.
Yeah there are some downsides.
NIP-51 has some too like:
- the list size limit due to relay event size restrictions.
- some people complain about
kind:3getting wiped. I guess with NIP-61 follow sets people would lose single follows instead of whole list - also the slow down of indexing many one-letter tags at once when updating a list
- can't download or update just one item at a time
Though can't say for sure if NIP-61 wins the competition.
Lol, this just got ultra-complicated. Do we really need to define all these rules?
@vitorpamplona Not much changed if you look closely.
kind:30061multiple events are the equivalent of your singlekind:10008event.- Your
kind:30382dtag is set top:<pubkey>instead of just<pubkey>. Then we can link to things other than pubkeys.
kind:30061 is needed to have things like NIP-51 follow sets (those lists similar to kind:3 but with user-generated label - see the "Best Friends Forever" example). Also to keep track of custom set names.
Clients adding a backtick to user generated set names when saving is a rule to avoid collision with standard list names.
Order was brought back to the PR after applying @vitorpamplona suggestions.
@vitorpamplona added private event sets, extracting it from your relationship status PR. Do you need the kinds to change or are they ok?
I almost made the Private stuff a separate NIP. I am not sure Clients must implement both to declare compliance with this NIP.
Because you have the "Table of "Set Item Reference" Event Kinds", you need to define the d tag for each of the kinds.
I would move the section "How to add items to a set" to before "Set types" because right now you are describing Set Types that are for multiple types: follow and friend and for pubkey sets; bookmark are for event sets. But you only describe that this difference exists much later.
I almost made the Private stuff a separate NIP. I am not sure Clients must implement both to declare compliance with this NIP.
Shouldn't clients just pick and use the sets they need? I mean, a client doesn't need to support all public sets and/or all private sets in this NIP. I added the private stuff cause it is the same thing with just the d tag twist addition.
Because you have the "Table of "Set Item Reference" Event Kinds", you need to define the d tag for each of the kinds.
Didn't understand. Do you mean the NIP should define the d tag separately for public and private versions? But the values are the "same". The difference is that private version obfuscates the tag value, as mentioned later at Private "Set Item Reference" Event:. (edit: before that, it is also said that "The unique features of the private version will be explained later.")
I would move the section "How to add items to a set" to before "Set types"
Done, thanks
Shouldn't clients just pick and use the sets they need?
Yeah, but partial support is tricky. Like do you merge the n tags of public and private sets to the same public key? Are those two separate sets? Questions that make things complicated.
Didn't understand. Do you mean the NIP should define the d tag separately for public and private versions?
Yep, otherwise it just looks like private events only work for public keys.
Even though this solves follow lists being huge, it doesn't solve follow notifications. I wish it did.
Even though this solves follow lists being huge, it doesn't solve follow notifications. I wish it did.
It kinda solves it. If pubkeyA makes a REQ for kind:30382 and d:pubkeyA, pubkeyA will receive all modifications made by everybody else's follow (and other lists) with pubkeyA. You can show a notification like this:
pubkeyB has changed your status to include the lists: follow, friend and idiot.
It's broader than just follow/unfollow.
It kinda solves it.
Yeah the client would need to track n tag changes cause although the filter { kinds: [30382], #d: ["<user>"], #n: ["follow"], since: <last-time-checked> } would include events that were updated since the timestamp, the update could have been on another n tag.
Tracking isn't that great, cause one may have thousands/millions followers.
Ideas:
A) kind:30382 n tags could include a timestamp to use client side like ["n", "follow", "<updated_at>"]
B) Or we add uppercase N tag to the kind:30382 with just n tag values that were added/removed at last event update. Then you do { ..., #N: ["follow"] }
C) Or we could use an auxiliary "Set Change Notification" event just with the n tag changes?
I like the local solution. If it is the first start, the notification can just be more generic (people don't care about new follows in the first start). Once the client has received some events, it can then display the differences between them on updates.
Yes, it just doesn't make the problem much easier.
I still like this event sets idea a lot, though. i'm working on implementing it in Ditto.
Why does the target event's pubkey need to be in the d tag for kind 30383 events?