NIP-61 - Event Sets

[arthurfranca]

Read here

Like NIP-51 lists but without list size limit.

[staab]

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.

[arthurfranca]

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.

[vitorpamplona]

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.

[vitorpamplona]

Additional comments on the structure of the text.

[vitorpamplona]

this map tag is strange. If thiere are many n tags, how does it know which one is the encrypted one?

On #761, I created kind 10008 to have maps for any n tag. People can privately rename tags at will with that structure.

[arthurfranca]

This is in fact a map from the d tag to the map value. The n tag was a way to do, for example, NIP-51 Follow Sets (NIP-51 kind:30000 follow lists with a custom d label), meaning when you add an n=follow tag, you are saying the event set is follow-ish. I admit the structure is bizarre.

I will improve it using your way (kind:10008) but with a parameterized replaceable event. So d=follow tag will mark all custom sets as follow-ish. Else, use d="" for custom sets with no standard meaning.

[alexgleason]

Even though this solves follow lists being huge, it doesn't solve follow notifications. I wish it did.

[vitorpamplona]

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.

[arthurfranca]

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?

[vitorpamplona]

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.

[alexgleason]

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.

[alexgleason]

Why does the target event's pubkey need to be in the d tag for kind 30383 events?

[alexgleason]

Suggested change

	| **event** | 30383 | `<event-pubkey>:<event-id>` | `["k", "<event-kind>"]` |
	| **event** | 30383 | `<event-id>` | `["k", "<event-kind>"]` |

Including the pubkey is a painful annoyance. It makes it harder to query, and harder to create the event, with no apparent benefits.

[alexgleason]

I saw in another thread, the justification was that it can be used like a relay hint. That's not a good enough reason to put it in the d-tag value. You could use ["d", <event-id>, <optional relay>] for the same purpose, or even ["d", <event-id>], ["relay", <relay>]

[arthurfranca]

Let's consider it a fact that both the referenced event author's pubkey and the regular relay hint are important when searching for the referenced event. The former is slower cause needs more steps to find the event, while the latter may suffer from link rot.

With that said, this was my jerk move to force people to add NIP-65 pubkey hint. I agree with the "annoyance" part if you meant that this shouldn't be placed in the d-tag cause it shouldn't be indexed by relays.

Besides the ["relay", "<relay>"] what do you think of ["nip65pk", "<pubkey">] for the pubkey hint?

[alexgleason]

In the spirit of the k tag, I ended up adding a p tag of the original author in my events. Here's an example:

{
  "kind": 30383,
  "id": "00dab96e90bf45215b6c8b7e2d6c238977d5395eeeaf7b236d161875537f819f",
  "pubkey": "d4ac0aa9df4ae9c491fde58ae4846079ad20332a59d7a360a186122320ad780f",
  "created_at": 1717945869,
  "tags": [
    ["d", "b8d54511a88165d8e59d29617d66d76c4564e013bdcfec021d663bf63d3b46fe"],
    ["n", "closed"],
    ["p", "0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd"],
    ["k", "1984"],
    ["P", "9989500413fb756d8437912cc32be0730dbe1bfc6b5d2eef759e1456c239f905"]
  ],
  "content": "",
  "sig": "14bc909d5ea13658833d0996ad09185ac5ffbf0bd2ab7f5a9f1a2f02df79e6bda212916258de1039c0ff695b28366f77e9b9ebd0811b26e04dbb1c7f46e58227"
}

[arthurfranca]

It works but the k tag is indexable cause there is a need to get just 30383 events referencing events of specific kinds.
I couldn't think of an use case where one wants to filter also by referenced event pubkey. We shouldn't add one-letter tags for no reason.

And what's the uppercase P for? (edit: nvm guess its related to the 1984 report)

[alexgleason]

Every time a report comes in, I generate a kind 30383 event for it with ["n", "open"]. Then instead of querying kind 1984 events, I query { kinds: [30383], authors: [me], '#k': [1984] } and paginate through this list.

This allows me to mark reports as open or closed, and then query by the n tag to get reports depending on their status.

I want the "p" tag so I can also filter by the user who created the report, in conjunction with filters like "open"/"closed".

The uppercase "P" is people who the report tags, so I can similarly filter reports targeting specific users users along with "open"/"closed".

[arthurfranca]

I want the "p" tag so I can...

Thx for the example, changed 30383 and 31383 to use just the event id in the d-tag. Added the p tag too.

[alexgleason]

@arthurfranca Should this be unmarked as a draft?

[vitorpamplona]

I am just realizing that with this, we are just swapping an event with thousands of keys (e.g. the contact list) to an event with thousands of list names (e.g. new 30382).

Different race conditions, but race conditions might still be a problem if lists become a common feature of Nostr clients.

Regardless, this is a good evolution.