Correct me if I’m wrong. I read ActivityPub standards and dug a little into lemmy sources to understand how federation works. And I’m a bit disappointed. Every server just has a cache and the ability to fetch something from another known server. So if you start your own instance, there is no profit for the whole network until you have a significant piece of auditory (e.g. private instances or servers with no users). Are there any “balancers” to utilize these empty instances? Should we promote (or create in the first place) a way how to passively help lemmy with such fast growth?
A network of (“thousands of”) servers has — like most things — pros and cons.
Some of the pros are:
- The network is more resiliant against outages. If lemmy.ml is down, all other users can still access the network.
- It’s hard to take legal action against the network or to buy it out (like Big Players™ like to do to get rid of potential competitors).
- It allows various similar or even conflicting moderation policies. The network, i.e. the infrastructure doesn’t allow or prohibit any specific opinion (the communities do).
- It allows for different ways to pay the bills: goodwill of the admin, donaitions, ads, fee or selfhosting. The latter also allows great control over the data so you control your privacy.
Some of the cons are:
- Content is replicated across servers, which increases the total amount of data stored.
- Latency and speed suffer.
- Interoperability with the wider Fediverse is less than 100%, which can create confusion and frustration.
- Discovery is more difficult.
I just commented on this in another thread: https://lemmy.world/comment/76011
TL;DR: The server-to-client interactions on Lemmy are a lot heavier than the server-to-server interactions, so even if you’re just using your own server to interact with communities on other servers, it should still take load off of the servers you would have been using directly.
Huh, so the problem is about just serving static assets? TBH, I think this problem should be mostly solved, especially for such minimalistic UI. Maybe some (free) CDN? Also UI can use any lemmy server for most of requests (e.g. fetched federated_servers fom a bootstrap node) and use “logged one” only for user actions. I think it isn’t a terrible difficult task for the current ui (it has it’s own backend).
To expand, every user has their custom set of content that they want to see, which needs to be queried from the database. Mainly their subscriptions, those will rarely be the same between any two users, and they need to be aggregated according to the sorting method the user wants. Or other personal things, like every user’s messages/replies/notifications/settings.
It’s a bit worse than that actually. I’m now seeing several communities with exactly the same name that originate on different servers - so clearly Lemmy doesn’t have a rule about duplication once you cross a server boundary. That’s going to get unwieldy quite fast particularly if, I dunno, “Aww” gets popular on two separate servers at the same time - I guess I’ll have to subscribe to both…
This is a feature, not a bug. But we definitely need a solution to make subscribing/coalescing them easier for users. Mastodon allows subscribing to topics (hashtags) - I think something similar is needed here, but that will evolve naturally over time.
You are right. On the one hand, it’s kind of bad, naive distributed architecture (my day job), it could have been done much better. On the other hand, the more important point is that it demonstrates an alternative to centralized. We’ll learn a lot about usage patterns here, get new ideas, and either improve Lemmy or build something better from the ground up. Big thanks to Reddit for driving users this way to test scalability and get much better knowledge of usage.
It’s not distributed architecture as you normally think it - it’s a decentralised federation. It’s an important distinction from your typical distributed architecture app.
