A Better Scheme for the Fediverse?

Like many others, I’ve recently joined Mastodon, a collection of servers implementing a distributed Twitter-like social media service, using a protocol called Activity Pub. Like Twitter, you can view your timeline via an app or via a web browser.

Unlike Twitter (or virtually every other social media platform), the URLs can point to an unlimited number of host names and domains. And therein lies one of its weaknesses: you (or a computer) can’t just look at a URL and know that it points to a Mastodon server or post. All Mastodon URLs start with https¹, but anyone can stand up a Mastodon instance in any domain and fully participate.

This means that a single app can’t field all links to Mastodon posts or users, because the OS selects an appropriate app to handle the URL based on the hostname.

However, most OSes also support the notion of selecting handlers based on the URL scheme (the first part of the URL, like https). I wonder if a new scheme idenitifying Mastodon URLs would be useful here. I initially suggested masto, but didn’t particularly like that. @byterhymer@mastodon.social suggested fedi or ap, and while I tend to prefer ap, it might not be the best choice, either². Then again, I’m not entirel sure it matters that much, so long as we all agree to what it should be.

The list of schemes is much longer than I realized, and some are definitely not protocol-oriented (e.g. paparazzi). So maybe masto or fedi is fine. But let’s assume it’s ap.

Treatment

How does an ap: URL get handled? That depends on the client making the request, and I think there are some choices that can be dictated by the Accept HTTP header. Accept: text/html would result in the HTML markup for the given resource (a post or user’s profile, for example). An Accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams" would return ActivityPub content.

It also depends on the OS: OSes should have a default handler set up for the ap scheme, and launch that handler when appropriate.

In Practice

To make this useful, serveral things would need to fall into place:

• Web browsers would have to understand the new scheme, and make a request for HTML content on port 443 by default (a detail to be hammered out is how to make an insecure request).

• Mastodon servers need to redirect https:// links to ap:// links, and someday to directly render ap:// links in their pages.

• OSes would have to invoke the appropriate handler app for the scheme.

• Other apps might need to learn about the scheme. If I send someone an ap:// link in Apple Messages, it (annoyingly) renders a preview.

Redirection

Since there are millions of existing https:// Mastodon links, there needs to be a way to optionally redirect to them. Mastodon instances could respond to https:// links with an additional header, e.g. AcitivtyPub-URI, that informs the user agent that the resource is a Mastodon link. A savvy user agent would then open the provided ap:// link, which would cause any installed app to be opened.

Caveats

There’s at least one aspect I’m not sure about: I think Apple discourages app developers from implementing custom URL schemes. Perhaps this concern doesn’t really apply in this case, as it would really be a well-known scheme, able to be handled by a multitude of apps.

I’m sure there’s more to this, but I wanted to get some quick thoughts down.