Yes, the server and client implement the logic. Each URL specifies its "Merge-Type" in a header, which defines the spec for the OT or CRDT that they implement.
- https://datatracker.ietf.org/doc/html/draft-toomim-braid
- https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...
People do synchronize at the application level today. But every application invents its own non-standard synchronization method, which is incompatible with every other application. This results in each website only accessing its own state, rather than sharing state with other websites, and the web becomes a bunch of walled gardens.
In order to decentralize the web, we need a standard for the internal state of websites, that makes it easy for websites to re-use the state of other websites. Where the original web allows any website's pages to link to any other site's pages, Braid allows any site's internal state to synchronize with the internal state from any other site.
Now, you might ask why we should implement a standard at the HTTP level, rather than make a standard on top?
Well, it turns out that HTTP and REST are already designed for sharing state-- but they are just limited to state transfer rather than state synchronization. It is very natural to extend it to synchronization -- we can do it with just 5 new headers, 1 new response code, 2 range units, and 1 new registry.
And if you try to build something on top, you'll have to re-implement all the great things that HTTP has invented that we now take for granted: caching, CDNs, idempotency, media types, etc. By putting synchronization into HTTP, we can add these features to the existing web. Caches (like CDNs) can suddenly support dynamic content -- not just static content. If you change a line of code in your Javascript, all clients will update with just a diff, rather than re-requesting the entire file. The reload button becomes obsolete. Existing HTTP network traffic becomes more efficient. Every TEXTAREA can become a collaborative editor.
This is not coherent.
The Braid spec does not impede access control — that works just like it always has on the web. A client logs into a server. If a client does a GET request, the server decides whether the client can see the result. If a client does a PUT request, the server decides whether to allow it. The only difference is that these GET and PUT requests can now be broken into granular patches with a version history.
And if you want to build a peer-to-peer network, then you will replace the server with a validation function running on each peer, and authentication with a crypto scheme. But we aren't at the point of trying to standardize that stuff yet.
My concern is that this requirement means the state can't be encrypted.
> if you want to build a peer-to-peer network, then you will replace the server with a validation function running on each peer, and authentication with a crypto scheme
How do you break a GET request of some state blob into "granular patches" if the state is encrypted?