The problem with federated web apps

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.

Let's take the Fediverse as an example. Suppose some user profile is hosted at https://example.com/johnsmith. This URL can be used by Fediverse clients to retrieve machine-readable profile information, but visiting it in a web browser, or clicking a link to it from some other location, results in loading a specific application served from example.com and chosen by the operator of that server.

Thus, when accessing a profile at example.com, the “application” used to view the profile is chosen by the operator of example.com. Yet when accessing a profile at example.net, the application used to view the profile is chosen by the operator of example.net.

The problem basically comes down to this: the web was built as a federated platform. That's literally what the address bar facilitates — the web browser is the application, and that browser is used consistently and uniformly between different sites. This model works well for a web of hypertext documents, as was the original vision. But this model breaks down because it wasn't designed under the premise that interactive applications would then be built on top of individual websites, and then a whole second level of federation would be built on top of that.

In order to solve this problem, you would need to decouple the resource being accessed from the application being used to access it. This already works well enough for the web itself; it seems like this could be facilitated for other protocols using a new URI scheme.

For example, suppose a browser allows custom URI schemes to be registered, e.g. apub://, and specifically allows that URI scheme to be bound to an internal HTTPS URL which is loaded to serve as the handling application. That page then handles navigation events to apub:// URLs. If the user eventually navigates away to an http:// or https:// URL, the page is unloaded and standard HTTP navigation is handled as usual. This would enable the decoupling of applications from resources and allow users to exercise choice in what applications they use to access a given resource.¹

Could anything useful be done about this in the absence of such browser support? The only options which immediately occur to me are:

• Hack it using an URL fragment, so an application hosted at https://example.org/ can be used to access a resource such as https://example.com/johnsmith by constructing the URL https://example.org/#https://example.com/johnsmith. This is ugly, makes it hard to copy URLs without “localising” them to a specific application, and requires users to mangle URLs into this format rather than just pasting them into an address bar. Not great.

• Double address bar. In this pattern, an application is hosted at https://example.org/ (and this pattern may be combined with the above pattern). The top of the application shows an address bar with the resource URI (e.g. apub://example.com/johnsmith), so the user can navigate in a browser-like way using an address bar interface. The use of two address bars is liable to be confusing to novice users. It is at least possible to register an URI handler for apub:// or so on using JS APIs.

• Browser extension. I don't believe modern WebExtensions are powerful enough to support implementing custom URI schemes, sadly, unlike their predecessors for Mozilla-derived browsers. But it should potentially be possible to detect web pages which correspond to federated resources and redirect to the correct application automatically. This again can be combined with either or both of the above patterns.