BlueSky username/handle changes are not updated on BridgyFed

[BeAwareTTV]

I recently updated my handle on BlueSky to my own domain. However, the federated account doesn't reflect the changes and still has the old link in the bio which no longer works.

Hope this is a good enough explanation. Ryan told me to submit issue. So, here it is.

[qazmlp]

@snarfed If you solve this by migrating, it may be a good idea to send another Move after a delay (more than an hour, maybe a bit more than a day?) for good measure, unless someone else has taken and bridged the origin handle. Historically, some software had trouble with cached profiles at the destination, meaning it would think alsoKnownAs wasn't set.

(There could still be a race condition if you set alsoKnownAs and then Move within ~5 seconds of each other even after the fix in Akkoma, iirc, as they have a little debounce in place to prevent reflection attacks. See: https://akkoma.dev/AkkomaGang/akkoma/pulls/714#issuecomment-11203)

[snarfed]

Sigh. Under the covers, BF uses Bluesky DIDs in AP actor ids, eg https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb, not handles. The original hope/goal there was that we wouldn't need "migrations" at all, since the actor id stays the same across handle changes.

Sadly it sounds like Mastodon has old legacy baggage in its schema that identifies remote actors by their (username, server) tuple...? Can't find where we discussed that recently, but if Mastodon thinks an actor becomes an entirely separate actor when its preferredUsername changes, and nothing else, then that's...unfortunate. I don't know what we'd do then, since this wouldn't really be a migration at all: the actor id, follows, everything else stay exactly the same. 😕

[qazmlp]

Ah, I'd failed to consider that.

I think it does look up accounts by id. It just has an account refresh interval of a week, so it can look stale (unless the update is pushed via Update, which... no. The problem is really just this line, I think (plus that it never sets username). Looks like Mastodon just plain skips the by-id search when it receives an Update, unless I missed something).

I think it generally does look up accounts by id almost exclusively though, so it won't treat them entirely as separate, but I couldn't say how it actually ends up behaving.

To me this looks like a bug where the parameter is intended as "only by id" but ends up meaning "not by id unless". (Edit: I think the parameter is not actually used anywhere at all though.)

---

This comment is a mess, sorry.

The gist is yeah, I think this wouldn't allow remote servers to change preferred handles in place, ever, towards a Mastodon server.

It may recognise the change/"missing account" after a week, but could possibly lose some data in the process?

[snarfed]

Here's what I'd remembered about Mastodon:

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…

[qazmlp]

That matches what I found in the code, I think.

If I'm not mistaken, you can prevent eventual destruction of the database entry with a WebFinger 'redirect' (at least the code seems to call it that), but I'm not sure that won't cause issues down the line.

[RingBandit]

I'm having the same issue, only that it pulled Data from my first Change. I changed the Handle again short after and until now it didn't pull the new Handle.

[snarfed]

Relevant: W3C SWICG finalized its ActivityPub and WebFinger report last month, and it includes guidance on preferredUsername. From section 3.1.2:

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

[jasontenpenny]

I've run into the same issue, but I'm unclear on what we're saying in this thread. Are we saying it's not possible to update the Mastodon info currently, or that it will update if we change handles again after a few hours?

[snarfed]

@jasontenpenny right, Mastodon can't handle username changes right now. They've made some progress on supporting it for their own users, internal to each instance, but not yet much progress for remote users.

If you unfollow and then re-follow @bsky.brid.gy@bsky.brid.gy, you may get it to bridge you to a new fediverse account with your new handle in the bridged fediverse address. Let us know if that works!

[astrojuanlu]

FTR, I tried

1. Unfollow,
2. Block,
3. (Wait a few hours),
4. Unblock,
5. Follow,

And the new account wasn't created.

[jasontenpenny]

yeah it looks like BF keeps a cache of the DID even after we block the account. So when we unblock and re-follow, it just reactivates that old cache. So it doesn't pull the updated username from Bluesky, and it doesn't look like it recreates the Mastodon account. Either that or I just haven't waited long enough for that part.

I'm wondering if part of it is due to the fact that blocking BF doesn't reset its following status. So it's still following my account as soon as I unblock it.

[snarfed]

yeah it looks like BF keeps a cache of the DID even after we block the account. So when we unblock and re-follow, it just reactivates that old cache

Yes! That's #1334