This is the first time I see nip81, and it seems to me you can mimic lists with it.

The set of pubkeys in the "d" tags of nip81 "follow" is like your follow-list. So if everyone's nip81 follows are identical to their follow-list, then the result is the same.

However, why having a gazillion events where you can have just one per pubkey? Validating 1000 signatures per user is not a small feat.

Reply to this note

Please Login to reply.

Discussion

it is a CRDT, it's supposed to be done once and cached

i'm glad to hear about this, i've also been saying this one for some time that mute and follow lists should be CRDTs - ie, add, remove, so long as timestamps are monotonic there is no confusion

what's hard about it is this: lazy programmers who don't want to build caches

I get the benefits of CRDTs, but it can create problems when some event in the change of diffs is not to be found. How would you deal with that case?

consistency is a fun game

a query where you can poll other nodes for "list kind but not these" would let you fill the gaps

it also hints towards the notion that users should have some "authoritative" store for their events (or stores) and at some point you have to throw your hands up in the air and say "the real world is a messy place" and too bad, so sad, get a helmet, to use some expressions that were popular in australia when i was a kid

the thing is CRDTs are *something* where the whole list is not just expensive bandwidth but also what if you can't find it, then it's all or nothing

Although I understand the data saving of CRDTs, I think they can introduce a lot of pain points, so I have a slight preference for the current grok brain approach of big lists.

yeah, big list is probably suited to gratis to store spam ridden relays, the signs are all there about what kind of security model was in the minds in addition to their expectations of their peers