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
“tim@example.com”. Paste mailto:tim@example.com
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 @timbray@mastodon.cloud 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 Eugen is right about support for alternate schemas in Web browsers being weak, but not all of them. 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.
Comment feed for ongoing:
From: J Banana (Apr 21 2025, at 03:13)
You said "...patchy browser support is a problem..." but I'm not sure that's right. I had to configure my operating system to accept a new URI scheme, not my web browser (details here: https://portal.mozz.us/gemini/freeshell.de/windowsprotocolhandler.gmi ) and that feels like something that a local client install could/should deal with.
[link]
From: Scott Laird (Apr 21 2025, at 10:19)
The problem is that we'd really *like* a `fedi://example.com/...` URI to work out-of-the-box for users who don't have any specific handler installed, but there might be an interesting solution here, with a bit of heavier-weight standards-wrangling.
In an ideal world, Chrome, Safari, FF, etc would all recognize `fedi:` URIs and just fall back to `https` if there's no explicit `fedi:` handler installed, but that feels like weird special case logic that a lot of browsers would (rightly) push back on.
If, instead, we used something like `web+fedi` or `https+fedi`, *and made that a standard pattern*, then browsers could have a well-defined fallback behavior. You can install a specific handler for that scheme, *or* the browser will treat it as equivalent to `https`. This would probably be generally useful for a lot of things-that-sit-on-HTTP.
Looking through the IETF scheme list, `web+ap` is the only scheme that fits this basic pattern today, so we'd probably be free to pick something with a less ugly naming pattern. IMO `https` is clearer than `web`, because it makes the fallback explicit, instead of having to play implied-https-but-maybe-possibly-http games.
[link]
From: Sami Samhuri (Apr 21 2025, at 10:28)
> But on Android, any app can register itself to handle URIs of a particular scheme. I assume iOS has something similar?
Sadly iOS has continued to ignore this problem and it's basically chaos. The first app to be installed that handles a scheme just gets to own it, or not, who knows. It would be amazing if they'd just do exactly what Android does.
[link]
From: Scott Laird (Apr 21 2025, at 10:49)
There's also a related (but not identical) use case here -- I've wanted to have Fediverse-integrated comments on my blog for a while, but the UX is just too much of a pain. In an ideal world, I'd have a "comment" link that sent the user to their own Fediverse server, where they could comment on a Fediverse version of my post, and then the comment would be sucked up and displayed on the blog. Then for non-Fediverse users, there'd be a more traditional commenting option, because "sign up for Mastodon to comment" seems antisocial.
The problem is that there's no way to say "respond to this on your Mastodon instance" today without requiring the user to provide a link themselves, which is ugly and has too much friction.
Having a `fedi://` or `https+fedi://` or whatever scheme would fix a big part of this. There are a couple other ways that I can see to accomplish the same thing, but none of them really seem as practical.
[link]
From: Jan (Apr 21 2025, at 12:05)
Hey, you seem to focus on Mastodon and Bluesky here, but have you ever considered using NOSTR (it’s a protocol) for sharing in a user centric and decentralized way?
It’s unfortunate that with true decentralization there can’t be a perfect way of getting every message to every follower instantly. But maybe that is a trade-off that you’re willing to tolerate?
[link]
From: Robert Sayre (Apr 21 2025, at 13:12)
It's Zooko's Triangle, right?
[link]
From: Nik (Apr 21 2025, at 13:49)
Scott Laird said:
> In an ideal world, Chrome, Safari, FF, etc would all recognize `fedi:` URIs and just fall back to `https` if there's no explicit `fedi:` handler installed, but that feels like weird special case logic that a lot of browsers would (rightly) push back on.
I think there's no reason why that couldn't happen. The `mailto:` handler on my Chrome just opens Gmail because that's my configured client, not a desktop app. I don't remember now but it's possible that's the default.
Chrome knows that:
* I'm logged in with my Google Account
* That Google account has a Gmail address
* No other app handler is configured for the protocol
So it just opens Gmail.
The major browsers could absolutely implement that for `fedi:` and `at:`. The challenge would be to decide what is the "default" client. Maybe until there's an "open source" fediverse/at protocol viewer, it would get bogged down in minutia or analysis paralysis?
[link]
From: anon (Apr 22 2025, at 06:09)
In not exactly sure I understood what is the problem you are trying to solve.
You know, there used to be a time when there were a lot of uri schemes: http:, ftp:, uucp:, ldap:, ssh:, xmpp:. Now that we are encapsulating everything into http, which is just a bunch of headers in plain text, we finally don’t need any of that chaos, and moreover, most things are now in a browser anyway.
I think that what is really needed are a couple of browser extensions, not a new uri scheme.
[link]
From: Joe Germuska (Apr 22 2025, at 10:45)
tbray wrote:
“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.app, it’d be perfectly tractable (I think).”
For your example post, the ATproto URL is at://tbray.org/app.bsky.feed.post/3lmxrkmwz5k2u
Handlers don’t even need to worry about `bsky.app`; they’ll just resolve the location of your PDS server and ask it directly.
Now the cool thing I’m waiting for is something that can resolve a root ATProto URL like `at://tbray.org` into any number of resources you choose to advertise (like handles on other services or whatever really). From there it’s also a tiptoe of a step to generating a linktree-style human-readable web page that does the same. Handlers just need to coordinate on specifics of how things are structured in the DID document.
[link]
From: Giles Edwards-Alexander (Apr 23 2025, at 14:17)
As Scott points out, inventing a new scheme requires special case handling in browsers for when there is no suitable local handler. It also hangs out to dry browsers that haven't been updated to the new scheme.
This doesn't feel like something that needs a new scheme. HTTP is an app-level protocol. Could this be done by standardising on content types, and then using content negotiation and multiple accept types?
A browser could have a configured database of MIME types it handles, or has third party handlers registered for. When sending a request, it accepts all those types. The server picks one and responds with that type, the browser then routes that to the correct handler.
That is, the Fedi post is a new content type. If a user has an app installed, the browser sends that when it follows a link from a web page. When the server responds, with that type, the browser kicks the user over to their installed handler. Then the user can stay in that app.
Back when Apple started routing requests based on domain in about 2011, I argued for something similar. But, not working for Apple, and never getting around to writing it up, it went nowhere. I still think there is something powerful in handling the *documents* at the URLs specifically, and not overloading the URL.
[link]
From: Matěj Cepl (Apr 24 2025, at 09:17)
What's even more fun is that for me in my Firefox there is
https://en.osm.town/deck/@timbray@mastodon.cloud/109508984781213507
which is completely insane.
[link]