Domain names as handles #23

Open
opened 2023-04-17 06:11:06 +00:00 by helge · 10 comments
  1. People seem to want it, see here
  2. It should be easy. See here
$ dig _atproto.bmann.ca TXT

...
;; ANSWER SECTION:
_atproto.bmann.ca.	270	IN	TXT	"did=did:plc:2cxgdrgtsmrbqnjkwyplmp43"
...
  1. 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.
  • BAM!
1. People seem to want it, see [here](https://social.treehouse.systems/@ariadne/110212271790484173) 2. It should be easy. See [here](https://bmann.ca/bluesky-and-domains/) ``` $ dig _atproto.bmann.ca TXT ... ;; ANSWER SECTION: _atproto.bmann.ca. 270 IN TXT "did=did:plc:2cxgdrgtsmrbqnjkwyplmp43" ... ``` 3. 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. - BAM!
helge added the
FEP
label 2023-04-17 06:11:06 +00:00
Poster
Owner

Note did-web does not use DNS records, so it does not do what I want here.

Note [did-web](https://w3c-ccg.github.io/did-method-web/) does not use DNS records, so it does not do what I want here.
Poster
Owner
Blaine's [Name Name System](https://talk.fission.codes/t/nns-the-name-name-system/3684) might be relevant see: https://mitra.social/post/018791b2-4dde-067b-2086-53a11c5e895e
Poster
Owner
See https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-612d.md

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 _@domain as 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 bob@bob.com as that is redundant. Instead, Bob can use the identifier _@bob.com and expect Nostr clients to show and treat that as just bob.com for all purposes.
-- 544095d23f/05.md (showing-just-the-domain-as-an-identifier)

> 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 `_@domain` as 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 `bob@bob.com` as that is redundant. Instead, Bob can use the identifier `_@bob.com` and expect Nostr clients to show and treat that as just `bob.com` for all purposes. -- https://github.com/nostr-protocol/nips/blob/544095d23fe6521f46242137c7dbe77918254ec8/05.md#showing-just-the-domain-as-an-identifier

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:

https://indieweb.social/@manton@manton.org/110346703502552278

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: https://indieweb.social/@manton@manton.org/110346703502552278
Poster
Owner

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.

The short answer is: Not an ActivityPub issue. The long answer is: Yes, it is possible. As I discuss [here](https://codeberg.org/fediverse/fep/src/commit/b38615015cc5fb8dab9a22f67374f653641bbc0e/feps/fep-4adb.md#preferred-account) 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](https://www.rfc-editor.org/rfc/rfc4501.html) 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.

Src: https://techcrunch.com/2023/07/05/bluesky-announces-its-8m-seed-round-first-paid-service-custom-domains/

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. Src: https://techcrunch.com/2023/07/05/bluesky-announces-its-8m-seed-round-first-paid-service-custom-domains/

Related discussion at Mastodon issue tracker: https://github.com/mastodon/mastodon/issues/22213#issuecomment-1745358403

_@domain.tld is proposed as an equivalent of @domain.tld; replacement can happen on the client side.

Related discussion at Mastodon issue tracker: https://github.com/mastodon/mastodon/issues/22213#issuecomment-1745358403 `_@domain.tld` 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.

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.
Poster
Owner

I think "client-side" hacks miss the point. Sure you can do acct:_@domain.tld 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.

I think "client-side" hacks miss the point. Sure you can do `acct:_@domain.tld` 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.
Sign in to join this conversation.
There is no content yet.