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

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

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?

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…

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.

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.

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

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?

@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 @[email protected], 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!

FTR, I tried

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

And the new account wasn't created.

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.

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

@snarfed I think this is solved as far as possible on our end now, since #1334 is done.

The rest of the issue seems to be on the receiving instance's end, e.g.

• Feature request: Make it possible to change a username mastodon/mastodon#15320,
• Threadsの連合ユーザーのusernameが変更されても反映されない misskey-dev/misskey#13611 / preferredUsernameとurlは可変 mei23/misskey#4986,
• Allow changing account's username. pixelfed/pixelfed#4053 (no more specific issue, but not implemented I think),
• I can't navigate Pleroma's source well (I don't know Elixir), but https://git.pleroma.social/pleroma/pleroma/-/issues/59 seems related.

Technically yes! But since it seems so common that receiving fediverse servers don't support username changes, notably Mastodon, I wonder if we still want to keep this open so that people can find and follow it easily? I don't know, open to thoughts.

Sounds good, I'll just mark it blocked then.

Hey folks! Just did the dance of change handle --> unfollow --> refollow, but the result doesn't seem to have taken quite right. A specific order of events, with some other potentially confounding factors:

• Messaged @ap.brid.gy with a fediverse handle I wanted to follow. It told me I needed to bridge first, and I knew that there was some weirdness with changing handles, so I thought to do that first
• Changed handle from @luxaritas.bsky.social to @luxaritas.com
• Followed @ap.brid.gy
• Either just before or just after I follow @ap.brid.gy (can't actually remember this order of events), I create a new account with the handle @luxaritas.bsky.social to park it
• I now notice Bridgy tells me my page URL is https://fed.brid.gy/bsky/luxaritas.bsky.social, which I assume means it cached the handle from that original DM
• I unfollow and re-follow @ap.brid.gy

The situation I now see myself in is that https://fed.brid.gy/bsky/luxaritas.bsky.social redirects to https://fed.brid.gy/bsky/luxaritas.com, but the later responds with bsky user luxaritas.com not found

Sorry for the trouble @luxaritas! Sounds like this is indeed your issue. I don't have an ETA for a fix, but I appreciate the details and info.

Thanks @snarfed! Don't know if there's anything I can do to help given I have no previous experience with this project, but if there is do let me know, as I have a vested interest in this 😄

Hey folks! Just did the dance of change handle --> unfollow --> refollow, but the result doesn't seem to have taken quite right. A specific order of events, with some other potentially confounding factors:

• Messaged @ap.brid.gy with a fediverse handle I wanted to follow. It told me I needed to bridge first, and I knew that there was some weirdness with changing handles, so I thought to do that first
• Changed handle from @luxaritas.bsky.social to @luxaritas.com
• Followed @ap.brid.gy
• Either just before or just after I follow @ap.brid.gy (can't actually remember this order of events), I create a new account with the handle @luxaritas.bsky.social to park it
• I now notice Bridgy tells me my page URL is https://fed.brid.gy/bsky/luxaritas.bsky.social, which I assume means it cached the handle from that original DM
• I unfollow and re-follow @ap.brid.gy

The situation I now see myself in is that https://fed.brid.gy/bsky/luxaritas.bsky.social redirects to https://fed.brid.gy/bsky/luxaritas.com, but the later responds with bsky user luxaritas.com not found

I get this same problem. I'm happy to contribute a fix if someone can guide me as to what is failing here.

@Zemnmez thank you for offering!

Sadly this specific issue isn't quite shovel-ready yet. The main blocker is that some fediverse software, notably Mastodon but also others, can't handle username changes yet, #1074 (comment), so if we fully implemented this and sent out Updates for bridged actors, that would break them in the fediverse in various ways. 😕

It sounds like there's an additional issue here regarding the broken redirects.

@snarfed What do you think about using did:… URLs for the HTML link hrefs?
For example, my profile is at https://bsky.app/profile/tamschi.bsky.social but https://bsky.app/profile/did:plc:kh75nufdwqlesva4uyyj2e2m works just as well and might save some database lookups on our end.
(You get this form when you use the share button to copy a custom feed link, so it should be quite stable.)

It should be enough for the redirect path to validate that the last segment is a username or DID without any parameters.

Right now, I would be happy to be able to just completely recreate the profile rather than rename it - it didn't live long enough to even be used, and any time it doesn't exist is time that content I post won't be synced to the fediverse

Actually I just checked and it appears after logging into a Mastodon account and searching for it I can see @[email protected] - so I think it's only the web profile that's broken in my case?

@snarfed What do you think about using did:… URLs for the HTML link hrefs?

Sorry, the HTML link hrefs where? In DMs that @[email protected] sends?

Sadly this specific issue isn't quite shovel-ready yet. The main blocker is that some fediverse software, notably Mastodon but also others, can't handle username changes yet, #1074 (comment), so if we fully implemented this and sent out Updates for bridged actors, that would break them in the fediverse in various ways. 😕

@snarfed what's the state of the world on this? I'm seeing the same as @luxaritas that the link I was DM'ed https://fed.brid.gy/bsky/zemnmez.bsky.social is broken -- but https://fed.brid.gy/bsky/zemn.me does work, so is everything working as expected, but with a new account?

I don't mind not being able to move my old posts -- my BSky account is super new.

Honestly I haven't dug into this enough yet, and it's not really a priority right now. Sorry I don't have better news. Hopefully after I get through the current roadmap!

@snarfed What do you think about using did:… URLs for the HTML link hrefs?

Sorry, the HTML link hrefs where? In DMs that @[email protected] sends?

I was thinking @mentions in general, profile "url" property… essentially anything that currently uses "https://bsky.brid.gy/r/https://bsky.app/profile/" could use the DID there instead and the redirect route could allow-list links of this format without checking the database.

(I misread a little earlier regarding where the "bsky user … not found" error happened, since I think that also happened in a different context related to viewing someone's profile from Mastodon.)

Case in point: I just changed my Bluesky handle and now the "Open original page" function is broken on that bridge profile.
I just checked with ActivityPub Explorer and Bridgy Fed is still serving

"url":[ "https://bsky.brid.gy/r/https://bsky.app/profile/tamschi.bsky.social", …

, which is clearly incorrect now. https://fed.brid.gy/bsky/tamschi.bsky.social worked but showed the old state…

…until I refreshed it manually just now. It's now a redirect to https://fed.brid.gy/bsky/tamschi.itch.io but that page only shows

Not Found

bsky user tamschi.itch.io not found

while the "url" in ActivityPub has changed to

"url":[ "https://bsky.brid.gy/r/https://bsky.app/profile/tamschi.itch.io", …

which is correct. When viewed through Mastodon, the profile's "Open original page" link interestingly has changed to https://bsky.brid.gy/ap/did:plc:kh75nufdwqlesva4uyyj2e2m, which seems to redirect fine but interestingly to the clear handle URL. That redirect route too could avoid the database lookup by just redirecting to the /did:plc:… URL on bsky.app.

(Maybe Mastodon doesn't process "url" arrays, falling back the the "id" instead?)

So overall there are probably two issues:

1. Bridgy Fed doesn't notice automatically when the handle updates and
2. when refreshing the profile, the profile page on Bridgy Fed isn't bound properly at the new handle.

Some further interesting developments. All of a sudden, the page for my new handle) is now showing up, with the page for my old handle now 404ing. However, after creating a bsky post, I don't see it reflected on the fediverse profile :(

Wait no, that's just a me not reading the docs 😅

If you're looking at your bridged account in the fediverse, Bridgy Fed only delivers your posts to fediverse instances where you have at least one follower. (This is how the fediverse works in general.)

I am seeing a bit of weirdness where posts from bsky are (sometimes?) delayed in showing up (including on the web profile), but I'm going to guess that's unrelated

I too followed @ap.brid.gy and then changed my username from *.bsky.social one to my own custom domain. Today I was curious to check my user page, but I saw neither my old nor current username were on fed.brid.gy. It was redirecting from my old to new only enough. Tried the whole unfollow/block/unblock/refollow dance to no avail to getting an account setup for my custom domain.

Having the exact same problem as above…curious to see a fix.

We're still blocked on the fediverse mostly not being able to handle username changes. 😢 From #1074 (comment) :

Sadly this specific issue isn't quite shovel-ready yet. The main blocker is that some fediverse software, notably Mastodon but also others, can't handle username changes yet, #1074 (comment), so if we fully implemented this and sent out Updates for bridged actors, that would break them in the fediverse in various ways. 😕

I think we could send out Updates (and fix the Bridgy Fed status page for the handle-changed account 😉). We can leave the WebFinger redirect in place unless someone else takes the handle and I think then even Mastodon shouldn't misbehave.

The main adverse effect of current implementations on the fediverse is that the visible handle won't be updated in those instances for now, as they just ignore the preferredUsername when they update remote accounts.

As I reported elsewhere, I'm having the same problem.

I'm having the same problem with Sharkey (Misskey fork), except it's worse: the bridged account is broken and now longer shows any new posts or replies. Reposts are still bridged as boosts, but actual posts are not federated. I know that Misskey doesn't really support WebFinger redirects, so maybe that's related?

Misskey doesn't really support WebFinger redirects

Whoa, really? You mean, if Misskey does a Webfinger lookup, and it redirects, they don't follow the redirect?! That's...not good. Webfinger explicitly allows redirects: https://www.rfc-editor.org/rfc/rfc7033#page-9

it does support WebFinger redirects though it has issues if the Webfinger points to the own instance

should not be a issue for bridgy

We're still blocked on the fediverse mostly not being able to handle username changes.

Even if a bluesky username was deleted on the fedi, this still blocks recreating a fedi account with the same or renamed bluesky username?

it does support WebFinger redirects though it has issues if the Webfinger points to the own instance
should not be an issue for bridgy

OK...? Fwiw Bridgy-Fed-bridged web sites that use their own domain, like mine, @[email protected], redirect across domains, eg https://snarfed.org/.well-known/webfinger?... redirects to https://fed.brid.gy/.well-known/webfinger?....

Whoa, really? You mean, if Misskey does a Webfinger lookup, and it redirects, they don't follow the redirect?! That's...not good. Webfinger explicitly allows redirects: https://www.rfc-editor.org/rfc/rfc7033#page-9

After checking the code, this is apparently what it does:

1. A webfinger request is made for @user@host. (after calling the host-meta and identifying the correct webfinger URL, of course.)
2. The client follows any HTTP redirects.
3. The response is parsed to extract the first self link. No other validation is performed, including alias checks. No webfinger redirects are followed.
4. The original input (@user@host) is discarded, and the returned URL is fetched to create a user.
5. If a user already exists for that URL, then it's returned as-is.

Thus, a redirect will "kinda" work on first fetch, but will not update the user if they change username or host.