Re: Braid: Synchronization for HTTP

> On Jul 19, 2019, at 13:45, Michael Toomim <toomim@gmail.com> wrote:
> 
> Hi all!
> 
> I'm writing to request review for a new extension to HTTP called Braid, which gives it the ability to synchronize changing state, rather than just transfer it. Braid integrates the power of Operational Transform and CRDTs with the web, improving network performance and robustness, and enabling peer-to-peer web applications.
> 
> At the same time, Braid creates an open standard for the dynamic internal state of websites.  Programmers can access state uniformly,  whether local or on another website.  This creates a separation of UI from State, and allows any user to edit or choose their own UI for any website's state.
> 
> We just published a first draft of the Braid protocol here: https://tools.ietf.org/html/draft-toomim-braid-00 <https://tools.ietf.org/html/draft-toomim-braid-00>. Additional resources are at https://braid.news <https://braid.news/>.
> 
> As this is a new proposal, we are also looking for a home for its development. Is the HTTPWG interested in aspects of this work?
> 
> In any case, I look forward to seeing you in Montreal! This will be my second IETF meeting, and it was fun meeting many of you in Prague.
> 
> Michael
> 

My personal notes on draft-toomim-braid-00:

* This seems to be written like an academic paper rather than an RFC, is this ultimately intended to be a technical specification?

* One of the examples uses a `braid:` URI. First, consider referencing “example.com"; second, how the “braid:” scheme dereferenced differently versus “http:”? How would one point to a p2p resource?

* Does this anticipate registering “Linked JSON” as a new media type? (That would go under IANA Considerations.) What existing JSON-based hypermedia types have you considered using?

* For versioning, HTTP can represent specific versions of resources as hyperlinks. See <https://tools.ietf.org/html/rfc5829>, among some others.

* Could this simply be implemented as a new HTTP method? e.g. suppose this defines a SUBSCRIBE method that streams changes to the resource (using a new media type built for this purpose). Likewise, modifications would be uploaded via PATCH (using the same media type). You can also look at CoAP, which already has a SUBSCRIBE method, and a WebSockets transport.

* The Web does allow for client state, at the user-agent's discretion. If I download a webpage, I don’t expect my edits for form fields to be automatically propagated to other users, at least not until I submit the form, or otherwise opt-in. Also, bookmarks and navigation history are forms of client state too. How do I distinguish between these states that I do and do not want synchronized?

* Can this be used with hypermedia types, like HTML? It would seem strange if this were a protocol built only to support a single media type.

* Is there more to this than a standardized implementation of operational transform, for editing resources? It seems like what you’re aiming for is something like WebSockets, specialized for OT and more transparent to the client; especially the Upgrade handshake to change protocols, and a standard ECMAScript API for Web browsers. (My first impression is this aims to change the semantics of HTTP entirely, but upon further inspection, is actually much more modest.)

Thanks,

Austin Wright.