In the spec, there’s nothing that inherently prevents one from changing their username, yet the very idea of it seems to be very much opposed by most of the community — or, at least, the Mastodon team. So I’m trying to understand why is that.
Here’s my understanding of the problem:
The uniqueness of an AP object, internet-wide, is determined by its id a.k.a. @id. This is supposed to remain constant throughout the object lifetime.
The rest of the fields in an object can be changed, added, or removed with an Update containing that object, as long as the id remains the same. These fields include url and preferredUsername for actors.
So, as long as the id remains unchanged, there isn’t technically anything preventing one from changing their username.
Some implementations (again, Mastodon) use the username for both the id and the url. This means that Mastodon users won’t ever be able to change their usernames.
But, this would be effortless to implement in Smithereen — I already use database row IDs to generate my id URLs. It should already work as intended if another server does it this way.
So what is it, then, that prevents us from having changeable usernames?
As you note, many implementations (including Mastodon and Pleroma) use the username as part of their IDs, which limits them in this way.
However, for a host that doesn’t do this I imagine usernames chould change. Worth testing to see how other implementations react if you do that
So far as I can tell, it should be fine to change usernames. The only thing that would break is previous mentions of a user and potentially follows…
One way around that could be to store previous usernames and set up redirects to the new ones, but you’d have to consider whether to keep those old usernames reserved forever or if you allow the next person who comes along and uses them to take over and remove the redirect. Allowing new users to take over old usernames in this way presents the problem that now anyone following the previous owner is now following this new person they don’t know, and in the case of Mastodon (and probably many other implementations), the server wouldn’t know to replace the follow with the new username!
So I can understand why it could be a problem to allow changing usernames, but it doesn’t seem like an insurmountable problem is you think it through enough!
As you said, there are essentially three things one could call a ‘username’
The activitypub ID.
The name property
The username property
Of these, only the activitypub id has to always stay the same to identify the user. Feel free to change the others any way you like. If you allow something like taking over old users names, just remember to not let them take the same AP id. Misskey uses random IDs.
The mentions problem can be solved by the receiving side storing the mentions as its internal user IDs (that don’t change) and then substituting the appropriate link at rendering time. You have to sanitize any incoming HTML anyway, so why not process it a bit more?
This is also what VKontakte does internally: mentions are stored as [id1708231|Gregory] with the numeric ID, but this becomes a link to that user’s current username upon rendering.
Yes, I mean url. My understanding is that id is internal and never ever surfaced to the users (thus it may contain any kind of sufficiently unique gibberish — database row IDs, UUIDs, random characters, whatever), and url is where there’s a user-visible web page with the profile of that actor.
In theory, nothing prevents you from changing usernames.
However, doing this is not compatible with Mastodon. Indeed, Mastodon uses the username + domain pair (the acct: URI, really) as the authoritative identifier, not the ActivityPub id. This pre-dates ActivityPub and it’s one of my main gripes with Mastodon, but unfortunately it’s unlikely to ever get better, as it is too deeply ingrained in both its UX and database design…
A Move activity, like all ActivityPub stuff, references an ActivityPub id, which I suppose here, wouldn’t change, so I’m not sure how that could help (the Move would just serialize a move from one’s identifier… to the same identifier?)
What would currently happen in Mastodon is that it’ll re-fetch the remote actor definition, find the new username, and then… create a new user with the same uri (oof)…
