It absolutely happens.

Eh, tbh though, I don't know why I was arguing that point, it really doesn't matter one way or another.

You absolutely identified a very good reason to want to switch instances, and why account portability has value in the Bluesky world.

I wish ActivityPub had a better solve for this, but unfortunately a true federated model makes that awfully difficult (since the entire ecosystem has to update its view of where posts are located).

Similarly, if I'm in a length email exchange with a friend on Gmail, and then I move to another service, there's no way to update my friend's account to "rewrite" those emails to point to the new service. It's a deep limitation in the model itself. The only question is whether the tradeoff is worth it (and, to me, it is).

Another very cool decision they made for AT Protocol/Bluesky is making user identity domain name-based. So you can just sign up as a subdomain of eg .bsky.social, but you can also bring in a custom domain name. This neatly solves identity-portability and even trust/verification in one swoop

(you can also change which domain your bsky profile is identified by, which, I'm not quite sure how that works at a protocol level but it is possible)

> This neatly solves identity-portability and even trust/verification in one swoop

Until you lose control of the domain for any number of reasons and then whoever buys it happily continue on as you. A simple credit card processing problem can lose your "identity" at some point in the future.

The same is true if you use a custom domain for email, for your company's servers, for any number of other critical things. It's no different (and arguably those other things are more catastrophic than losing control of a social media profile)

Also, to emphasize, regular people who don't do those other things don't have to roll a custom domain on bsky (and are unlikely to). But eg. if NPR wants to make a bsky account under @npr.org, that's really quite good verification that it's "the real NPR account", and nobody has to deal with any of the politics around verification which have become a dumpster-fire on twitter since Musk took over

Using a domain for verification isn't the worst idea but there's still some things to work out. How will the service handle homoglyphs domains? Are they going to ship a webfont that makes homoglyphs obvious? Will they display punycode? It's all well and good the real NPR can use @npr.org but what will ｎｐｒ.org end up looking like on the service? Will it be distinct enough normal users will be able to distinguish it from the real domain as displayed on the website or app?

Again, it's a strict improvement over what came before (centrally-managed namespace), and it lumps bsky's problem in with the existing place where the web is already wrestling with these questions. It hitches its cart to the world's biggest and most robust decentralized-identity mechanism; I can't think of a better approach to take, perfect or not.

Actually the domain (handle) resolves to your DID which is you primary identifier and which contains your public key and without coresponding private key, nobody would be able to happily continue as you... See: https://atproto.com/guides/identity. It would be better though if the DID didn't contain the link back to the domain, so that you could continue with your identity under different domain...