Mutation is just inherently more complicated than storing immutable events. If someone is storing a new immutable event every 100ms they’re easy to spot as a potential spammer/abuse.
If they’re replacing an event every 100ms and a server naively just deletes old versions, now you don’t have a record of how much they’re (ab)using your resources.
Plus, a big benefit of signed events is holding people (or at least, pubkeys) accountable for what they’ve posted. If they can just edit it out of history, that is lost.
For that reason, my FeoBlog system disallowed mutability. But, that was super frustrating when I would inevitably discover a typo in what I just posted. So, while it’s more complicated, I’m glad that Nostr has a solution there.
But in my Nostr relay implementation, I keep older versions of mutable events so that you can see previous versions that a user posted. I’m keeping the receipts. 😉
> Mutation is just inherently more complicated than storing immutable events.
Not really. This blog post is mutable. There is nothing more complicated to it than to an immutable event.
> If they can just edit it out of history, that is lost.
It's not an edit. It's a new signature. You are free to keep all versions if you want to audit people. Also, almost all relays delete regular events. So, I would argue that auditing is exactly the same between replaceable a non-replaceable events. As we move along, relays won't be able to keep more than a few weeks of data for all their users. So, every event will disappear in time.
> For that reason, my FeoBlog system disallowed mutability.
You are free to force yourself to do this. But you are not free to force that decision on everybody else. If people want replacements, they will have replacements.
Oddbean new post about login | logout