and when played out of order, it's guaranteed to resolve to foobaz eventually or immediately, depending on when messages are received

when you encounter the scenario of a fork, there's usually a fork resolution rule, e.g. D: { "prev_hash": "<hash of B>", "content": "foobazbar" }

to resolve C vs D, sort lexicographically, choose direction of sort order and pick first

When you have non-continuous data due to messages dropping, e.g. you have B and perhaps an E that builds on C, you can either use the same lexicographic rule, or make the hash basis a combination of timestamp and hash, so you get temporality and lineage.

As for deletes, you have either the single set approach of simply making the message content empty and that _is_ the delete, or you have the 2-phase sets, where there exists an add set and a delete set.

Quite a few ways to approach it, but commutativity can be readily preserved.

but "makes sense" and ways to optimize that can change massively with context. e.g. for a chat app, as soon as you see "deleted message X", you can reasonably drop all past and future changes to X because they won't be shown. if you do that with "deleted chars 87..93" in a text editor, past-edits that you receive in the future might affect the behavior (it might add chars before those, changing what that range means), so you can't simply forget those chars (e.g. an easy option is to replay all events that occur after an event syncs, but that means retaining all events forever). the semantics you choose and what you do with the data affect your outcomes a lot.

tbh this is one of the reasons I like the idea of a WASM-defined algorithm. no one algorithm will be "best" for all data, and the storage/computation/transmission savings can be extreme.

So there is no one approach to this, rather you design the approach based on the application, and since contracts are just webassembly they are extremely flexible.

[1] https://github.com/freenet/river

And even without agreeing on whether people should be anonymous on the Internet,

it could be agreed that replacing a software which guards against a certain threat model (repressions) with one which does not,

without changing the name, is not exactly a wise decision.

There was no "year of debate".

You came to the mailing list and announced it for the first time as a finalized decision already,

without any prior debate with the original team.

The "board" you cited as the body which allegedly discussed it did neither join the mailing list discussion,

nor were you willing to hand out their contact info.

It's all public for anyone to see on the mailing list archive:

https://www.mail-archive.com/devl@freenetproject.org/msg5526...

https://www.mail-archive.com/devl@freenetproject.org/