Comment by jcgl
First of all, non-standard extensions to federated protocols have a pretty rough history. Even when an extension reaches median adoption (rare, I assert), the long-tail adoption is dismal. For something as fundamental as
Second of all, how could this just be an implementation-specific extension? The failure mode (of a client not supporting the extension) would be outright broken. To have name portability, the client needs a two-step to first discover the name's server before then connecting to that server. Whereas now (afaiu), the server is already identified by the name. That's a fundamental change in what identity means at the protocol level.
I'd love to be corrected by someone more intimately familiar with ActivityPub. But until it has mandatory (and mass-adopted) support for something vaguely like SMTP's MX records or whatever the equivalent for ATProto is, name portability is a distant dream.
I'm not intimately familiar with the spec, so don't take my word as gospel, but as I understand it, current implementations already do name discovery. It's just that every implementation hardcodes the server name. IIRC some people have applied some kludge where they put a .well-known document on their own server to point to their instance's account, but it's still pretty spotty without that server being actively aware of that identifier. But (again, if I'm understanding correctly) servers could be updated/written to support that properly.