Thought on Freenet’s merge model (why it works, and where its natural boundary is) #2927
Replies: 4 comments
-
This is true, however there are many kinds of applications where ordering can be sufficiently sustained at the application layer where we don't depend on network ordering and still maintain the necessary logical invariant. I think the universe of applications which cannot be replicated using CRDT is much smaller than we think for the classes of applications we are used to utilize in the Internet. So we cannot replicate all applications, but I am sure we can replicate a lot or most of them. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense, and I agree with most of that framing. I think you’re right that the class of applications that truly cannot be expressed via CRDT-style patterns is probably much smaller than people often assume — especially if you allow the application layer to carry its own ordering, invariants, and reconciliation logic rather than relying on network ordering. In practice, a lot of things that look “order-sensitive” at first can be reformulated so that the meaningful invariants are order-independent, even if the internal logic isn’t trivial. CRDTs have been surprisingly expressive in that respect. The way I think about it isn’t so much “CRDT vs non-CRDT”, but: which invariants you choose to preserve under merge, and what information you’re willing to treat as derived rather than fundamental. From that angle, Freenet’s approach feels very well-judged: it keeps the network simple and pushes complexity to where it belongs — the contract/application layer — where developers can decide how much structure they actually need to sustain. So yes, I agree: we probably can replicate most of the applications we’re used to on the Internet this way. The interesting edge cases, to me, are less about common apps and more about where people start trying to encode learning, adaptation, or long-lived intent — and even there, CRDT-style techniques may go further than intuition suggests. In any case, I really appreciate how cleanly Freenet draws the line between network guarantees and application responsibility. That separation is rare, and it’s one of the things that makes discussions like this possible at all. |
Beta Was this translation helpful? Give feedback.
-
|
Great discussion — I agree with everything said here. I actually struggle to think of a popular Internet service that couldn’t be implemented in this model. The hardest cases tend to be things that require strict global ordering or hard real-time guarantees, where you explicitly have to pay a coordination cost. But that’s a tradeoff, not a fundamental limitation. If someone has a concrete counterexample in mind I'd be interested to hear it. |
Beta Was this translation helpful? Give feedback.
-
|
That’s a fair challenge — and I agree that most mainstream Internet services can be expressed in this model once you’re willing to pay coordination costs at the application layer where needed. If I try to think of harder cases, they’re usually not “popular web apps” so much as systems where state evolution itself is part of the semantics. A few examples that feel more challenging (at least conceptually): Online learning systems where model updates depend on the precise sequence of observations, and replaying or reordering them can change the learned parameters in non-trivial ways. Reputation or trust graphs where temporal structure affects weighting (e.g. decay, recency bias, causally linked events). Causal audit logs where the order of events is itself the object of interest, not just a derived view. Certain kinds of financial matching engines or markets where price formation depends on arrival order in a way that can’t be fully reconstructed from a commutative aggregate. Now, it may well be that all of these can still be reformulated so that: the invariant that actually matters is order-independent, and the apparent order-sensitivity is just a derived property. That’s partly why I find this interesting — it’s less about “can CRDTs do it?” and more about identifying where the meaningful invariants really live. In many cases, once you push the right abstraction boundary, the need for global ordering collapses dramatically. In others, you end up explicitly paying for coordination because the application semantics genuinely require it. So I’m not claiming there’s a large class of popular apps that Freenet can’t express — more that the boundary between “naturally commutative” and “coordination-required” is a useful thing to make explicit. If others have concrete examples (in either direction), I’d also be very interested to see them. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
One of the things Freenet gets very right is requiring contract state to be order-independently mergeable. That single choice is what makes decentralised consistency scale without any central authority.
If you step back a bit, you can think of this as a “flat” case: updates can arrive in any order, loops always close, and divergence is resolved purely by merge. That’s why the system converges and why it scales so well.
What I’ve been thinking about recently (not as a proposal, just as framing) is that this isn’t just an implementation detail — it’s a particular regime of state evolution. Enforcing commutativity removes path-dependence entirely, which is exactly what you want for many classes of applications.
At the same time, there are application types where order actually carries information (learning, intent, history, reputation, etc.), and forcing everything into a fully order-independent merge can erase that structure. That doesn’t mean Freenet is “missing something” — it just marks a boundary of what this design is optimised for.
What’s interesting to me is that Freenet already sits at a very clean point in this design space:
no global clocks, no total ordering, no central coordinator, opaque bytes at the network layer, semantics fully defined by contracts. That’s a strong foundation.
I’m curious whether others here think about mergeability in these terms — not “commutative vs broken”, but “what kinds of meaning survive order-independent merge, and what kinds don’t”. Have you run into cases where commutativity felt like a feature, and cases where it felt like a constraint?
Beta Was this translation helpful? Give feedback.
All reactions