> So ironically I see far less reason for identity portability in that ecosystem since (to my knowledge) the server you're using doesn't have much of an impact on your experience.

One of the biggest reasons why people change Mastodon instances is because the instance shuts down.

I had to do an emergency switch because my instance admin went AWOL, and it was breaking down technically. In other cases, the admins decide they don't want do run an instance anymore, for whatever reason.

If posts could be migrated on Bluesky, that would be a vast improvement over Mastodon.

You are right, that is definitely one very good reason why many people move (though in the Mastodon world, I would argue it's probably not the biggest reason outside of weird events like the shutdown of mastodon.lol), and in the Bluesky world, probably the primary reason (since there's no concept of local moderation or community policies that you might disagree with, thereby leading to an instance switch).

> I would argue it's probably not the biggest reason outside of weird events like the shutdown of mastodon.lol

A number of such events have occurred.

I haven't actually heard of anyone moderated off an instance (aside from spammers), but maybe I hang with the "wrong" crowd for that.

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

> So ironically I see far less reason for identity portability in that ecosystem since (to my knowledge) the server you're using doesn't have much of an impact on your experience

To an extent, though I still think it's valuable for situations where eg. a host might decide they don't want to host you if you post certain content. In the same way: a website host doesn't normally have much of an impact on your experience, unless they decide to kick you off or otherwise exert control over you

> moderation as a separate service, which has to be funded... how?

It's an interesting question; I think some of it will be answered with algorithmic/AI-based filtering (false-positives are more tolerable if users have the ability to opt out!). People have also talked about a model where you can just share (or subscribe to) communal block-lists. So maybe your circle of friends does its own internal "moderation" just by using the site (blocking people is already a normal part of my day today usage of both bsky and twitter)

With a platform this open and flexible, there are tons of options to be explored!

> And this is all assuming they actually pull off what they claim, and it's still waaaay too early to say if this'll all work in practice.

It definitely is! But I'm excited and hopeful