An unspecified "implementation detail" is essentially another way of saying that it doesn't work.

I've ported my account on ActivityPub a couple time, and it's a horrendous experience -- not only do I lose all my posts and have to manually move a ton of bits, but the server you port from continues to believe you have an account and doesn't like to show you direct links on there anymore.

The latter could probably be easily solved, the former needs to be built into the spec or it will continue to be broken.

100% agree with everything in your post. I don't see how it contradicts anything I've said though.

> the former needs to be built into the spec or it will continue to be broken.

Absolutely, but ActivityPub doesn't preclude that. There's no reason for that proposed feature to be incompatible with the spec., or to have to exist in an implementation that is incompatible with ActivityPub.

Fwiw Mastodon, the most popular ActivityPub implementation, is (as is often the case with open standards) not actually fully compliant with the spec. They implement features they need as they need & propose them. This is obviously a potential source of integration pains, but as long the intent to be compatible is still there, it's still a better situation.

and I believe CalcKey? is adding account content migration, which is why Eugen is suddenly talking about account migration again.

Even framing it as 'account portability' is missing the point. I want to own my identity and take it with me anywhere. I shouldn't need to transfer anything, its mine. This model is fundamentally incompatible with how ActivityPub works (no, running your own server is not the same thing as decoupling identity from the concept of a server itself.) Could that change in the future? Maybe, but not without prior art. Even if you think @proto, farcaster, ssb, nostr, or others are doomed, we should be applauding them for attempting to push the needle forward.

It's not incompatible with how ActivityPub works at all.

The ActivityPub spec says that object id's should be https URI's, not that they must. The underlying ActivityStreams spec just requires them to be unique.

All that's needed to provide full portability without a "transfer" is for an implementation to use URI's to e.g. DID's, or any other distributed URI scheme. Optionally, if you want full backwards compatibility, point the id to a proxy and add a separate URI until there's broader buyin.

> the main challenge there is not the spec but getting buying from at least Mastodon

Which is why a new competing protocol is a good way to push for change.

You want Microsoft to become more open? Then start promoting Linux.

You could do the same a lot easier by pushing an incompatible change to ActivityPub that'd be easy to adopt.