Mutability of the webfinger address

[evanp]

Can you change the webfinger address for an actor? For example, by changing the preferredUsername property?

Can you change the actor that a webfinger address links to?

[trwnh]

Yes, but Mastodon et al will have issues with this. Mastodon in particular uses Webfinger address as more authoritative than ActivityPub ID or even its own database ID in certain code paths. Generally, changing the preferredUsername will lead to a duplicate account/profile, as preferredUsername@host is used for deduplication (iirc)

[nightpool]

I think we should strongly encourage the ability to change webfinger addresses both with and without a "redirect" component, and file implementation bugs for implementations that don't support it.

On Wed, Feb 7, 2024 at 12:21 AM a @.***> wrote:

Yes, but Mastodon et al will have issues with this. Mastodon in particular uses Webfinger address as more authoritative than ActivityPub ID or even its own database ID in certain code paths. Generally, changing the preferredUsername will lead to a duplicate account/profile, as @.*** is used for deduplication (iirc)

— Reply to this email directly, view it on GitHub https://github.com/swicg/activitypub-webfinger/issues/10#issuecomment-1931307065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV72TOEM7RWUJNL5ZS3YSMFOPAVCNFSM6AAAAABC22OYJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZRGMYDOMBWGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[pfefferle]

The problem: It is possible to point a WebFinger address to any Actor-ID you want (kind of as a proxy), but Mastodon (et al) is using WebFinger only as discovery mechanism and always stores the Actor-ID as ID.

[tesaguri]

I think a tricky part would be interaction between reclaimed usernames and uniqueness constraints.

Suppose that Actor 1 renames from @A@example.com to @B@example.com and then Actor 2 reclaims the @A@example.com username[^1]. Under such a circumstance, remote servers may not tell that the username @A@example.com has been freed and may recognize that @A@example.com is still owned by Actor 1.

On the other hand, many implementations require that a username@domain pair is owned by only a single actor, even if not as strict as Mastodon does. The constraint might make the federationg servers reject the reclaim of @A@example.com as a duplicate.

Perhaps, implementations should acknowledge that the WebFinger resource for acct:A@example.com has removed Actor 1 from the JRD in the process of reverse-discovery of the JRD subject of Actor 2, and should perform reverse-discovery of Actor 1 again to learn Actor 1's new username (@B@example.com).

But I'm curious whether the existing implementations are prepared for such a situation and are able to handle it appropriately.

In particular, it's not obvious how the implementation should deal with "cascading" reclaims, i.e., a situation where Actor A reclaims @A@example.org, which had been owned by Actor B, who has reclaimed @B@exmaple.org, which had been owned by Actor C, who has…. Obviously, the implementation shouldn't process an unbounded number of reclaims at once, but where should the threshold be set? Or, even better, do we have a mitigation to prevent the cache from being stale to that level?

[^1]: You could argue that such a reclaim shouldn't be possible in the first place. But that is possible in many real-world social networking platforms (e.g. Twitter), which I believe the report should cover for wider adoption. Also, I think there's a trilemma where you cannot allow unlimited renaming, effectively prevent exhaustion of usernames and fully prevent reclaim of usernames at the same time, so we cannot just shrug off the usecase of reclaiming if we want to support changing usernames anyway.

[silverpill]

@tesaguri I think internal uniqueness constraint on webfinger address is useful, so I wouldn't remove it.

Conflicts may occur in two scenarios: when a new actor is discovered, and when a known actor is updated. In these cases implementations can nullify webfinger address field on conflicting records, and only keep it on a created/updated one.

Mastodon API clients can't display actors without webfinger address, but perhaps an invalid address can be used instead, or actor's ID (related problem: domain names as handles).

[tesaguri]

implementations can nullify webfinger address field on conflicting records, and only keep it on a created/updated one.

Ah, I was unconsciously assuming that implementations need to keep the username of every actor resolved, but leaving the conflicting usernames unresolved (probably until actually needed?) sounds quite viable indeed.

[tesaguri]

The use case of mutable usernames that interests me the most is to reuse the same username after a server migration.

Suppose Alice has an actor at https://app1.alice.example/users/1 with a username of acct:Alice@alice.example, and Alice decides to use a different server implementation, and create a new actor at https://app2.alice.example/users/1. While the Mastodon-style use of Move activities allows Alice to migrate their followers to the new actor, now their actor ID has changed, and when they phases out the old server, links to their old profile breaks. If Alice have introduced their Fediverse account to their friends by its URI, they need to tell the friends the new URI.

But if Alice can rename the old actor to acct:Alice@app1.alice.example and assign acct:Alice@alice.example to the new actor, they don't need to tell their friends a new username.

This should be possible in theory, but today this would confuse Mastodon servers as already pointed out. And the fact that I wouldn't be able to reuse a same username makes me hesitate to set up my own server, because I'd need to give up the username if I don't like the implementation I've chosen.