I’m a fan of decentralized social media and that’s partly because I enjoy using it. But mostly because history teaches that decentralization is the best basis for sustainable, resilient online conversation. (Evidence? Email!) For the purpose of this essay, let’s assume that you agree with me. Let’s also assume that our online life is still Web-flavored. I’m going to describe a few unfortunate things that can happen in a decentralized world, then look at a basic built-in feature of the Web that might make the problems go away.

Let’s start with bad-experience scenarios

Sharing pain · Suppose I post a picture to my social-media feed and since Ash follows me, it shows up in their stream. They can favorite or boost it, but let’s suppose they think their friend Layla might like it too, so they grab the link and drop into their chat window with Layla, or maybe they send her an email.

By “link” I mean “URL”, and by “URL” I mean “URI” (the distinction will matter in a bit). Here’s what that looks like, first on the Fediverse:
https://cosocial.ca/@timbray/114361121438267145
And on Bluesky:
https://bsky.app/profile/tbray.org/post/3lmxrkmwz5k2u

Layla sees the link and clicks it or taps it and yay, there’s the picture. She dislikes it and wants to add a negative comment. On the Fediverse, if it turns out she’s logged onto CoSocial.ca like me she’ll have no trouble, she can fire away. If she’s logged into another instance (and the Fediverse has thousands) she’s out of luck, even though she’s got a live Fediverse session. She can paste the URL or just “@timbray” into her search window and that might get her there indirectly if she’s lucky.

This is a bad experience.

On Bluesky, it’ll probably just work. Well, for now. Because while Bluesky is based on the AT Protocol (ATproto for short) which is in theory decentralized, at the moment Ash is logged into the “App View” at bsky.app just like I am, because in practice everybody on Bluesky is.

But in a future where there are multiple ATproto App Views, which is to say when Bluesky becomes as decentralized as the Fediverse is today, we’re back with the Fediverse problem, because her browser doesn’t know that the URI identifies an ATproto post that she should be able to boost or like.

Client pain · There’s another problem in this scenario. Suppose Layla was logged into CoSocial.ca, but she wasn’t using the default Mastodon client, but rather an alternative such as Phanpy or Elk.zone. When Layla clicks on that link she won’t be in her fave Fedi client but back in vanilla Mastodon.

Not a good experience.

Post portability pain · Let’s look at the URI for a different Fediverse post of a pretty picture:
https://mastodon.cloud/@timbray/109508984818551909

It’s one of my posts all right, but it’s not from cosocial.ca, it’s from mastodon.cloud, which was my first home on the Fediverse. I left it in December 2022 because it was sold to another company which is sketchy, by which I mean Lolicon-friendly.

Whatever I think of whoever’s running mastodon.cloud, I have a lot of posts over there, some of which I care about. For now, they’re still there, but I’m not contributing any money to those guys, nor will I, so if they pull the plug and vanish I can’t complain. Only if they do, so do all those posts that I cared about back then and still do a bit.

Another bad experience.

URIs and schemes · [Anyone who already understands URIs schemes and so on can skip to the next section.]

Let’s look at that Fediverse link again:
https://cosocial.ca/@timbray/114280972142347258

I call it a “URI” because that’s the official name for what it is. What they look like and how to use them are very thoroughly specified in several Internet Engineering Task Force publications starting with RFC3986. URLs are also URIs, but URIs can do surprising things that you’ve probably never seen in the world of ordinary URLs.

The crucial thing about both the Fediverse and Bluesky URIs is that they begin with the magic letters “https” followed by a colon. All URIs begin with a short string and a colon; the string is called the URI scheme. For each possible scheme, there’s a set of rules saying how to handle URIs of that flavor. If it’s “https”, then the rules say, using that Fediverse URI as an example, to make an encrypted connection to the server at cosocial.ca and ask it to send you /@timbray/114280972142347258. You’ll get some bytes that represent what the URI identifies.

[Yes, I’m oversimplifying. Sorry.]

While most of the URLs you’re ever likely to encounter begin with “https:” there are other schemes. Suppose your email is “[email protected]”. Paste mailto:[email protected] into your browser, hit Enter, and see what happens. This is a URI whose scheme is “mailto” and it works just fine.

When I tried this just now on my Mac, all three of Safari, Firefox, and Chrome noticed that I use the Mimestream mail app and popped that up. Which shows that somewhere in this computer there’s a notion of a registered handler for a particular URI scheme. Which is exactly what URI schemes were designed for.

I mean, if I can install an email app to handle mailto: URIs, why can’t I install a Fediverse app to handle fedi:?

There are lots of URI schemes! Here’s the official registry. Now, most of these are marked as “provisional” which means “we’re just reserving this scheme because we think we’re going to use it” and even among the ones that aren’t provisional, very few of them are in widespread enough use that you can expect your browser to handle them.

You’ll notice that the at: scheme is in there, registered by the Bluesky people (after I suggested they do so). For the Fediverse, I see web+ap: (which I’d never heard of before starting to write this).

Let’s suppose that there were URI schemes for both ATproto (at:) and the Fediverse(I suggest fedi: rather than web+ap: for reasons I’ll discuss later). Let’s also suppose that they were well supported by operating systems and browsers. I claim that this would help solve all three of those pain scenarios.

Solving sharing and client pain · Remember, Ash copied the URI for a post and dropped into their chat window with Layla; when Layla clicked it, she saw the post but couldn’t boost it or reply to it.

But suppose it began with either at: or fedi: — then the computer or mobile would dispatch to whatever Layla uses to interact with ATproto/Fediverse software, and it’d know how to go about opening that post in the way Layla expects so she can reply and boost and so on. I’m ignoring the details of how that’d work, and some of them are tricky, but this could be done.

Solving migration pain · This is a little more ambitious, but remember that “mastodon.cloud” post that might go away some day if the server does? Suppose we change it slightly, like so:
fedi://mastodon.cloud/@timbray/109508984818551909

Once again, because it begins with “fedi:” not “https:”, the job would be handed off to Fediverse-savvy software. And since the Fediverse already knows how to migrate accounts from one server to another and bring your followers along, why shouldn’t it also copy your posts and store them somewhere, and when it hits that URI, remember “Oh wait, that @[email protected] handle migrated a couple of times but that’s OK, I still have the posts from the old servers stored away so I can fetch that post rather than just giving up because mastodon.cloud went away”.

Now, as far as I know, Mastodon doesn’t have any capabilities like that, nor does any other Fediverse software. But once again, it’s a thing that could be done. And if we have a new URI scheme, there’d be a hook to hang that kind of software on.

At the moment, ATproto/Bluesky is a lot closer to being able to do this. Your ATproto account isn’t tied to the server you happen to be logged into when you posted it, it’s a long-lived asymmetric-crypto based thing and it assumes that there’ll be per-account storage not tied to any particular App View. Also posts are identified by content hash, which should be helpful.

But as far as I know, even with ATproto, if my browser’s visiting the bsky.app App View and I shoot a URL beginning with https://bsky.app to someone on the blacksky.web.xyz App View, I don’t see how the browser can figure out that that URL should invoke ATproto software.

But if it began at://bsky.capp, it’d be perfectly tractable (I think).

Scheme details and problems · There multiple proposals for a Fediverse URI scheme. I already mentioned web+ap: and then there’s web+activitypub: from silverpill (which may be the same?), and fedi: from me. The “web+” ones are more descriptive but mine is cooler and I think that matters. The proposals include useful discussions of the issues, which include those discussed in this essay; if you care about this stuff I think both would reward a read.

I also have to note this from Mastodon author Eugen Rochko back in 2022: “We've done this before but removed because browser support / UX was inadequate.”

(Before I go on I should point out that while Eugen is right about support for alternate schemas in Web browsers being weak. But on Android, any app can register itself to handle URIs of a particular scheme. I assume iOS has something similar? So this isn’t completely science-fictional.)

So using URI schemees isn’t a new idea and yeah, patchy browser support is a problem. The people who build Safari and Chrome and Firefox are busy and are fanatically concerned with security and stability for their billions of users, and if I go and tap them on the shoulder and say “Here are new schemes and here’s the decentralized-social-media software I want registered to handle them” they’re not gonna to just say “Okay” and do it.

Bit I dunno, the times they are a changin’. As Bluesky and the Fediverse build momentum, and the decentralized path forward looks more and more attractive, the case for new URI schemes probably becomes easier to make.

As it should. Because the notion of the URI is a core foundational piece of the Web’s architecture, and the design of URIs has multiple protocol support baked in, and the URI schemes exist specifically to enable it.

So, we should work on using it.