Granted, my comment doesn’t add much to the discussion, since this domain ownership issue would have been a problem in ActivityPub too.
At least there's already a relatively established dispute mechanism for domains.
This wouldn't be a big deal in practice (besides losing the domain). Domain usernames are just the combo of you telling Bluesky "I intend to use this domain name" and then you placing a TXT record on the domain to prove you own it. If you want to change domains (or, are forced to), you just give them the new domain name and you set another TXT record (just like if you had set up a domain name as a username for the first time). The underlying DID is still yours.
https://news.ycombinator.com/item?id=11349870 - Kik, left-pad, and npm (2016)
The identity is just a public key, basically. There's a resolution service which uses domains, but you can move the identity, with all the data, to another one.
In ActivityPub URLs are the identifiers, be it for actors or anything else. And the URL can be just of a domain, therefore it's perfectly possible to have domain named identifiers.
ActivityPub is a federated social networking technology popularized by Mastodon.
Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP’s double-@ email usernames, and the goal of having large scale search and discovery (rather than the hashtag style of discovery that ActivityPub favors).
from https://atproto.com/guides/faq