Smoke Signal

Extending Also Known As

Posted 2024-11-21 11:00 ‐ 3 min read

ATProtocol has a simple and direct way of binding and displaying identity through hostnames (domain names). The process is beautifully simple and shows bidirectional consent: First, you must prove you have the authority by hosting a file or setting a DNS record. Once your PDS can resolve your DID through either of those methods, your DID document is updated and cryptographically signed to prove you initiated the connection.

But let's examine one specific component of the did-plc1 document that could lead to some handy features: alsoKnownAs

The "alsoKnownAs" attribute is a list of AT-URIs the DID can go by. At this time, that list only has one element: the handle that a DID primarily resolves to. It is used in that bidirectional consent as the look-up hostname should be the first element in the list. If it isn't, then something wasn't configured correctly.

Extending The List

When I think of my online identity as @ngerakines.me, it includes all the places I choose to present myself. For better or worse, most of my handles are simple "ngerakines" because they are unique and easy to grab.

On ATProtocol, my "ngerakines.me" identity isn't any more or less important than my GitHub identity (also "ngerakines"). I think of them as associated with each other, or to phrase it another way, my GitHub "ngerakines" is an identity that I'm also known as.

A simple and immediate change we could adopt in the ATMosphere is to support multiple elements in that list. It would immediately solve several key things:

  1. For users on the bsky.network troop, it would allow them to have their primary PDS identity ("celebrity.bsky.social") and a vanity handle ("celebrity.great-film-studio.tld") to prevent squatting.

  2. It would allow users in organizations to have their personal handle ("john smith.bsky.social") as well as their organization handle ("john smith.astrenox.coop").

For Users

The user experience for people and organizations with multiple handles is small and subtle.

A mockup of the bsky.app profile with multiple handles

To view a handle's profile through an app view like "bsky.app", use any of the resolvable hostnames. The first element of that "alsoKnownAs" is considered the "primary" handle for display purposes. Additional hostnames along with an "and others" would be displayed.

For Developers

The change necessary to support this should be minimal for applications and tools that resolve identities. Instead of checking the first element of the "alsoKnownAs" value to compare against a hostname, you should check if the list contains the hostname.