FEP-03c1: Actors without acct-URI

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

This is a discussion thread for the proposed FEP-03c1: Actors without acct-URI.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

Most current Fediverse applications use an acct-URI as unique display name
for actors. Usually, this display is done by displaying acct:user@domain.example
as @user@domain.example. This FEP states that if there is no
acct-URI associated with an actor, the actor should be displayed
as its id. So the actor with id https://actor.example/path will be
displayed as https://actor.example/path.

In addition to the example below, we wish to point out that further independence of webfinger will enable new features such as using domain names as handles.

1 Like
2

I don’t really understand why we would have a FEP to describe a lack-of-a-feature. This is the default behavior in the spec, making a specification simply to say it’s allowed is very confusing.

3 Likes
3

It might be the default behavior in a spec, I guess ActivityPub, but it is not the default behavior in the Fediverse.

1 Like
4

@helge Shouldn’t a handle based on actor ID have @ in front of it?

  • acct:user@domain.example → @user@domain.example
  • dns:domain.example → @domain.example
  • https://actor.example/path → @https://actor.example/path ? Or maybe even @actor.example/path
5

Requiring developers to use any specific prefix for displaying implementation-specific account handles doesn’t seem desirable to me.

1 Like
6

Yes, but this proposal says

Usually, this display is done by displaying acct:user@domain.example as @user@domain.example.

So I thought it might as well recommend a way to create @-handles from https: URIs.

7

I think how to display an unique identifier per Actor is an interesting topic. I think one should recommend displaying Actor’s in a form similar to:

actor_display

You might be able to edit it at Excalidraw | Hand-drawn look & feel • Collaborative • Secure

The question here would be “What is ‘Unique Identifier’?”. I would claim that the conversion:

  • acct:user@domain → @user@domain makes sense, because the meaning of acct will confuse the average user.

Whereas the average user knows that a https:// URL identifies something, so using it as a identifier is fine!

2 Likes
8

Is it really necessary to display a unique identifier, in the first place? In the case of RSS feeds (which the FEP takes as an example), I think it’s common for feed readers to only display the feed’s <title>.

And more generally, it doesn’t feel quite right to me to forge a “username” for a user who doesn’t have a “preferred username”. A “username” is a short human-readable representation of the user, whereas a URI is not always short nor human readable (consider a URI with a UUID, for example).

I think that’s especially the case for automatically-generated actors as demonstrated by the FEP itself. Clients don’t want to display a long URI like https://rss.example/actor?feed=https%3A%2F%2Fpypi.org%2Frss%2Fproject%2Fbovine%2Freleases.xml. They would rather display an ellipsized form like https://rss.example/actor?feed=…, which would be only useful for telling the domain name and few boilerplate path components.

On the other hand, the ability to mention the user is still important. But I think we can just use the actor URI (or url if present) for that purpose, as the FEP requires for the displying purpose. You can even make it a proper Mention like the following:

{
  "type": "Mention",
  "name": "example.com/@actor",
  "href": "https://example.com/users/1"
}

However, I believe that care should be taken to not add to/cc without the post author’s explicit action, since it’s not usually the user’s intention to “mention” another user by just including a URL of that user in the post, while adding to/cc means that the post is delivered to the referent actor even if the post is supposed to be private.

I think prefixing the actor URI with @ may be a good indicator of the user’s intention to mention the referent actor.

By the way, there is a Mastodon issue relevant to this FEP:

Also, this may be a good topic for the ActivityPub and WebFinger Community Group Report:

1 Like
9

I “implemented” this FEP in my project.

Previously webfinger addresses were used as primary identifiers, but that was undesirable for several reasons, so I switched to actor IDs. Now webfinger addresses are mutable, and that might lead to a conflict if two actors use the same address. If conflict occurs, the server removes address from the conflicting actor. Webfinger addresses are still used everywhere in the UI but when address is not present, the actor ID is displayed in its place.

Nice illustration! Consider adding it to the proposal

Unique identifier should be displayed because there might be accounts with the same display name. Often such accounts belong to the same person, but it also could be a case of impersonation, or unintentional name clash.

10

I agree that usernames should be displayed for actors with canonical acct: URIs. But today, normal users do have canonical acct: URIs, and I think confusion/impersonation issues are less relevant for supposed use cases of the FEP like automatically generated actors.

I think it’s a viable recommendation for servers to always assign unique usernames to normal users who should be protected from impersonation.

Edit: But, yes, it may still be better to display the actor URI rather than nothing, even if it’s ellipsized, so that it’s explicit to the user that the actor has no username.