Clarify current best practices regarding preferredUsername

[marrus-sh]

It has recently come to my attention that Mastodon's current implementation of ActivityPub expects the value of preferredUsername to be unique for the lifetime of an account. In fact, Mastodon privileges preferredUsername over id when identifying an account and storing its information in the database.

I am not familiar enough with other softwares to speak to their implementations regarding federation; however, to my knowledge there aren't presently any (multi-account) implementations which allow local users to change the value of their preferredUsername—so as of yet this behaviour hasn't created any major concerns. (Feel free to correct me if you know of any examples to the contrary.)

Note that while this treatment of preferredUsername has never (to my knowledge) been explicitly specified, it is my understanding that it was considered best-practice under GNU Social as well.

Without passing judgment on Mastodon's implementation, the fact remains that a naïve ActivityPub implementer—unfamiliar with existing implementations—attempting to support username switching might try changing the preferredUsername value, resulting in unpredictable behaviour across the fediverse. As this is an interoperability concern with potentially disastrous effects for users [1], it needs to be documented in the ActivityPub spec. In particular, I would recommend the following steps:

• Add the following recommendations regarding preferredUsername: that, if present and supported, it SHOULD be unique (when compared in a case-insensitive manner) on a given server, and that it SHOULD NOT change over the lifetime of an actor.
• Add an informative note that some existing implementations expect this value to uniquely identify an account on a server, and that changing it has the potential for causing interoperability concerns on federation.
• Add an informative note describing the current usage of this property; ie, user mentioning and lookup, without prescribing any behaviours regarding this.

In addition, I would recommend adding a new property, with the description and semantics of preferredUsername currently, for usernames which are not necessarily unique and are liable to change over time. I would recommend calling this property nick, after FOAF.

---

1. potentially disastrous effects: Namely, if person B unwittingly changes their username to one previously owned by person A, they will appear on some other servers to be the progenitor of person A's earlier posts.

---

(Background for this issue: I am currently working with a friend on an implementation of ActivityPub which does aim to support username switching, and ran into this problem.)

[nightpool]

I documented this in Mastodon's Implementation Report. i think it's best practice for Webfinger-based systems but I don't consider it a best practice for AP as a whole and I dont think it should be documented in the spec itself.

we were going to make a more comprehensive document for webfinger best practices at one point—does anyone know what happened to that?

[TiMESPLiNTER]

I stumbled across this issue here and want to add some questions/thoughts to it:

What's the purpose of preferredUsername if it has not to be unique per instance? I can define a display name through Object.name/Object.nameMap. In theory having a username is great because I can identify a user with a memorable sequence of characters rather than with a random ID. But if the preferredUsername is not unique I could have multiple actors per instance matching a specific username. So why does it not have to be unique per instance? What were the initial thoughts to put the statement into the standard that it not has to guarantee any kind of uniqueness?

Maybe you can give us/me some more insights about the concept of that property. I guess this would be helpful to understand what it should be used for. 🙂

[tesaguri]

I understand that this issue has been resolved by the ActivityPub and WebFinger Community Group Report.

https://www.w3.org/community/reports/socialcg/CG-FINAL-apwf-20240608/#usernames

• Implementers SHOULD NOT treat usernames as stable identifiers that will always map to the same actor, and SHOULD use the actor id in any references to an actor.(Implementers that currently treat usernames as canonical identifiers SHOULD take steps to avoid doing so in the future.)

cf. swicg/activitypub-webfinger#10

[evanp]

I think @tesaguri is right here! The AP WF report does cover this issue in a lot of detail. It may be worthwhile in future versions of the AP spec to refer to that report explicitly. Otherwise, I think we can wrap this up.

[evanp]

We're going to leave "Next version" issues open, so I'm going to take off the pending closure tag. However, I think this issues is more or less resolved until a new WG is chartered.