3 ms·
Yes, the braid protocol could let you run a distributed system over HTTP. It lets you put a CRDT or OT behind any HTTP resource, which lets you distribute the
by toomim 7y ago
Yes, the braid protocol could let you run a distributed system over HTTP. It lets you put a CRDT or OT behind any HTTP resource, which lets you distribute the resource, with multiple writers, and guarantee consistency after arbitrary edits. Each resource will still have a URL, with one particular hostname, but the actual state can live and be modified simultaneously on multiple hosts.
The first thing you might use this for is collaborative editing. Braid can give you the power of Google Docs at any HTTP URL, without writing additional code.
This also improves performance. Instead of using heuristics to determine when a cache needs to be reload (cache-control max-age, last-modified, etags), Braid will automatically push all updates to caches -- guaranteed. That means you never need to force-reload a page, or force-clear a cache. Also, updates are sent as minimal diffs, rather than re-sending the entire resource whenever it changes. This saves a lot of bandwidth and a lot of round-trip latency when loading a page.
As a third practical example, Braid makes it very simple to read and write data from multiple web sites. By collapsing time, braid implementations let you write code that manipulates state at any URL as easily as a local variable. It doesn't matter whether state is located on your server, or someone else's server, or distributed on everyone's servers and clients. It's all equally easy to interact with.
This also makes it easy to write a new UI for an existing site.
As for Paxos, yes, CRDTs are an alternative to Paxos, and CRDTs can be used in Braid. CRDTs have some performance improvements over Paxos -- Paxos chooses a leader, and whenever the leader is unreachable, a new leader election takes place which requires a couple network round trips before any new edits can be broadcast. CRDTs are always editable, and edits can always be broadcast.
- sagichmal 7y ago> Braid can give you the power of Google Docs at any HTTP URL, without writing additional code. What implements the OT or CRDT logic? The webserver itself?
- toomim 7y agoYes, 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.
- sagichmal 7y agoWhy should this be implemented in HTTP itself, rather than as an application using HTTP as a transport?
- toomim 7y agoI suggest reading the introduction to either of these specs: - https://datatracker.ietf.org/doc/html/draft-toomim-braid https://datatracker.ietf.org/doc/html/draft-toomim-braid - https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http-01 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.
- sagichmal 7y ago> 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. This is not coherent.