Domain names as handles #23
$ dig _atproto.bmann.ca TXT ... ;; ANSWER SECTION: _atproto.bmann.ca. 270 IN TXT "did=did:plc:2cxgdrgtsmrbqnjkwyplmp43" ...
- My proposal would be
- dns txt record points to actor id
- preferredUsername starting with an @ is interpreted as domain; probably should use something else for backward compatibility. Settling on the term to use is probably the hardest part.
Note did-web does not use DNS records, so it does not do what I want here.
Blaine's Name Name System might be relevant see: https://mitra.social/post/018791b2-4dde-067b-2086-53a11c5e895e
preferredUsername starting with an @ is interpreted as domain; probably should use something else for backward compatibility. Settling on the term to use is probably the hardest part.
We could look at Nostr for additional ideas. They decided to use
_ as the indicator of a username that shows you'd prefer to use your domain name as your identifier:
Clients may treat the identifier
_@domainas the "root" identifier, and choose to display it as just the
<domain>. For example, if Bob owns
bob.com, he may not want an identifier like
email@example.com that is redundant. Instead, Bob can use the identifier
firstname.lastname@example.org expect Nostr clients to show and treat that as just
bob.comfor all purposes.
Is this relevant to this discussion? Would seem so on the face of it to me but others know the specifics of what would be possible under ActvityPub:
The short answer is: Not an ActivityPub issue.
The long answer is: Yes, it is possible. As I discuss here the main issue is how to specify what username to display. The proposal there would be:
- Introduce a new property for the Actor
- Servers should verify the validity of the entries
- Clients, i.e. an App, should display the first entry
Following RFC 4501 one would add
dns:_apobjid.alyssa.cool?type=TXT as the first entry of
aliases to specify that
@alyssa.cool should be the username.
Once a technical solution is described all that remains is hope people implement it. It should be an "easy" patch to have the Mastodon API return whatever is the first entry of
aliases as the "acct" parameter. After looking at the Mastodon code, one probably needs to add a database row "preferred identifier" or something to support custom domains as identifier. The rest for displaying a DNS name should work out of the box. (One also needs verification, but that's straightforward to code).
The bigger trouble will be to get setting the aliases build.
I met Blaine at a conference and he joked about how lame it was that "the only business model anyone seems to have found for identity is selling people their names to them."
In a separate but related announcement, Bluesky shares more about how the Namecheap paid service will work — by allowing users to pick out a domain name of their choosing and then link it to their Bluesky account.
Related discussion at Mastodon issue tracker: https://github.com/mastodon/mastodon/issues/22213#issuecomment-1745358403
email@example.com is proposed as an equivalent of
@domain.tld; replacement can happen on the client side.
My concern regarding the client-side "desugaring" approaches is that they might give a wrong impression of "authority" if the server is unaware of the convention and assigns the "special" username to an unprivileged user. At least, Mastodon seems to assign the
@_ username to unprivileged users (e.g. https://mastodon.social/@_).
As for the
@* username proposed in the Mastodon issue, I don't know if there are any (major) services out there that let unprivileged users register with the username, but even if not, I'd still believe there should at least be additional precautions like updating related specs (maybe the ActivityPub recommendation?) to specify that the ActivityPub Federated Server SHOULD NOT assign the special
preferredUsername to unprivileged actors and the WebFinger server SHOULD NOT respond with the special JRD subject for unprivileged ActivityPub actors, mentioning to the convention, so that future implementors are aware of it.
I think "client-side" hacks miss the point. Sure you can do
acct:firstname.lastname@example.org should be represented as
@domain.tld, but what's the point?
The point of https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-612d.md is:
- You control your DNS entry => you can use it as an identifier
- You do not need to configure some webfinger stuff
- You do not need to host your own server
- You only need to update the DNS entry and have your server change your default identifier
The only thing missing from a specification point of view is adding a default identifier property to actors. The rest is defined in FEP-612d.
Of course, then you need to unravel the "identifier to display" logic in Fediverse applications and pass the information along to clients. That's hard work. Fortunately, it is work that needs to be done.
Unfortunately, there is a lot of preliminary work that needs to be done. In the above picture: The default identifier associated with an actor is defined by the user and can be changed. This means that Fediverse applications cannot rely on it to search for past entries. The user might have changed his identifier. This leads to all kinds of problems that are tedious to solve, as one needs to define consistent logic.
For the moment, one could get around these problems by
- requiring that the URL the Actor object can be retrieved needs to stay constant. Unfortunately, this means your logic breaks if you want your user to be able to migrate between users.
- or use cryptographic identifiers, which would mean the user needs to keep a cryptographic secret
I don't like the first solution. I don't think the second solution meets the usability requirements, we want for the Fediverse.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?