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

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

Received on Tuesday, 16 September 2025 20:55:02 UTC