How Hubzilla interfaces with ActivityPub
Artikel ansehen
Zusammenfassung ansehen
Responding to
this comment by @
Jupiter Rowland ...
@
Jupiter RowlandOf course, the downside of it would be that e.g. Mastodon users receive messages from you through an entirely different address. ... They'll simply assume that you've got a new account, that you've moved instances, and they'll follow your clone along with your main.
Yes, that's exactly the problem. Having messages arrive in ActivityPub from multiple Hubzilla instances is confusing. You'd have to know how Hubzilla works to understand it, and the whole point of an abstraction like ActivityPub is not to have to know how all the other systems work.
The only way to mitigate this in the long run would be ActivityPub and its implementations at least understanding and correctly handling nomadic identity as implemented in Zot and Nomad.
Not sure.
Long term it would be better if nomadic identity was widely adopted and protocols develop that makes that happen well.
Personally I feel like Hubzilla has taken a strange route in how it handles ActivityPub, given that Hubzilla knows ActivityPub doesn't understand nomadic identity.
I think I'd have been tempted to have only the primary instance ever connect to ActivityPub. Messages sent within Hubzilla (primary or clone) while the primary-ActivityPub bridge was out or delayed would be delayed. ActivityPub contacts would never have to "reconnect" from clones, because all interaction with ActivityPub contacts would be via the primary instance.
Expecting ActivityPub to handle nomadic identity when we know it doesn't is likely to lead to strange results. If ActivityPub expects only one identity, it should be given only one. If someone chooses to change which hub is their primary, at that point the contacts would need to be reconnected on the new primary hub, and that hub would take over handling all communication with ActivityPub on behalf of itself and any clones.
