Forfeiting all their past content and relationships is “not much effort for the user”?
Again, we treat usernames differently. Some treat them like important primary keys, but for me they’re decorative. I designed my database for the possibility of changeable usernames from the beginning.
Just a note that I’ve rebased my PR to Mastodon that adds support for preferredUsername changes and requested another review.
I’m still quite curious how this is supposed to be handled by WebFinger and mentions. Specifically the fact that @Alice@example.org may refer to more than one user, since there is no guarantee that the username Alice is unique on the domain example.org.
Does Mastodon or any other implementations currently handle this scenario? What happens in Mastodon if I post a toot mentioning @Alice@example.org, in the case where there are, say, 50 users on example.org with the username Alice? Does it mention all of them? Or none of them? Or one of them, chosen arbitrarily?
No, the webfinger username must be unique on the domain that hosts it. Webfinger doesn’t support multiple profiles for a given username, and consequently no downstream software supports this.
The preferredUsername in the Actor document should also be unique for the domain, however, may not be unique for the domain, in which case software may assign the account in their system as like Alice1 because Alice was already taken on domain according to their database.
See the “3.2 Establishing a link between the WebFinger resource and the actor document” section here: ActivityPub and WebFinger and specifically the note:
Publishers SHOULD include only one such link.
Do you have a source for that claim? The spec quite explicitly states that this is not the case:
preferredUsername: A short username which may be used to refer to the actor, with no uniqueness guarantees.
But conversely that means that publishers MAY include more than one such link. What happens then?
It’s an implementation detail, like yes, you could have preferredUsername be non-unique, but most receiving software will need a unique way to address that account, so if you don’t use unique values, receiving software will create usernames that are unique. You can’t mention @alice@social.example if you don’t know which alice to mention.
Shit breaks. That’s basically it.
This makes me very curious why the spec didn’t just specify that preferredUsername is unique within a domain. If that is the only way to avoid breaking everything, why even allow the possibility of it not being unique?
Usernames are still unique per server. There can’t be more than one Alice on example.org. In case there’s a conflict, I change the old user’s username to a long random string, with the assumption that they changed their username but my server doesn’t know that, and that it will be updated to their real one if and when their actor object is refreshed.
But as I stated above, the spec explicitly says preferredUsername has no uniqueness guarantees, so this doesn’t seem to be true.
It seems to be a universal truth in implementations though and it kinda makes no sense to use WebFinger with ActivityPub if preferredUsername is not unique (as AP states it is not). But I don’t suppose there is any way to update the ActivityPub standard here, like through an errata or something? Allowing duplicate preferredUsernames within the same domain seems ludicrous.
Well, sometimes the spec and the reality disagree. In such cases, it’s usually wiser to look at the reality. And ideally amend the spec to agree with it.
If actor type is specified in properties, I take the link to a Group actor (this is for Lemmy). If actor type is not specified, I simply take the first link.
ActivityPub doesn’t depend on WebFinger in any way. The usage of WebFinger is entirely spurred by Mastodon’s desired user experience of replicating Twitter’s @ mentions. preferredUsername being used for WebFinger is just one mistake in a list of mistakes that implementations have made over the years, where they use the closest sounding property from the activitystreams context or AS2-Vocab (even if it doesn’t fit!) instead of defining their own.
There have been attempts at explicitly defining a property for “WebFinger address” or “Fediverse address”, such as fep/fep/2c59/fep-2c59.md at main - fediverse/fep - Codeberg.org proposing a webfinger property (https://purl.archive.org/socialweb/webfinger#webfinger), but this hasn’t really caught on due to a lack of developer interest.
If you’re wondering what the intended usage of preferredUsername was, it’s to provide one or more “preferred usernames” in the same way that name works to provide one or more “display names”. They’re not 1:1 parallels of each other, because there is no natural language support for usernames like there is for display names, but they serve functionally the same purpose when it comes to display. Identification is done via id. There is no uniqueness guarantee even across a domain, because the concept of a “domain” does not exist in ActivityPub; the basic unit of computation is an actor[1].
In ActivityPub, this is any resource with an inbox and an outbox. Now, whether this makes sense or is logically consistent is a different matter altogether. There was some effort to keep AP from depending too heavily on HTTP so that it could be used in a P2P or distributed environment, but I think that this work is largely unsuccessful since the core of AP still relies on GET/POST semantics… ↩︎
I think that’s a very negative way of seeing it. It was not Mastodon’s idea to have @ mentions. That’s just something that users simply expect in every social platform in existence these days. Do you think Mastodon should’ve left out the feature? That doesn’t seem viable. Do you really think it was a mistake to provide the feature? I would guess that Mastodon would not be nearly as big as it is today if it did not have mentions. Or do you think it should’ve provided it via an extension property? That runs into the problem of splitting the ActivityPub ecosystem even further, and what to do about the instances that don’t implement the “unique usernames” extension?
The real mistake is the spec not having accounted for this (very predictable, if you ask me) use case and not including some kind of accommodation for this use case in the base spec.
I’m starting to think that even this was a mistake, because it doesn’t seem like it lines up with reality. Are there any significant ActivityPub implementations that take this “actor-first” approach and eschews instances/domains? There’s so many missing pieces in ActivityPub that I don’t even see how you could build an implementation without assuming things like instances/domains and unique usernames.
I rather think that email had it correct from the start - username@domain should’ve been the ID of an actor. Don’t fix what’s not broken, and all that.
Very few platforms that were created in the past 10 years support unique, plain text @ mentions without some form of UUID or disambiguater stapled onto them. Facebook never has, for example. Do you think users care? No, they just care that they can @ mention their friends, and the system takes care of resolving that into a profile UID behind the scenes.
Supporting unique, purely text based @ mentions is a very developer brained way of looking at the problem of “how do I reply to my friends”?
what? how does that follow?
Exactly! I would love that we think about this more from a user/UX perspective. But I feel like that perspective has not gotten its due in the ActivityPub spec.
I agree, of course users don’t care if username@domain is entirely unique as long as they can reliably use that syntax to mention who they want to mention, but implementing such a feature becomes a lot easier if usernames are unique, and for a distributed protocol like ActivityPub it is crucial to make implementation easy and pain-free.
And how would we do such disambiguation in the base ActivityPub spec? There is nothing in the base spec that provides any information on actors that could be used to disambiguate between users like this. Perhaps except followers; i.e. if there are two users behind the identifier Alice@example.org, choose the one that is your follower, not the one that isn’t. But filtering on followers seems like a weak filter that would rarely result in a unique disambiguated user (i.e. if neither of the two users follow you). I don’t think the solution is to show the ActivityPub IDs of both users to the mentioning user and let them pick who they mean.
Mastodon is the major Twitter alternative on the fediverse. @-mentions on Twitter is a hugely central feature. I think if Mastodon did not have the feature, many users would have their expectations broken, as they would expect a Twitter alternative to have mentions. I think that follows quite easily, but I could be wrong of course. There’s no way to know as this is purely hypothetical of course.
The mistake isn’t copying twitter mentions, the mistake I was referring to is
But the feature itself doesn’t actually depend on usernames either. From a UX perspective, the feature depends only on the user typing @ and then their client shows them some UI to allow them to select a user. As nightpool points out, Facebook and Facebook-like implementations don’t ever expose @username, they use display names instead. So this is just as much a valid mention:
<a href="https://mastodon.social/@trwnh">infinite love</a>
The encoding just needs to be unambiguous. How you render it is entirely a choice of the visual designer. You can refer to my account as infinite love or @trwnh or even https://mastodon.social/@trwnh and these are all valid as long as on the backend you understand that the object you are referring to is https://mastodon.social/ap/users/14715 or whatever.
The important thing to realize is that ALL of these different references are exactly that – references. They should map to the canonical identifier at the end of the day. You should be able to change how the references are displayed, as long as you can still get to the id. Changing my preferredUsername from trwnh should be just as uncontroversial as changing my name away from infinite love.
Let me put it another way. Are https://trwnh.com and https://abdullahtarawneh.com backed by the same service? You have no way of knowing if the same HTTP server or software instance is serving the requests for both domains. Simply put, you cannot reason about services without e.g. a Service actor being associated with both Person actors as the attributedTo or some other more appropriate relation to let you know that in fact https://nginx.trwnh.com is managing both https://trwnh.com and https://abdullahtarawneh.com.
This is “broken” because it doesn’t allow for userpart changes, which is the primary topic of this thread. If you want to make usernames changeable (insofar as you recognize and use usernames), then the identifier cannot depend on usernames. See “What to leave out” from “Cool URIs don’t change”:
- Authors name- authorship can change with new versions. People quit organizations and hand things on.
People also change their name due to social reasons a lot – getting married, transitioning gender, or just because they want to. Asking everyone to commit to an unique unchanging username is a setup for eventual failure.
I tried to build on actor-centric model, but it doesn’t really work. Even a simplest blogging application can’t completely ignore server boundaries without exposing itself to security risks, and the model completely breaks down in more complex cases.
That doesn’t mean actors are not important, but they exist on the layer above the “server”. The result of my research on ActivityPub security model is FEP-fe34: Origin-based security model.
There is no mistake. What ActivityPub specification actually describes is a network of servers, server-to-server and client-to-server APIs. It begins with the following paragraph:
The ActivityPub protocol is a decentralized social networking protocol based upon the ActivityStreams 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.
It uses the term “origin” instead of “domain” throughout the text. And nowhere it says that actor is a “basic unit of computation is an actor”. This is just not true.
There are many missing pieces, but early adopters filled the blanks and thanks to them we have a functioning network. The best way to build an implementation is to look at what others are doing.
this is drifting off topic but i would like to push back against this bit:
in ActivityPub, you do not follow servers, and servers do not perform activities. servers merely host actors as HTTP resources in the default interpretation, and provide interfaces for communicating with the actor inside its cage (outbox, proxyUrl, and so on).
what you may be referring to is that in “the fediverse”, applications follow the instance model. this is evident by the overwhelming use of sharedInbox and the social-platform-as-a-service approach taken by most implementations. the flipside of this is that, if you accept that servers are inevitable, then most of activitypub is actually needlessly complicated overhead that could be eliminated entirely. ostatus got along just fine using atom feeds and websub notification hubs. you could use a single Service actor to handle all traffic and you wouldn’t lose anything. take it one step further, and you find that federation doesn’t make sense anymore; what you would really want is syndication instead between different sites. the messages are discarded and the content is made available on remote sites as a “post” in the database.