If I ever start a new nostr project I'll probably use immutable events only. Replaceable events are a bad idea in a distributed system since they provide weak consistency only, hence the "some client nuked my mute list" issue proliferation. Profile metadata and contact lists have this problem too. I'll happily pay the cost in bandwidth and storage in exchange for consistency and predictability.

Reply to this note

Please Login to reply.

Discussion

Does that mean mute lists would be client-specific?

Nope, it means that muting something or someone on a client wouldn't mess with what you did in other clients. You still could have client specific mute lists if you wanted.

There should be a mechanism to retrieve the last X versions of replaceable events from relays so ovewrites can be undone.

I think this would be better than x100ing the number of events.

Also, having a 'state' of a list is super useful. Otherwise your'll never know if you got all item the user intended to be in the list.

mute list expires for 6 months, expiration Timestamp