Re: Mnot's Pub/Sub for the Web

Mike Bishop:
> This is a very interesting space, and I’m glad we have two such solid 
> contenders.  I’m not convinced this fits squarely within HTTP’s 
> mandate, as this seems more like a protocol on top of HTTP than a pure 
> extension to HTTP.  Perhaps like OHAI, there might be enough interest 
> to warrant a dedicated working group?

Creating a separate working could be a good idea. For a couple years, I 
thought we would be making one, because the OT and CRDT and 
Decentralized Web people are such separate groups from HTTPBIS.

Also, I see ways in which Mercure looks like a protocol on top of HTTP, 
but I think Braid is a direct generalization of HTTP's core semantics. 
Let me give some examples:

Braid generalizes Range Requests, which RFC7233 defines only for GET:

    "A server MUST ignore a Range header field received with a request method other than GET."

Braid also defines Range Requests for PUT, which enables some very cool 
features.

First, it creates *patch* semantics. A "patch" is a replacement of a 
range of a resource. A PUT is a replacement, and a Range defines a 
range. This "patch" is very powerful. It can represent version control 
and collaborative editing (CRDT and OT) systems. We happen to study the 
most complex of these (see e.g. https://josephg.com/blog/crdts-go-brrr/ 
and https://braid.org/antimatter), and we can represent all of our 
systems' patches using variations of Range Requested PUTs.

Second, we extend Range Requests for both GETs and PUTs with GraphQL 
semantics—where you can ask for just a slice of some JSON structure. We 
do this by defining a new "Range Unit", as described in:

    https://datatracker.ietf.org/doc/html/rfc7233#section-2

This ^^ RFC describes how to define new Range Units, but the only one 
standardized thus far is "bytes". You typically see "bytes" in requests as:

    Content-Range: bytes 0-499

Braid defines an alternative to "bytes", named "json":

    Content-Range: json .posts[3].author.firstname[4:-5]

You can do a GraphQL query:

    Content-Range: graphql {students: {id full_name}, days: {*}}

Each of these is a different extension to the core of HTTP. When you put 
them all together, you get a robust synchronization protocol.

HTTP is a very general protocol already. It turns out to require very 
little for it to generalize into a synchronization protocol!