Subject: Braid: Synchronization for HTTP

From: Michael Toomim <[email-masked]>
Date: Fri, 19 Jul 2019 13:45:47 -0700

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.

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

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-toomim-braid-00.txt
> Date: July 8, 2019 at 4:55:28 PM PDT
> To: "Michael Toomim" <[email-masked]>, "Rafie Walker" <[email-masked]>
> 
> 
> A new version of I-D, draft-toomim-braid-00.txt
> has been successfully submitted by Michael Toomim and posted to the
> IETF repository.
> 
> Name:		draft-toomim-braid
> Revision:	00
> Title:		The Braid Protocol: Synchronization for HTTP
> Document date:	2019-07-08
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-toomim-braid-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-toomim-braid/
> Htmlized:       https://tools.ietf.org/html/draft-toomim-braid-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-toomim-braid
> 
> 
> Abstract:
>  Braid is a proposal for an extension to HTTP that transforms it from
>  a state *transfer* protocol into a state *synchronization* protocol.
>  Braid puts the power of Operational Transform and CRDTs onto 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 have a working prototype of the Braid, and have deployed it with
>  production websites.  This memo describes the protocol, how it
>  differs from prior versions of HTTP, and a plan to deploy it in a
>  backwards-compatible way, where web developers can opt into the new
>  synchronization features without breaking the rest of the web.
> 
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Austin Wright <[email-masked]>
Date: Sun, 21 Jul 2019 12:24:09 -0700

> On Jul 19, 2019, at 13:45, Michael Toomim <[email-masked]> wrote:
> 
> Hi all!
> 
> 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/>.
> 

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.