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 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 and chosen by the operator of that server.

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

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.1

Web (of hypertext documents)Chosen by user (web browser)Specified by address bar
Federated application built on the web (current)Specified by address barSpecified by address bar
Federated application built on the web (ideal)Chosen by userSpecified by address bar
Coupling of application and resource identifiers

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 can be used to access a resource such as by constructing the URL 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 (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://, 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.

1. Since this involves a way of registering some HTTP(S) resource as a handler for another URI scheme, it would be nice to solve the web cryptography problem at the same time and include a way to bind a root of trust for an application identity.