Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify current best practices regarding preferredUsername #309

marrus-sh opened this issue Jun 2, 2018 · 1 comment


None yet
2 participants
Copy link

commented Jun 2, 2018

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


This comment has been minimized.

Copy link

commented Jun 2, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.