I (like many people) have been paying more and more attention to distributed social networks over the past several weeks. For the uninitiated, these networks (hereafter referred to as “the Fediverse”) are individual instances running software which communicate with each other over standard protocols (mostly ActivityPub). A user on one instance can follow and interact with users on other instances in a mostly-transparent way, somewhat similarly to e-mail. The general philosophy, I think, seems sound: by decentralizing things, you reduce the influence — and potential damage — of any one entity.

I’m new to fediverse. For a long time I assumed it would be possible to have a single identity separate from the ActivityPub instance I’m using and tried to figure out what am I missing. Recently, I figured out that it was not the case. People generally have multiple accounts for interacting with different aspects of fediverse. It still bothers me a bit. So I did a search and found this note from 2018 that summarizes my thoughts very well.

I’m wondering if there are others thinking about this, or having multiple accounts has been accepted as the “correct” way of interacting with fediverse?

I think separating identity from the instances would really be a step forward, but as I said, I’m new to this and maybe there are things I don’t understand?

  • Witcraft (Hubzilla)@hubzilla.fediversum.deEnglish
    1·
    1 year ago

    @shrugal

    What we definitely should add is some sort of instance single-sign-on, so you can log into another instance by having your original instance authorize the login attempt.

    In Hubzilla / (streams), that existing functionality is called “remote login” (or technically “OpenWebAuth = OWA”) - and it’s the prerequisite to share access-controlled local content with connections - Unfortunately, this work only with Hubzilla/(streams) identities, because AP does not support this…

    It would be a blast if this mechanism could be transferred to the AP world (after all, it’s freely available open source…) and let us share the local content functions with our AP connections…