@vanderwal@elipariser I'm interested in scalability. Most of the analyses I've read start with uninformed assumptions about the fediverse as a strawman and then draw unfounded conclusions from those bad bases.
@vanderwal@elipariser also, we have a really dumb problem in the tech world, where we conflate scalable business models (jackpot models where small input gives great output at low probability) with scalable system architectures (can add resources to keep up with demand). It's really a ridiculous mistake, but it's also two concepts that lie very close to each other.
@evan it sounds like you were watching explainers I was making yesterday about basics of scaling and complexity and why the center is simple and need solid next tier that handle the deviatiations and divergent rules / constraints for all that follows in that chain.
The cost of hosting a server goes up significantly when you've got superusers on your server -- accounts with many hundreds of thousands or millions of followers.
This is true for many kinds of social networks. I know that at Twitter, it was a major problem in the early days of the company. And that was for distribution within their own environment.
@evan@vanderwal Yeah. Definitely thinking about the latter. The question I was thinking about is... if the cost to host a server goes up dramatically/exponentially as the network scales, what does that mean for decentralization?
@elipariser@vanderwal the obvious solution is that people who want that kind of reach should be paying for the burden they put on the network. Servers with open registration should put a limit on number of followers (~10K is a good number) and people who want to be broadcasters should host their own servers, or go to specialised servers that can manage that load.
@elipariser@vanderwal another issue is that with fan-out, it takes a non-trivial amount of time to deliver to each subscriber. So, instantaneous responses are hard to guarantee.
Platforms where the publisher and subscriber are on the same server can fake this by distributing to the tiny percentage of subscribers who are online *first*. The vast majority get their messages a few minutes, hours or days later.
We can't fake this, usually, although there are tricks we could do.
@shoq This is great, but I'm more talking about some of the technical/structural scalability problems... e.g. if every post interaction has to be pushed to every server, how does that hold up in a world where there are tens of thousands of servers and posts with tens of thousands of interactions?
@elipariser@vanderwal we can make some improvements at the protocol level by reducing the delivery overhead, say by using WebSockets to keep connections between servers alive.
Another possibility is using lighter processes for job handlers. That's a Mastodon issue rather than a fediverse one.
@vanderwal I'll read through. I think a typical AP interaction has 3 hops: sender client to sender server; sender server to receiver server; receiver server to receiver client.
@evan Yes, agree. Just dealing with the second and explaining why keeping the center handling things as simply as possible and put the deviations to the core needs. But, also need to keep the hops away from the core to a minimum to reduce latency.
@tedcurran you might want to think that one all the way through. What's different between a popular Toot and a popular 2-hour movie in 4K? What are people's expectations for each?
@evan@elipariser@vanderwal It seems to me that this was the problem BitTorrent was originally meant to solve - decentralizing the hosting of massively popular assets by making downloaders simultaneously upload as well. ?
@evan@elipariser@vanderwal sorry for the necro, but regarding Evan's Triangle-- what if, for wide distribution, you use the tape tree concept? That is, the sending server distributes to a much smaller number of intermediary servers, each of which sends to a fraction of the recipient list? It would be non-trivial-- for one thing, the intermediaries would have to know which recipients they're responsible for-- but I'm not convinced it's not possible. Not much load on any one server.