Mnot's Pub/Sub for the Web

Hello, HTTP!

Today Mark Nottingham posted a great articulation of the issues 
programmers face when choosing between using SSE, WebSockets, and 
WebTransports:

    https://www.mnot.net/blog/2022/02/20/websockets

I'll attempt to summarize Mark's beautiful insight as: in almost all 
cases, what the programmer *really* wants is a Pub/Sub protocol, not an 
arbitrary socket. And we could standardize a Pub/Sub protocol, and that 
would have great benefits.

These benefits are real and I think could improve performance 
dramatically. CDNs could cache realtime updates, not just static data.

However, I'll take Mnot one further, and propose that when a programmer 
is choosing a Pub/Sub protocol, what he *really* wants is a State 
Synchronization protocol, not an arbitrary Pub/Sub protocol.

He wants to Subscribe specifically to *state updates*. He wants to 
Publish specifically *updates to state*.

What we need is not a general Pub/Sub standard, but specifically a State 
Synchronization standard. State Synchronization is a constrained type of 
general Pub/Sub. And we'll need to constrain Pub/Sub in this way to 
address some of the issues Mark brings up, such as:

     > There are also some architectural/philosophical concerns about
    how non-final responses **relate to the state of the resource**.

The relationship between a server's "responses" and the "state of the 
resource" is what a State Synchronization protocol defines. And, in 
fact, we have two proposed solutions to State Synchronization in the IETF!

    Braid:
    https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http
    Mercure: https://datatracker.ietf.org/doc/draft-dunglas-mercure/

I am seeing a growing awareness that HTTP needs to add State 
Synchronization abilities, as well as excitement about the new 
fundamental power it gives programmers on the web.

These protocols transform HTTP from a State *Transfer* into a State 
*Synchronization* protocol. Whereas a transfer protocol can move a 
resource from server to client in a single request/response, it requires 
an application programmer to take over if the resource ever changes 
after the response completes. That sucks for programmers. A 
synchronization protocol provides a much better programming abstraction. 
The programmer just says "I want state X", and can assume it will be 
kept up-to-date by the protocol.

If we standardize this, we also get CDNs that automatically cache 
dynamic content (the stuff currently hidden within websockets), just as 
easily as they cache static content today. We get collaborative editing 
and offline modes available in web apps for free. We also take an 
important step towards decentralizing the web, by creating an open 
standard for the trickiest part of decentralized app development — data 
synchronization — that is compatible with P2P CRDT and OT algorithms.

Since this all seems to be coming together, I would like to know what 
HTTPbis as a group thinks. Is there interest in this topic?

If so, what aspects might we want to work on?