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...
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.
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".)
