The problem with federated web apps

Programming@programming.dev – 0 points – 1 years ago

Trying to make web applications federated is a popular effort. Examples include things like the “fediverse”, as well as various other efforts, like attempts to make distributed software forges, and so on. However, all of these efforts suffer from a problem which is fundamental in building federated applications built on top of the web platform.

The problem is fundamentally this: when building an application on top of the web platform, an HTTP URL inherently couples an application and a resource.

Except it doesn't couple an application and a resource. Serving the application/web UI is only a side effect of the browser requesting the resource be served in HTML format, which brings up the web application. It's a backwards compatible convenience for users to be able to access the resource in more than one way.

If you request the same thing in application/activity+json format then you get exactly the same resource, but in machine format. Lemmy apps use that for example to display the content natively and completely bypass the web application part of it.

The browser very well could say it accepts both ActivityPub and HTML format, in which case the server would serve the ActivityPub that the browser could display using some native implementation. And bam, there's no longer an application+resource tie.

I don’t get what is the “application” in this context. Is that the Lemmy server or kbin server, which use the ActivityPub protocol? And couldn’t this be solved with a sort of .apub at the end of each resource, like the .json used to work for Reddit?

Application being the Lemmy UI I would guess.

No need for .json or .apub, that's already handled by the Accept and Content-Type header.

Just happens that the browser requests HTML, which loads lemmy-ui, which then requests exactly the same resource again but this time in ActivityPub format, which returns the data as expected in the standardized format.