@decryptlyfe OK, setting aside the security concerns, if your mental model is email, what would building this look like in email terms? (Warning, long rant below 🙂 )

For incoming messages: Alice @ X gets forwarded to Alice @ Y? Or vice versa? Or both? For outgoing messages: Alice can choose to send a message as Alice @ X xor Alice @ Y? Are all outgoing messages duplicated by the client to both servers? Obviously followers and following don’t have direct email analogs, but you can see how this would create extra noise, whereby every follow for Alice @ X gets duplicated to Alice @ Y and vice versa. What if Alice @ X automatically allows follows but Alice @ Y is locked and requires Alice to manually approve them?

My understanding of the ActivityPub standard is that this kind of arbitrary account linking is not well supported by the design of the protocol.

The “email” solution to this would be to have Alice own Alice @ alice’s domain and allow forwarding/aliasing to the equivalent of Google or Microsoft or Yahoo. Alice has the opportunity to migrate the backend service, but without any apparent change in activity pub handle. The problem is that ActivityPub doesn’t even run based off of something that looks like an email handle (alice @ alice’s domain), but based off of the profile URI. So Alice would need to have an HTTP endpoint at alice’s domain /users/Alice that performs the relevant redirects.

I think at a certain point, what you have is really an ActivityPub (AP) implementation designed for this “forwarding” or “aliasing” use case. The biggest weirdness I think is that the Outbox / Followers will have to live on this forwarding server while the Inbox / Following will live on the backing instance.

This still won’t solve the problem for most people, for the same reason that most people won’t bother to set up their own AP server, but it would be much more lightweight than Mastodon and perhaps even than Pleroma or other Mastodon-compatible AP implementations.