- From: Evan Prodromou <evan@prodromou.name>
- Date: Thu, 18 Sep 2025 13:01:45 -0400
- To: Juan Caballero <virtualofficehours@gmail.com>
- Cc: public-swicg@w3.org
- Message-ID: <dc550051-d5b3-4caf-b0da-0a96c209d41f@prodromou.name>
I think it's a final report, actually! Evan On 2025-09-18 12:24 p.m., Juan Caballero wrote: > Right, I was going to ask how this relates to the draft report we > already have that I think fairly summarizes the status quo. > > Maybe if dwebfinger or other novel conventions are of interest to > implementers, this thread could be the occasion of a conversation to > gauge interest from implementers/maintainers of implementations. I > have heard anecdotally of some projects getting feedback from users > that having a "special snowflake" identifier scheme is a point of > friction and a limiting factor on fediverse growth and onboarding. I > personally have always thought of webfinger as an identifier scheme > for "tenancy identity systems" (universities, employers, big > multi-user/heirarchical servers with admins, etc), so for me the > identifier system and the portability issues are intimately tied up: > users wanting an identifier that outlives their "tenancy" on a server > (or the server itself). Others just want a simpler, "more normal" one > to "give out at parties" and "put on my profile elsewhere". The Ghost > team have written in their changelogs and AP blog about the "webfinger > workaround" (@index@example.com for ghost blogs that... otherwise > identity as just example.com <http://example.com>) but I can also > sense in their writing that this is more of an > interoperability/legacy-support thing, since fundamentally a ghost > blog is a website (and a single-actor server for now). > > Also Ryan and Anooj presented some great exploration of UX research in > overlapping problem spaces (and how to bind multiple identifier types > in smarter consumers/clients) at last FediForum, maybe they can speak > to where their work fits into this more specific use-case? > > In any case, if there are implementers who would be interested in > working out a convention in common for some kind of identifier they'd > rather work with, then working out the "legacy compatibility" for > webfinger-only clients/consumers could be an interesting workstream > (ultimately adding some sections to the existing Discovery draft, in > the best case scenario?). Count me interested, wearing my DIF and/or > IPFS Foundation hat! > > Thanks, > __bf > > ------------------------------------------------------------------------ > Juan Caballero, PhD. > Freelance <https://www.caballerojuan.com> researcher, consultant, and > free thinker > Signal/whatsapp: +1 415-3101351 > Berlin-based: +49 1573 5994525, CET/UTC+2 > Native: English, Español; Functional: Deutsch, Français, Português > > > On Thu, Sep 18, 2025 at 3:18 PM Evan Prodromou <evan@prodromou.name> > wrote: > > I know that ActivityPub IDs are https: URLs, and that the > Webfinger format is only a helpful discovery mechanism. > > We have a Report from this CG about how Webfinger handles are used > with ActivityPub. > > https://swicg.github.io/activitypub-webfinger/ > > I was answering Johannes's question about the Webfinger format > that people are using to sign up for Fediforum. > > I agree that calling them "ActivityPub handles" is a misnomer. > > Evan > > On Sep 17, 2025 19:57, ben@bengo.co wrote: > > The uri scheme for ActivityPub is not acct. > Strictly speaking, I’d say there isn’t one nor should there > be. It was discussed in the WG. You might be surprised what > IANA says on the matter. > > Evan you are describing a different thing entirely which is > the webfingeriverse, and it was rejected by the ActivityPub > editors and every other author except you a very long time > ago. Amongst other reasons, because webfinger FORBIDS > identities at uri paths, and because it FORBIDS at the syntax > level what people actually want to do which is @bengo.is > <http://bengo.is> and @company.com/store/product > <http://company.com/store/product> . Webfinger is, since we’re > taking liberties, “not right” for ActivityPub. If you’re > defining whole new social webs or fediverse, fine, but why > confuse the *W3C ActivityPub* community by saying acct is the > “right” way when it is literally not even an *option* made > explicit in the spec, let alone a recommendation or a > requirement. We’ve already debated the s for a decade. If you > want to repropose it on its merits, make a proposal, but > please don’t fiat it into being a thing when there are good > reasons your proposal was rejected last time. > > With regard to registerProtocolHandler, I am a fan. That’s a > separate issue IMHO. > It is registered in IANA as web+ap and has been there for years. > > Darius, practically speaking fine replace the URI scheme with > an at sign. > @bengo.is/foo/bar <http://bengo.is/foo/bar> > > looks great. From a UX perspective, when texting the IDs > around in plaintext I STILL recommend a URI only because it > will be more tappable to your friend. Its not a technical > thing its a UX thing at least in the context of SMS comms. > > For the folks that grew up with uri schemes hidden from them > by chrome et al, that’s ok. Replace the ugly parts with an at > sign. (But it’s not webfinger, which bans @bengo.is > <http://bengo.is> ). People will figure it out. You don’t have > to use a whole other spec from before AP with a whole other > media type as WF requires. Webfinger people can adapt > @domain.com <http://domain.com> to acct uris, activitypub > native people can translate directly to (in parallel) https > discovery per AP spec, and (why not) other resolvers maybe > some Jabber (or AT) via-DNS. > I’m not even arguing against webfinger. I’m arguing *for* > @person.com/context <http://person.com/context> and its > webfinger that forbids what people want. > > The big thing: Let’s not tell people what to do when it’s not > necessary. What webfinger forbids, was never relevant to any > W3C SocialWG TR. Just do @company.com/product > <http://company.com/product> on the billboard. The sign maker > doesn’t need to dictate how the reader interprets the sign. > > Evan, as you know, we have disagreed on this issue in person > several times. > I have to admit, 9 months ago, I sketched a “dwebfinger 🤙“ > for April fools (and because someone asked me to) but I > decided not to release it here because you might consider it a > provocation. Please don’t. Many people want @domain.com > <http://domain.com> and what you’re recommending is > unfortunately in the way of it. We can agree to disagree, but > please consider not throwing around a controversial and > already debated issue as the “right” way, or at least please > understand why I speak up to disagree. Clearly there is not > consensus on the right way. > 🤙 > > android-chrome-512x512.png > > <https://hedgedoc.socialweb.coop/s/LwyM-4-w5#>dwebfinger - > HedgeDoc <https://hedgedoc.socialweb.coop/s/LwyM-4-w5#> > hedgedoc.socialweb.coop > <https://hedgedoc.socialweb.coop/s/LwyM-4-w5#> > > > > > (sent while mobile) > > On Sep 17, 2025, at 2:23 PM, Evan Prodromou > <evan@prodromou.name> wrote: > > I forgot to mention the relevant RFC for the acct: URI > prefix, which is here: > > https://datatracker.ietf.org/doc/html/rfc7565 > > Evan > > On 2025-09-17 5:16 p.m., Evan Prodromou wrote: > > So, this is a really interesting topic! > > > In terms of the "right" format for ActivityPub > accounts, I'd suggest sticking with bare Webfinger, > username@domain.tld. If I were make a UI for > submitting Fediverse account IDs, that's probably the > format I'd use. > > > From the URI perspective, for Webfinger identifiers, > `acct:username@domain.tld` is the "right" way to do it. > > > Having that be clickable means that users can assign > apps to "handle" the URI. For example, a user could > assign the Elk.zone Web application to handle those > URIs, and show the profiles page with profile, outbox, > followers, friends, etc. as well as affordances to > follow, block, message, mention, etc. > > > There are browser features and operating system > features to define a handler for an URI protocol > prefix. For browsers, registerProtocolHandler() is the > way to go. > > > https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler > > > > Theoretically, assigning an app to handle the "acct:" > prefix would let you create a link like this in HTML: > > > <a href="acct:evan@cosocial.ca > <mailto:acct%3Aevan@cosocial.ca>">Evan Prodromou</a> > > > ...and it would just work. > > > There are two problems with this, though. > > > 1. Webfinger identifiers are primarily (?) used for > ActivityPub actors, but not exclusively. It seems like > a low risk, but some non-zero percentage of users > might want Webfinger addresses to be handled by... > something else? > > > 2. HTML5 has an allowlist of URI prefixes that can be > registered to be handled, and "acct:" is not on the > list. You *can* use whatever prefix you want, as long > as it start with "web+", so registering the > "web+acct:" prefix would let you write links like this: > > > <a href="web+acct:evan@cosocial.ca > <mailto:web%2Bacct%3Aevan@cosocial.ca>">Evan Prodromou</a> > > > Anywho, long story short: I did a little > experimentation with this on https://acct.swf.pub/ ; > you can register that web site to handle web+acct: > URIs, and it should then handle them correctly. > (https://acct.swf.pub/test.html has a test link you > can try). I need to get back to polishing it up, but I > think this is an interesting area to pursue. > > > > On 2025-09-16 4:31 p.m., Johannes Ernst wrote: > > During registration for FediForum (which is coming > up again, by the way!) we are asking people for > their social web handles: > > > Here is a selection of what they give us when they > probably mean ActivityPub > > > @foo@bar > > AP: @foo@bar > > https://bar/@foo > > foo@bar > > foo (???) > > acct:foo@bar > > > Is it time to define a canonical version? > > > Perhaps there could also be a canonical, clickable > HTML version. > > > Just a thought. > > > Cheers, > > > > > > Johannes. > > > > > >
Received on Thursday, 18 September 2025 17:01:55 UTC