Bridging identity with account links

One of the most common questions we get here is, “can you help me connect all my different accounts?” You’re on Bluesky, and Instagram, and Mastodon, you make a video series on YouTube, you have a blog, sometimes you post on Reddit, and a while back you set up a Linktree to connect them all. Half of your accounts are inactive, the other half you copy and paste between all the time. At least once a day, you open a notification in one place, only to end up in a different place altogether, with no way to connect the two.

There must be a better way, right?

We hope so! It’s a big, gnarly, multi-faceted problem. We ran a session on it at FediForum, back in June, and came away with a great set of draft user stories and future directions. Today, we want to focus on one technique we’ve been using in Bridgy Fed and Bounce: account links.

One universal standard

Often, when people think about consolidating their identities online, they think top-down. If the problem is too many different accounts, one obvious solution is to make a new, meta account that knows them all and connects them all together, right?

It’s a good thought! FriendFeed, Plaxo, Linktree, HootSuite, and countless other social network aggregators have taken a swing at it over the years. The catch is, this just crowns a new central authority, with control over all of your accounts. It might work, but here in the open social web, we tend to prefer things less centralized. With apologies to David Clark and the IETF: We reject kings, presidents, and voting. We believe in rough consensus and running code.

The natural next step is to take this meta account service and turn it into an open standard. A noble, worthy idea! WebFinger, DIDs, OpenID, PGP keyservers, and many others thought so too. Enter XKCD 927.

So if thinking top down can lead to over-centralization and over-standardization, we wondered about the other direction. What’s the smallest thing we could do, bottom up, without introducing another central authority or standard?

Account links

We immediately thought of profile links. Many social networks let you include links in your profile: your web site, Linktree, Patreon, etc. These are aimed at human users, but we knew that there were machine-readable corollaries: places in each account’s underlying data where they can link to other accounts, on other networks. The web has rel=me, the fediverse has alsoKnownAs, Bluesky also uses alsoKnownAs (also check out their 2022 Satellite contest), Nostr has NIP-39, etc.

Let’s look at an example. Anuj is @quillmatiq@pixelfed.social on Pixelfed. That account is bridged to Bluesky by Bridgy Fed, which publishes an account link back to the Pixelfed account in the Bluesky account’s DID document, via alsoKnownAs:

  "alsoKnownAs": [
    "at://pixels.quillmatiq.com",
    "https://pixelfed.social/users/quillmatiq"
  ]

The second element there, https://pixelfed.social/users/quillmatiq, is the Pixelfed account’s ActivityPub actor id. Any Bluesky client or app can read this DID document, fetch https://pixelfed.social/users/quillmatiq, see that it has a link rel=alternate type=application/activity+json, and use that to find and show the Pixelfed account. Here’s an example mockup based on bsky.app; note the Pixelfed logo and linked handle.

This works in both directions. Anuj’s Bluesky account is bridged to the fediverse, and its bridged ActivityPub actor includes this:

"alsoKnownAs": ["at://did:plc:xgvzy7ni6ig6ievcbls5jaxe"]

Fediverse clients and apps can fetch that DID document, see that it’s a Bluesky account, and link users to it. Bridgy Fed already even includes that user-visible link! Clients just need to match it to alsoKnownAs, detect that it’s a Bluesky account, and show a visible indicator. Here’s an example mockup, based on Mastodon’s web UI.

Bidirectional verification

The other useful thing to do with these account links is bidirectional verification. Anyone can claim that they’re a given account; you only want to trust them if that other account agrees. Platforms can support this by publishing links in both directions, from each account to the other. Clients can then verify by loading both accounts and checking both links.

For example, my web site snarfed.org is bridged into the fediverse as ActivityPub actor https://fed.brid.gy/snarfed.org. Bridgy Fed includes it in the actor’s alsoKnownAs:

  "alsoKnownAs": ["https://snarfed.org/"]

In return, snarfed.org links back to that actor with a rel="me" link:

<a rel="me" href="https://fed.brid.gy/snarfed.org"></a>

When clients see my fediverse account, they can fetch the alsoKnownAs URL, look for the rel="me" link, see that it points back to the actor, and confirm that this site and that fediverse account are legitimately the same person. Likewise, if they start from this web site, they can follow the rel="me" link and do the same check.

Mastodon already does this! If you add a profile link to your web site, and then link from your site back to Mastodon with rel="me", Mastodon shows that link with a green check. Account links in the wild! We love to see it.

Mastodon and Pixelfed users can even set their own account links. The fediverse’s term for these is aliases; here’s how to set them in Mastodon and Pixelfed. Bluesky’s bsky.app client doesn’t have a way for users add aliases to their DID docs yet, but it’s a straightforward feature that any Bluesky client could add.

Next steps

There’s lots more to talk about. There are post links too, which you can use to connect posts across networks. Multi-protocol clients can use these links to show every account and post natively, regardless of where it first came from. You could use account links to build an identity aggregator that detects and sets up all of your accounts for you. And so on.

There’s also more work here for the ecosystem to do. Account and post links aren’t supported in all networks yet. Bluesky doesn’t have a standard field for post links; Farcaster doesn’t seem to support either kind. Also, some networks lack a way to specify the “canonical” (ie native) version of an account or post.

Regardless, we propose account links as one modest, bottom-up starting point for connecting our myriad identities online. They don’t solve all problems. They’re not a grand vision. But they do help the open social web say, hey, this person here? They’re also that one over there. And they help apps surface those connections to users. We think that’s useful.

If you’re a developer, and this piques your interest, check out the Bridgy Fed docs for more details, and feel free to reach out to us, we’d love to work with you!

Specifically, if you work on a social web platform, client, or bridge, here are our recommendations:

• When you see a new account, check whether it has any account links. If it does, show those links to the user.
  • Bonus: include the logo for each linked account’s network.
  • Bonus: fetch the linked account(s) and check that they have link(s) back. Include user-visible indicators on the links that verify.
• Do the same for posts and post links.
• Let your users set their own account links (aka aliases).
• If you cross-post or bridge, set account and post links automatically.
• If an account or post specifies its canonical version, prefer to fetch and render that version, since it will usually have the highest fidelity.