Re: Mnot's Pub/Sub for the Web

> 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
considered when people mention pub sub, like:
>
>- Versioning & reconnecting
>- 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 <matthew@kerwin.net.au>
wrote:

> Hi all,
>
> On Wed, 23 Feb 2022 at 10:06, Seph Gentle <me@josephg.com> 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/
>
>