Subject: Mnot's Pub/Sub for the Web

From: Michael Toomim <[email-masked]>
Date: Sat, 19 Feb 2022 23:36:33 -1000

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?

---

From: Kévin Dunglas <[email-masked]>
Date: Tue, 22 Feb 2022 18:55:42 +0100

Thanks for bringing this topic to the list again!

On the Mercure side, the spec has stabilized. Several open-source and
proprietary implementations are available (
https://mercure.rocks/spec#implementation-status), and adoption is growing:
2.7K stars on GitHub, dozens of open source projects using it, large
companies publicly declaring use...

Many new use cases have been reported on the bug tracker over the years,
and we improved the spec to cover most of them. Some minor issues still
need to be handled (https://github.com/dunglas/mercure/labels/spec), but
we're very soon to publish the final version of the specification.

As demonstrated by the discussions on Hacker News, Mark's great article,
and by the adoption of Mercure, the community is in demand of a pub/sub
standard for web resources.

Even if most discussions occurred on GitHub, Slack, Twitter, and other
channels instead of on IETF mailing lists, the Mercure spec is now
implemented by production-grade "running code" and has reached "rough
consensus".

Mercure is less ambitious than Braid. Its scope is more limited. It is
focusing on providing a simple pub/sub protocol for web content proved
working with the current web infrastructure (web browsers, proxies,,
firewalls, etc). In its current state, it doesn't require any JS library or
polyfill client-side.

The spec is very similar to the WebSub specification from the W3C, but
mainly targets web browsers instead of servers. As WebSub, Mercure uses a
hub to distribute web resources, which allows implementing the protocol
easily even in legacy applications, with languages not designed to handle
long-living connections (e.g. PHP), and when using modern infrastructure
such as serverless and edge computing platforms (
https://dunglas.fr/2019/07/mercure-real-time-apis-for-serverless-and-beyond/).
Unlike WebSub, Mercure natively supports authorization, end-to-end
encryption, and state reconciliation. Both clients and servers can be
publishers.

Currently, Mercure only allows using SSE as transport, but we'll maybe
allow using other transports such as WebSockets and Web Transports,
probably as extensions to the current spec, to cover use case such as
transmitting non-base64-encoded binary data (
https://github.com/dunglas/mercure/issues/616).

Braid is very interesting and has a much broader scope (state
synchronization, P2P, etc). It also requires more changes to the current
software stack to be natively supported by the web platform. Mercure
overlaps only with the "subscribe" feature of Braid, and I've the feeling
than Braid could use Mercure (and probably WebSub too) for its subscribe
feature, at least in a first iteration.

I wonder how we can move forward regarding the standardization of a pub/sub
protocol for web content and web browsers. Even if Mercure gained traction
outside of the IETF, it hasn't on this group. I was thinking about
proposing the final version of the spec as an independent-track RFC, or to
the W3C as it is very close to WebSub, and is also related to the other
specs published by the Social Web Working Group (ActivityPub, and even
Solid). But as the this topic is discussed again, maybe could we work on a
pub/sub protocol here?

On Sun, Feb 20, 2022 at 10:39 AM Michael Toomim <[email-masked]> wrote:

> 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
> He wants to Subscribe specifically to *state updates*. He wants to Publish
> specifically *updates to state*.
>
> 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**.
>
> resource" is what a State Synchronization protocol defines. And, in fact,
> we have two proposed solutions to State Synchronization in the IETF!
>
> Braid:
> Synchronization abilities, as well as excitement about the new fundamental
> power it gives programmers on the web.
>
> *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.
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Feb 2022 21:22:02 +0000

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?

From: Kévin Dunglas <[email-masked]>
Sent: Tuesday, February 22, 2022 12:56 PM
To: Michael Toomim <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; Mark Nottingham <[email-masked]>
Subject: Re: Mnot's Pub/Sub for the Web

On the Mercure side, the spec has stabilized. Several open-source and proprietary implementations are available (https://mercure.rocks/spec#implementation-status), and adoption is growing: 2.7K stars on GitHub, dozens of open source projects using it, large companies publicly declaring use...

Many new use cases have been reported on the bug tracker over the years, and we improved the spec to cover most of them. Some minor issues still need to be handled (https://github.com/dunglas/mercure/labels/spec), but we're very soon to publish the final version of the specification.

As demonstrated by the discussions on Hacker News, Mark's great article, and by the adoption of Mercure, the community is in demand of a pub/sub standard for web resources.

Even if most discussions occurred on GitHub, Slack, Twitter, and other channels instead of on IETF mailing lists, the Mercure spec is now implemented by production-grade "running code" and has reached "rough consensus".

Mercure is less ambitious than Braid. Its scope is more limited. It is focusing on providing a simple pub/sub protocol for web content proved working with the current web infrastructure (web browsers, proxies,, firewalls, etc). In its current state, it doesn't require any JS library or polyfill client-side.

The spec is very similar to the WebSub specification from the W3C, but mainly targets web browsers instead of servers. As WebSub, Mercure uses a hub to distribute web resources, which allows implementing the protocol easily even in legacy applications, with languages not designed to handle long-living connections (e.g. PHP), and when using modern infrastructure such as serverless and edge computing platforms (https://dunglas.fr/2019/07/mercure-real-time-apis-for-serverless-and-beyond/). Unlike WebSub, Mercure natively supports authorization, end-to-end encryption, and state reconciliation. Both clients and servers can be publishers.

Currently, Mercure only allows using SSE as transport, but we'll maybe allow using other transports such as WebSockets and Web Transports, probably as extensions to the current spec, to cover use case such as transmitting non-base64-encoded binary data (https://github.com/dunglas/mercure/issues/616).

Braid is very interesting and has a much broader scope (state synchronization, P2P, etc). It also requires more changes to the current software stack to be natively supported by the web platform. Mercure overlaps only with the "subscribe" feature of Braid, and I've the feeling than Braid could use Mercure (and probably WebSub too) for its subscribe feature, at least in a first iteration.

I wonder how we can move forward regarding the standardization of a pub/sub protocol for web content and web browsers. Even if Mercure gained traction outside of the IETF, it hasn't on this group. I was thinking about proposing the final version of the spec as an independent-track RFC, or to the W3C as it is very close to WebSub, and is also related to the other specs published by the Social Web Working Group (ActivityPub, and even Solid). But as the this topic is discussed again, maybe could we work on a pub/sub protocol here?

On Sun, Feb 20, 2022 at 10:39 AM Michael Toomim <[email-masked]<mailto:[email-masked]>> wrote:

Hello, HTTP!

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

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?

---

From: Kevin Marks <[email-masked]>
Date: Tue, 22 Feb 2022 22:49:34 +0000

Does WebSub (formerly PubSubHubbub) fit this case?

On Tue, 22 Feb 2022, 9:25 pm Mike Bishop, <[email-masked]> wrote:

> 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?
>
>
>
> *From:* Kévin Dunglas <[email-masked]>
> *Sent:* Tuesday, February 22, 2022 12:56 PM
> *To:* Michael Toomim <[email-masked]>
> *Cc:* HTTP Working Group <[email-masked]>; Mark Nottingham <
> [email-masked]>
> *Subject:* Re: Mnot's Pub/Sub for the Web
>
>
>
> https://mercure.rocks/spec#implementation-status), and adoption is
> growing: 2.7K stars on GitHub, dozens of open source projects using it,
> large companies publicly declaring use...
>
>
>
> I wonder how we can move forward regarding the standardization of a
> pub/sub protocol for web content and web browsers. Even if Mercure gained
> traction outside of the IETF, it hasn't on this group. I was thinking about

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Feb 2022 10:01:15 +1100

As far as I can tell, that requires the client to have a URI that can be POST to, so I think this is different.

> On 23 Feb 2022, at 9:49 am, Kevin Marks <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Seph Gentle" <[email-masked]>
Date: Wed, 23 Feb 2022 11:01:42 +1100

To me, the heart of HTTP is a core set of reusable verbs that we can use with different URLs (nouns). But the verbs we have now assume resources never really change. (Or if they do, you need to poll for changes).

One way of thinking of the braid proposal is that semantically we want to add a missing verb (subscribe) to URLs so the server can notify clients when a resource changes. Ideally I'd like to do this in a way which allows arbitrary clients to subscribe to arbitrary resources. (Unlike websockets or SSE, which both need applications to invent application-specific protocols for this)

And this is useful in lots of use cases:

- Caches keeping some pages "hot" without needing to revalidate
- Live updating values (eg server monitoring, watching the price of bitcoin, etc)
- Collaborative editing
... Etc.

There's a few parts we need to do this well, which aren't often considered when people mention pub sub, like:

- Versioning & reconnecting
- Patches (with named types, so generic clients can be written)

I'd be happy for it to be a GET query with options or something, but however we do it I think it would be much *cleaner* implemented as part of HTTP. I want it to be understandable by caches and middle boxes, rather than something sitting on top of HTTP in an idiosyncratic way.

-Seph

On Wed, 23 Feb 2022, at 8:22 AM, Mike Bishop wrote:
> *Cc:* HTTP Working Group <[email-masked]>; Mark Nottingham <[email-masked]>

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Feb 2022 11:10:18 +1000

Hi all,

On Wed, 23 Feb 2022 at 10:06, Seph Gentle <[email-masked]> wrote:
>
> I'd be happy for it to be a GET query with options or something, but however we do it I think it would be much *cleaner* implemented as part of HTTP.

Do you mean HTTP the semantic layer, or HTTP the transport layer? I
assume you mean the former since you're talking about verbs and nouns.
For the latter there are probably lessons to be gleaned from HTTP/2
server push, especially its evolution during specification from a
general-purpose reverse data flow to a specific cache priming/busting
tool (to something nobody implemented).

> I want it to be understandable by caches and middle boxes, rather than something sitting on top of HTTP in an idiosyncratic way.

My concern is that those caches and middle boxes are the very reason
it's hard to implement anything new at the HTTP layer (either one).
Some of those boxes are ossified around HTTP/1.0 and will never
update; many probably implement an approximation of /1.1, but any
message that isn't the exact flavour of /1.1 they've been coded to
handle will make them explode. To the point that they don't read the
version number, or sometimes even the entire method, in the request
line.

Maybe there's a space to design something as an extension to HTTP/2
and /3, since those intentionally don't route through legacy
middleware, but then there's a fork of the HTTP semantic layer
(version 1, and version 2+) which we've kind of avoided up until now.
(Aside: changing from single-request uber-concatenation in H1 to
persistent connections with many tiny blobs in H2 could have lead to a
semantic shift, but it's hard to see if that's actually happening.)

As always on the Internet, a layer has ossified so it's time to build
upwards. As messy as that is. (something something H3 over UDP instead
of IP..)

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/

---

From: Kévin Dunglas <[email-masked]>
Date: Thu, 24 Feb 2022 19:35:10 +0100

> Does WebSub (formerly PubSubHubbub) fit this case?

As Mark pointed out, WebSub only supports server-to-server communications.
The subscriber must expose an endpoint that accepts POST requests. Mercure
is largely inspired by WebSub but is primarily targeted at
server-to-browser and browser-to-browser communications. We have tried to
keep the specification as close to WebSub as possible. Mercure uses the
same terms, query parameters, etc.
Mercure can be seen as "WebSub for web browsers". For this, the Mercure hub
distributes updates using SSE instead of a POST endpoint. That being said,
Mercure has some features that WebSub does not have: advanced
authorization, state reconciliation, versioning support...
The two protocols are very complementary.

> There's a few parts we need to do this well, which aren't often
>- Patches (with named types, so generic clients can be written)

Mercure does support these parts:

- The spec recommends using the `id` field of Server-Sent Events to store
the revision identifier of the resource. As SSE natively supports automatic
reconnection and state reconciliation, Mercure ensures that missed updates
made to a resource during a disconnection are sent as soon as the network
is back. It's also possible to retrieve all changes made since a given
revision (for instance to fetch changes that have been made to a document
stored in a cache): https://mercure.rocks/spec#publication
- Because of the previously mentionned characteristics, it's possible to
send patches instead of full documents as updates. The discovery mechanism
allows the publisher to hint the subscriber that it will receive patches,
and to specify the patch format that will be used:
https://mercure.rocks/spec#discovery

> As always on the Internet, a layer has ossified so it's time to build
upwards. As messy as that is.

We might be able to find a path forward: Mercure works with the web
platform in its current state, and it looks doable to use Mercure (which
has a narrower scope: a simple pub/sub protocol for any web resource) as a
transport for Braid patches. The "Version" header could be used as Mercure
revision identifier and the Braid patch format could be used as in the
payload of the updates. This is actually already supported on Mercure side.
The new HTTP extensions that could be specified in Braid as suggested by
Matthew could be used when supported, and the Mercure mapping could be used
when not. This would also allow immediate adoption of bread.

> Perhaps like OHAI, there might be enough interest to warrant a dedicated
working group?

This could indeed be a good idea. Regarding Mercure, on the one hand it
seems very complementary with Braid and could therefore be worked on in the
HTTP group (considering Braid will provide new HTTP extensions) or in this
potential new group, on the other hand it is very close to WebSub (which is
a W3C standard) so maybe we could also consider the W3C SocialCG group?

On Wed, Feb 23, 2022 at 2:13 AM Matthew Kerwin <[email-masked]>
wrote:

> > I'd be happy for it to be a GET query with options or something, but
> however we do it I think it would be much *cleaner* implemented as part of
> HTTP.
>
> > I want it to be understandable by caches and middle boxes, rather than
> something sitting on top of HTTP in an idiosyncratic way.
>

---

From: "Seph Gentle" <[email-masked]>
Date: Fri, 25 Feb 2022 12:32:47 +1100

> tool (to something nobody implemented).

Yep, the semantic layer. I'm happy to defer to the collective wisdom of the working group when it comes to figuring out the syntax for something like this. So long as we capture the semantic intent of "subscribe to changes in the named resource" in a sensible way.

> version number, or sometimes even the entire method, in the request

How well do server-sent events work in practice through those systems? It seems like expanding on SSE might be a reasonable approach:

- Keep using GET, rather than inventing another HTTP verb
- Add client headers to specify the client's intent - "I want to subscribe, not just fetch a single copy of the document".
- The server can use http-like framing for SSE
- This is implementable right now (we've certainly done so), using javascript + the streaming capabilities of the fetch() method in web browsers.

> upwards. As messy as that is. (something something H3 over UDP instead

Yeah; I suspect we could make something which sits very cleanly on top of HTTP2's internal semantics. But its a shame very little of that is exposed to browser javascript. It makes it much harder to try things out without modifying the web browser itself.

---

From: Michael Toomim <[email-masked]>
Date: Fri, 25 Feb 2022 21:59:55 -1000

Kévin:
> synchronization, P2P, etc). It also requires more changes to the 
> current software stack to be natively supported by the web platform.

Just to be clear— neither Braid nor Mercure *require* changes to web 
browsers. They are like SSE: a new way using HTTP as it already exists, 
to give it new behaviors.

> pub/sub protocol for web content and web browsers. Even if Mercure 
> gained traction outside of the IETF, it hasn't on this group. I was 
> thinking about proposing the final version of the spec as an 
> independent-track RFC, or to the W3C as it is very close to WebSub, 
> and is also related to the other specs published by the Social Web 
> Working Group (ActivityPub, and even Solid). But as the this topic is 
> discussed again, maybe could we work on a pub/sub protocol here?

I think this work should be taken up in the HTTP group. "State Transfer" 
is an intimate component of both HTTP and ReST, and generalizing that to 
"State Synchronization" is a big deal for HTTP. This is a worthwhile 
topic for the HTTP working group to discuss.

---

From: Michael Toomim <[email-masked]>
Date: Fri, 25 Feb 2022 23:15:28 -1000

Mike Bishop:
> 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!

---

From: Michael Toomim <[email-masked]>
Date: Fri, 25 Feb 2022 23:50:51 -1000

> version number, or sometimes even the entire method, in the request

Thank you for bringing this up!

Many of these boxes have never updated, but this HTTP upgrade will 
create a new business opportunity: dynamic proxies. These proxies will 
be able to cache dynamic state; not just static assets. You'll be able 
to cache JSON that's being collaboratively edited by 100 clients. If 
your WAN internet goes down, your users can still collaborate on your 
LAN, through this proxy!

This business opportunity will enable new middleboxes to be created and 
sold. They'll probably sit alongside the dumb old ones. That's ok, 
because the new protocol is just an extension of the old. Any middlebox 
can support any subset of features it wants to.

---

From: Michael Toomim <[email-masked]>
Date: Sat, 26 Feb 2022 00:13:21 -1000

Michael Toomim:
>
> Braid also defines Range Requests for PUT, which enables some very 
> cool features.
>
> First, it creates *patch* semantics. [...]
>
> semantics... [...]
Third, this creates Resumeable Upload semantics. We can implement the 
beautiful dream that Austin Wright proposed in 2019:

    https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0066.html

To resume an upload, the client simply PUTs the remaining "range" of the 
file.

We get this ability for free, by just defining the semantics of a Range 
Request on a PUT. These are basic HTTP features that just need to be 
combined together.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Feb 2022 18:10:39 +0100

> Request on a PUT. These are basic HTTP features that just need to be

You may want to read the history around
<https://github.com/httpwg/http-core/issues/618>.

Best regards, Julian

---

From: Michael Toomim <[email-masked]>
Date: Mon, 28 Feb 2022 18:08:28 -1000

> <https://github.com/httpwg/http-core/issues/618>.

This is an excellent reference, thank you!