there is actually a new spec for a CRDT style atomic add/remove scheme but not many implementations yet

part of the reason is that client devs are not the sharpest knives in the drawer and instead of only one request and all is in one event, the clients have to parse every event from the user of this CRDT type and then assemble each pubkey into a list

in other words, it would probably make web clients especially, slower

but every other kind of client is using a language that wouldn't be as slow at dealing with it

some people also worry about consistency of the data, in that "they might miss something" for some random reason some unfollows might not be found and so on and so forth

i think the real solution is to have a compact fingerprint for nostr:npubs and a distributed registry of npub<->fingerprint and then you can pack them down to like 16 hex characters instead of the current 64

i'm pretty damn sure that SHA256 hash, truncated to 8 bytes is never going to see two nostr:npubs get the same fingerprint anyway... put it this way, the index in fiatjaf's event store just truncates the raw pubkey for the index

there is a ginormous number of values in 64 bits, it's 19 digits long in decimal, and SHA256 specifically is known for having a very low collision rate