Re: Standardizing the printed and HTML version of a an ActivityPub handle

Great question! I was considering
<https://mediaformat.org/2021/01/social-icons/> this a few years ago from a
social sharing/ “marketing the Fediverse” perspective.

I wondered about the webfinger vs url representation, and also whether it
was relevant to use each platform's logo, or band together for a common
approach.
A related concern at the time was whether to (visually) promote the
protocol (activitypub), or the social network (fedvierse).

Anyhow, today I think one of the most recognizable features of the
fediverse is the webfinger format.
I think it is also somehow more memorable, and the preceding @ symbol does
help disambiguate it from email.

Django


On Tue, Sep 16, 2025 at 3:37 PM Johannes Ernst <
johannes.ernst@dazzlelabs.net> wrote:

> It sounds to me like you are addressing a different requirement than I
> meant to bring up.
>
> I’m not attempting to say “disallow http identifiers for AP”. I’m also not
> talking about anything related to how software can figure out something.
>
> I am asking for a convention for how users write down their social web
> handles when asked. On paper sign-up sheets. On HTML registration forms
> (like my use case). And conversely, how they should be rendered when shown
> to the user, such as when printed on a business card, or shown on a website.
>
> E.g. — and this is just one possible proposal:
>
> * If your canonical identifier is http/s, provide this. Protocol is
> optional (like we’ve gotten used to in web browsers)
> * If your canonical identifier is acct:, provide @foo@bar
>
> In HTML,
>
> * if your canonical identifier is http/s, show <a
> href=“<URI>”>URI-without-proto</a>
> * if your canonical identifier is acct, show <a
> href=“<PROFILEURI>”>@foo@bar</a> where PROFILEURI is … you get the
> picture.
>
> (Could have have cute text adornment, too)
>
> Does this clarify?
>
> Thanks,
>
>
>
> Johannes.
>
>
>
> On Sep 16, 2025, at 13:54, Benjamin Goering <ben@bengo.co> wrote:
>
> By design, ActivityPub IDs can be any URL. So for https, for example, that
> means it's important to consider the rendering of activitypub ids like
> https://bengo.is/this-persona/this-context/ as distinct from
> https://bengo.is/this-persona
>
> MY concern with a lot of what you suggested, and this suggestion in
> general, is that none of those ways of rendering accommodate the
> flexibility in ActivityPub of an actor potentially having any https URL as
> it's only identifier.
>
> I would also point out that this seems redundant to some extent with the
> 'name' property on actor, which already is an affordance for a human
> readable representation of an actor.
> This seems like something that should be decided by individual actors and
> their choices of how to use the protocol, not necessarily decided by a
> standardization committee. To some extent it already has been decided: Just
> print the URL, and if that's too ugly, use the value of the 'name' property
> and hyperlink to an https://url (e.g. from id or url properties).
>
> To summarize
> 1) I think it's usually a good idea to use the .name property for a
> representation of the 'handle'. that's what it's for. hyperlink to .id or
> .url depending on uri schemes
> 2) Your suggestions dont accomodate valid and useful ActivityPub Actor
> IDs, eg.g. the example I gave before:
> https://bengo.is/this-persona/this-context/ . However, the render method
> I suggested above accomodates this just fine.
>
>
> On Tue, Sep 16, 2025 at 1:32 PM Johannes Ernst <
> johannes.ernst@dazzlelabs.net> 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.
>>
>>
>>
>