Technology

You also have to account another type of "ping" if a user lives in a cave 300 meters deep under sea level

Maybe I should clarify with "each user successfully spun up..." I'm mostly curious if the 5000 microservers trying to federate is a more sustainable access pattern than 5000 users hitting the website.

Since federation is an async process, it can be optimized on both ends in a way that user browser requests cannot.

At the same time, federation would overall result in more bandwidth being used because not every user wants to view every post in the frontend.

that ansible book works great, its just a bash script away from regular user DiY.

I've watched people who never used a computer install blockchain nodes and miners (including the networks). If someone wants to do it, they WILL figure it out.

So let's say we want to scale up to several million users - what would that look like?

I hadn't even thought of the moderating yet.

It wouldnt really be full P2P: I'd expect moderated communities to act as a funnel which everyone interacts with each other through. I wasn't really considering the hypothetical micro instances to be like a normal server, since even when federated its unlikely that they would consume as much federation bandwidth as a large instance. Most people wouldn't run a community, simply because they don't want to moderate it.

Realistically, the abuse problems you mention can already currently happen if someone wants to. It's easier to make an account on an existing server with a fresh email, spam a bit, and get banned than it is to register a new domain ($) and federate before doing the same. I think social networks would have a lot less spam if every time you wanted to send an abusive message, you had to spend $10 to burn a domain name.

Most of the content would still live on larger servers, so you end up moderating in the same place. Not much difference between banning an abusive user on your instance and banning an abusive single-user instance.

So you're saying that there's a sweet spot between the number of servers being federated and the number of users per server. I wonder what the optimal network distribution would look like.

I think the main difference between fediverse and email WRT cache instances is that if you create a cache instance for email, you're only caching your personal emails. If you create a cache instance for a lemmy community, you're caching every event on the community.

My intuition says there's probably a breakpoint in community size where the cost of federating all events to the users who subscribe to them becomes greater than the cost of individually serving API requests to them on demand. Primarily because you'll be caching a far greater amount of content than you actually consume, unlike with email.

Edit: That said, scaling out async work queues is a heck of a lot easier than scaling out web servers and databases. That fact alone might skew the breakpoint far enough that only communities with millions of subscribers see a flip in the cost equation...

I'm also running my own instance, very few users and everything is really fast. Because I'm not on the same instance as all those users.

I think there is a tipping point somewhere.

I think the connection calc is n * (n - 1) / 2 (at least, that's what it is for mesh networks) so 1000 servers would be handling ~500k connections each.
That would be for 1000 users.
Those connections might be more lightweight, but there are significantly more of them (might even run into OS issues with that many open connections)

If each server was handling 50 users, the mesh connections would then be 1.2k.
50 users should be a blip wrt server load, and 1.2k mesh connections is more manageable.