L. Rhodes started a discussion that became a fedi megathread, kicking of with this observation:
I’ve seen several people lately arguing that Bluesky is a fediverse network, on the premise that interoperability between independently-run instances is enough to qualify. But I think that misses something fundamentally distinct about the fediverse—namely: federation. Which is a particular social relation, structurally analogous to political federation: autonomous, mostly self-governing states, mutually deciding to associate in a united network.
The case is made that on the Fediverse the federation is first and foremost a social structure, rather than a mere technical construct on the protocol level. And that many discussions delve too much into the technical aspect of federation (think for instance bridging of protocols like with AP vs ATProto). This social perspective then subsequently determines whether one can call their app or service as “part of the Fediverse” or not.
This take raises additional questions such as (quoting L. Rhodes again):
Is Bluesky federated? That’s debatable. Bluesky is designed to be (mostly) decentralized. […] In a lot of ways, ATproto looks like it was designed to resist federation. […] So I wouldn’t call Bluesky federated. If you wanted to insist on calling it federated, I think you would need to qualify the term, at the very least.
And going one further in stating that the feature set of ATProto gives it different social / socio-political aspects:
[…] a lot of the design features that distinguish ATproto from AP are concentrated around giving individuals the maximum amount of autonomy from one another. In many ways, it strikes me as a radically libertarian social structure, but I don’t suppose everyone will prefer to frame it in those terms.
That is an interesting and debatable observation. The question also arises if ActivityPub, in the ways it can be used rather than how it is used today, doesn’t have much of the same capabilities. There’s not really something in the AP protocol that says that an instance should be like a separate community (a federation). The protocol is on the level of interconnected actors, and these actors can model any kind of service, exchanging specialized msgs defined in an AP protocol extension.
A general observation is the:
- Incredible ease of mixing social vs. technical perspectives of the social network.
- In ways that confuse discussions on the impact of changing functionality to the social fabric.
- Where the tendency is that the technical perspective gets most attention.
- And externalities like socio-cultural impact become apparent late in the process of introducing change.
So a question to ask is:
Question: Can we decouple the technical and social perspectives of the Fediverse properly?
The assumption and premise of Social experience design (SX) is that: “Yes, we can!”
And in fact we have a name for that already: The vision to explore a Peopleverse.
The Fediverse (technical) lays the foundation for a Peopleverse (social) to shape up.
Peopleverse here is not a name for the social network. It is merely a concept. But it follows that this concept should be able to be modeled, and in such way that it isn’t technical in nature. It is the social construct that is spun up by the entirety of protocols, apps and services that exist in the Fediverse.