I've been having a nagging feeling about the goals and ambitions of the current design of the #ActivityPub-driven Fediverse... I think we're going in the wrong direction, and I'd love your take on my thoughts.

Axiom: We need reply controls to combat abuse and harassment.

For that to work, control of the conversation must remain with OP (whos platform we're piggybacking on, btw) and we cede control of our reply.

This also means that we can only participate in the conversation when OPs server is available to append our contributions to the conversation.

If that is true, why do we federate as much as we do? What do we get by trying to replicate all the functionality of OPs application, besides a Sisyphean task of staying up to date with everyone and a very expensive CDN?

Alternatively, we could interact *on* OPs server. OPs server is authoritative and by definition up-to-date. We could bring our own identity to OPs server for the interaction and simply federate notifications, previews, links, and summaries.

What would such a world look like? Servers would be carriers of identity, and distributors and aggregators of notifications, links, and previews, all of which can be specified exhaustively.

Imagine that...

Follow

rambling about different kinds of decentralization 

@joelving There are some pretty severe accessibility implications in this, unfortunately, unless you are *extremely* careful about how you approach it (at which point it starts looking more like what we have now).

Likewise, you lose a lot of technical resilience - which isn't actually that important on a technical level, but *is* important in terms of making it Not A Big Deal when something goes down, which is in turn a big factor in making decentralized things sustainable at *any* degree of decentralization.

That's not to say that these can never be acceptable tradeoffs, but they are tradeoffs that need to be made very deliberately, compensated where possible, and with a very good understanding of what it gives and takes to and from whom.

There are some things for which the model you're suggesting makes much more sense than the AP model; code forges and community platforms, for example. These usually have a distinct 'home' and so decentralization on a protocol level doesn't matter much, and identity is really the only relevant factor. I don't think AP is that useful in Forgejo for example.

But for something that's trying to basically do emergent communities in a global shared Twitter-esque space, like Mastodon, I'm not sure that centralizing interactions onto servers would still be worth it once you reason through all the less obvious implications that it has.

· · Web · 1 · 0 · 1

rambling about different kinds of decentralization 

@joepie91 Thank you for the feedback. I think my main argument is that once we require reply controls, we immediately centralize "a conversation" to the OPs platform in both a technical and social sense. Our reply doesn't make sense outside the conversation, which is why I'd argue that it is acceptable to give up control of it. Unlike quoting which leverages our own platform socially.

rambling about different kinds of decentralization 

@joelving That's true to a degree, but not entirely - for example, enabling reply controls on a post means you centralize the control over who can participate in that conversation, but it doesn't imply that it is therefore acceptable for the conversation to become inaccessible to everyone if the OP's server has an outage.

There's a distinction to be made here between whether something should be *conceptually* decentralized versus whether it should be *technically* decentralized, and those aren't always going to have the same answer. In the cases where they don't, the challenge is precisely in finding a way that gets you both answers. (At which point "centralized control on a decentralized system" is usually easier to implement than "decentralized control on a centralized system".)

rambling about different kinds of decentralization 

@joelving I guess a more succinct summary of my point would be that "decentralization" is a catch-all mechanism for a pretty broad set of social and technical properties, and often people want some but not necessarily all of them.

rambling about different kinds of decentralization 

@joepie91 that's what my flippant comment about a "very expensive CDN" is about. I think of it more in terms of logic than serving of data. Data is relatively "easy" to replicate, either using a CDN or content addressing. The painful part is the logic to interact with it.

Sign in to participate in the conversation
Pixietown

Small server part of the pixie.town infrastructure. Registration is closed.