Ditching the webfinger requirement

[ClearlyClaire]

While useful, Webfinger is not part of the ActivityPub specification itself, and the ad-hoc mechanism from going from an ActivityPub actor URI to a canonical acct: URI is pretty clunky.

This issue is here to track what would need changing for dropping the Webfinger requirement. It is probably not exhaustive.

Uniqueness of local actor names should probably still be enforced to reduce confusion and avoid breaking compatibility with older versions.

API

• /api/v1/accounts/lookup would either need to be dropped or return an array
• it would probably make even more sense now than before to expose the uri of actors in the REST API

UX

• /web/@foo@bar and /web/@foo@bar/12345 paths introduced to harmonize the WebUI with the public page paths may not make sense anymore
• mentions: what to do if a @user@domain handle is ambiguous, or if an user doesn't have one?
• displayed username: everywhere in the UI we display @user@domain to identify users, what if the user does not have a canonical acct: URI?
• how to not make the admin interface utterly confusing?
• remote follow flow needs to be changed as well
• account redirect / migration flow might need changes as well

Database

• we need to finally enforce uniqueness requirement for actor uri at the database level
• which means we need a way to merge account records that shared the same uri even if it was only briefly possible
• we need to drop the uniqueness requirement on username+domain

[trwnh]

tagging #10745 here for potentially related changes -- if any work is put into moving away from username@domain as the canonical representation, then it might also make sense to use a less fragile URI scheme for actors that doesn't depend on usernames. (breaking domain requirement right now is unfortunately not possible due to DNS, of course)

[Ciantic]

People are already depending on @something@example.com working, e.g. Simon Willison made an article how to make these vanity handles.

IMO it should be made even easier, e.g. if John Doe had account in: https://mastodon.social/@JohnDoe

And he owns example.com, he should be allowed to make @john@example.com as his handle simply by creating some easy linking file e.g. https://example.com/fediverse.json

{
	"@john@example.com": {
		"aliases": ["https://mastodon.social/@JohnDoe", "https://mastodon.social/users/JohnDoe"]
	}
}

(Of course it would require a field in mastodon.social as well that you want to change the handle)

[rbairwell]

And he owns example.com, he should be allowed to make @john@example.com as his handle simply by creating some easy linking file e.g. https://example.com/fediverse.json

If you are the only user on that domain, you can currently:

• Either make a text file called /.well-known/webfinger and paste in the JSON content for your Mastodon URL as returned by a service such as https://webfinger.net/
• Or, even simplier, as I've done on my personal development site, just set up a bog standard 301 or 302 redirect from .well-known/webfinger to go to the instance's full webfinger url for your account (the GET url returned by Webfinger.net)

The problem with your solution is if there are multiple people "working at" example.com : which user should be listed in the static .json file and/or how would you distinguish which one is being queried for. You don't want to return all of the users due to privacy, anti spam and just size of the document (think IBM, Microsoft, Facebook type employee size) would be massive.

[tesaguri]

I understand that the plan is to treat whatever preferredUsername an ActivityPub actor states as the userpart component of the actor's acct: URI (if WebFinger isn't available?), and that the problem is that there could be multiple actors with a same preferredUsername under a same domain. And in addition, I think there's a problem that, without WebFinger support, the ProcessMentionsService has no way to resolve mentions to accounts that the local server doesn't know yet.

Then, how about keeping the WebFinger requirement for @ mentions and lookup with acct: URIs, and instead add a new mechanism of mentioning/looking up actors, where you can mention/look up actors (with WebFinger support or not) using their ActivityPub object URIs? I suppose the above problem can be solved this way since the object URIs are uniquely dereferenciable unlike preferredUsername (and like acct: URIs resolved via WebFinger). This would allow us to make the preferredUsername property (which is optional in the Activity Streams spec) optional as well.

A drawback of the proposed approach, though, would be that the user might not usually intend URIs in posts to be mentions. This would be problematic especially in private posts, which are intended to be only visible to explicitly mentioned accounts.

Perhaps the proposed mention mechanism should only be employed if the target server doesn't support WebFinger? But even then, ill-intended Web page administrators could set up ActivityPub actors on their own URIs to intercept Mastodon posts containing the URIs (though such an attempt would be quite likely to be apparent).

Or mentions with URIs should use a special syntax, e.g., that requires the URI to be prefixed with an @ sign, like @https://example.com/@actor. Possibly, this wouldn't look quite well to everyone, but it has an additional benefit that the ProcessMentionsService would only need to attempt to resolve URIs that are likely to be valid mentions.