@fediforum@mastodon.social
@fediforum.org

FEP Draft: IDs, Handles, and Multi-discoverability Use Cases

/2025-10/session/5-a/

Convener: bumblefudge.com

Participants who chose to record their names here:

Website:: https://notes.learningproof.xyz/bGqOKQcfQWycyjJGMUcSaA?view#

Notes

  • Discussion on mailing list about replace WebFinger
  • id property of Actor is the canonical identifier of a user
    1. “loud party discovery” verbally share how to find you online
    2. client and domain independent discovery. “Search for my handle with a specific type of client”
    3. self-managed domain discovery. Solve Impersonation, verification by using your domain as your username on any system
    4. Machine verifiable identification ocross networks,
    5. How do you deal with Mastodon only seeing WebFinger even if you do something different?
    6. Inactive accounts point to active account
    7. Handles on dead servers
  • Discussion: Interest in domain as handle with indirection of where the content is hosted. Reuse domain as identity, don’t want to have to host own server.
    • Service domain and handle
    • Ryan: split domain? https://correct.webfinger-canary.fietkau.software/
      • Yes, split domain is how I’m doing it, so if the service domain is social.example and I’m thisismissem.social.example as the “handle” within the context of AT Protocol’s design, then the webfinger is @thisismissem@social.example instead of @thisismissem.social.example but it really just redirects to @thisismissem@pds.example
  • Jim: User stories 1 and 2 assume same-language; localization might be relevant to specify.maybe a sep user story is common-lang or way to make explicit which language the domain/username is in . Multi-language variations of handles?
    • Loud party story specifically assumes both people can communicate the name by speaking and hearing, then the second person can write what they heard. Thus: they involve spoken language and written language.
    • Some kinds of characters are hard to speak or write. e.g. Emoji characters are difficult to write.
    • Issue of punycoding with URI reducing it to ASCII for machine communication, but plain text (punycode decoded) version to people to read
    • jim: punycode was applied to the username/handle section, but % encoding might be enough there; punycode/IDN was invented for ICANN
    • handles need ot be localized/punycodable, but ids might be fine to keep ascii/machine-readable
    • Ryan: Discussion seems to be desiring domains as usernames rather than @user@domain
  • Michael: intereted in #3. Feels like one thing Bluesky did well.
  • DNS “Label Generation Rules” as prior art of restricting sets of character usable for a certain class identifier (in this case, domain names). Starting point: Second-Level Reference Label Generation Rules https://www.icann.org/en/contracted-parties/registry-operators/second-level-reference-label-generation-rules-21-06-2015-en.
  • Ryan: https://github.com/mastodon/mastodon/issues/22213
    • Proposal of _@domain as a hack to just show the domain
    • Noster NIP05: does _@ method
    • Bumblefudge: "" empty string is a valid user id in WebFinger
  • Whatever is used needs to be able to deterministically downgrade to WebFinger-only services like Mastodon.
  • Most interest in use case 1
    • Does it need to be tied to domain names?
      • Nothing else is as universally understood and used.
      • Maybe DID Web? But didn’t seem correct, but found did:plc, ATProto more interesting
    • Need something that is stable independent of username. Problem of Mastodon implementation of Actor id is that usernames can’t change without breaking things.
      • Domains not being identifier in federation
        • Specifically, domain names expire and cost money, so it makes sense to decouple the handle from the identitier that software uses — it doesn’t have to be DIDs or did:plc or whatever, just that the difference between the two is a given.
    • Dimitri in chat:
      • I mean, look, the options are pretty clear:
        1. Use DIDs (like did:webvh) for under-the-hood non-human-readable stable identifiers.
        2. Use several Domain-to-DID discovery mechanisms, with fallbacks. which include, probably in order:
          1. .well-known discovery
          2. DNS binding
          3. (maybe, as last fallback) webfinger
  • Bublefudge: Request for focus on user stories rather than implementations
    • Dimitri believes the solution is known. Jeremiah would like to knwo more :)
  • Jim: Domain names cost money and domains expire. How will users deal with this?
    • Jeremiah: subdomains on your community server
    • Dimitri: like Tumblr / Livejournal etc gives out
    • Bublefudge: ICANN vulnerabilities, gTLDs of countries that stop existing, etc
    • Ryan: Services like WordPress.com and others hide the domain registration complexity to make buying a domain is as easy as picking a username now. The cost is less than the cost of a phone or even phone service.
  • General opposition to path-based usernames (e.g. service.example/username)
  • Jim: How do you prevent intentional attempts at impersonation? Domain name system prevent multiple registrations of the same name..
    • Bumblefudge: #3 is less valuable if impersonation is not able to be mitigated.
    • Many well known social media users, especially adult performers, have problem with impersonators doing scams.
  • Michael who’s doing this soon tho?
    • Emelia: I’m working on things related to this in an experimental software (Activity PDS), but if there’s a FEP for how to do this, I’d absolutely jump at implementing this in Hollo & Fedify.
    • Mastodon may be interested long term maybe? recently introduced a long-term stable identifier (acct id instead of username)
    • snarfed: @domain.example@domain.example is a good translation for sites that only show domain on hover or in faded color
  • Dimitri: I do want to offer a counter-point (to “subomains only, no path identifiers”). <- I definitely used to be on that team for the longest time. but talking with a couple of big tech engineers, they pointed out some scaling issues with that. so, grudgingly, I agree that we have to support URLs with paths as identifiers
  • Jeremiah: One thing with @domain.example@domain.example is that I would like capital letters like accessible hashtags, e.g. @JeremiahLee.com@jeremiahlee.com. Case handling