1 yr. ago • 66%

Are all these thousands of lemmy servers useless?

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?

40 comments

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.

5
- What makes a distributed system good that Lemmy hasn't done? Seems like a pretty robust system to me, seems like scaling issues are on the instance host themself. With Reddit's experience, I don't see how there are issues
  
  2
- 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.
  
  2
  
  Can you explain what's the difference?
  
  0
- it could have been done much better.
  
  Care to expand on this point?
  
  0
  
  Disclaimer: I've only looked a bit at the protocols and high levels descriptions of how it works, and this is just my understanding of it. But it seems to track.
  
  let's take .. Selfhosted@lemmy.world for example. Right now lemmy.world is the Source of Truth on this, which means if you sign up for it on a different host, let's say myawersomeinstance.com, that first contacts lemmy.world, copies over posts, and then subscribes on new posts for that. Actually not 100% sure if lemmy.world contacts myawersomeinstance.com when there's a new post, or myawersomeinstance.com polls lemmy.world.. But anyway, point is, lemmy.world is authority on it. myawersomeinstance.com also have Selfhosted@lemmy.world data, but it's a copy of it. And lemmy.world is only authority. So if you post something, your server then sends it to lemmy.world and waits a reply. Then lemmy.world contacts all instances that has at least one user following this to tell about the new post. And that new post now exists on a few hundred databases.
  
  The problem is the scaling is whack. Okay, you can have 5000 federated servers with users subscribing to Selfhosted@lemmy.world, but that means lemmy.world needs to update 5000 servers per post, and there'll be 5000x storage used for that post, and ALL 5000 servers contacts lemmy.world to get the new good stuff.
  
  Frankly, it's a scaling nightmare. As for a different approach, you could have private / public keys and sign updates from lemmy.world and allow the other instances to fetch the new data from each other. That would also allow more relaxed caching, since it would be generally lower cost to re-fetch the data. Now you need aggressive caching because you don't want lemmy.world to keel over and die form every server on the planet wanting to hear the latest and greatest posts all the time.
  
  1
This has definitely been a problem with communities being created on the bigger instances and not utilising smaller instances. Happy for someone to say I'm wrong etc, but I think there would be merit in capping instances to x number of users or communities, to force the user base to spread out.

Also, the way signups work, (ie you find a community you like then click sign up but that signs you up to that instance), further exacerbates the issue and the confusion around how federation works. The sign up links on each instance should lead either to a page with an instance finder, or to a random instance that matches the profile of, and is already federated with, the instance you were on. Otherwise the larger instances have a monopoly and are just going to lead to a bad user experience when they can't cope with the traffic.

It's a self defeating prophecy if users only want to sign up to the instances with the big communities, because then everyone is going to keep creating communities there and nobody is going to want to join a smaller instance.

I might be talking nonsense and am happy to be told why that is all wrong :)

2
- Yes, there should be instance caps, and they should be visible to users.
  
  That way users can scale, choose, without much thinking.
  
  This same techinque works everywhere, for example MMO games. You have availability visible and choose servers according to it.
  
  This would fix scaling partially without much technical changes.
  
  1
- If that cap idea was to exist, it would make sense to have it based on the balance of users across the federated servers, so of there's enough with a similar amount it raises the cap
  
  1
I'm quite worried of how well this federation system will work in the long run, especially when more people coming from Rexxit. As people make more post/comments, every federated instance will have to cache more redundant contents from each other, which also will use more storage thus increasing the fee of every instance hoster. There's also another problem of visibility in search engines. Because Lemmy/Kbin can be hosted by anyone, it makes searching on a specific domain impossible, unlike how I can just add "reddit" in the search query. Also since there are multiple Lemmy/Kbin instances, there's a chance there'll be similar communities spread over, fragmenting the communities even further. Until they can find a way to fix those problem, I don't think federation is suited for large scale communities.

As for fragmentation problem, maybe adding a global search for communities like this will help reducing fragmentation. Users can still make their own community in their instance, while other people who don't need to can easily find the community they want.

1
I've suggested a routing protocol to the lemmy devs - to use federated instances to route all the messages to other federated instances. The idea was received with some interest, but it seems that people believe that there's still a ton of performance that can be squeezed out from the current architecture through optimisations.

1
Since Lemmy instance are not backed by commercial interest, but rather by nice volunteers and donors that have money and time to spare, they will be heavily affected by economic downturns (we still can see commercial interests still affect users negatively tho with reddit). Here are my thoughts on the matter:

as far as I understand the owner of the domain: https://lemmy.world even has to pay for this fancy domain name in the DNS system ... every month subscription service style

(and tbh I hate the Domain name system) why should I fund it with my own money?

if you hosted with an onion site over tor that expenditure would not exist, but how would users discover your site then? Let me know if you know something about this

in times of deflation (meaning money becomes worth more, spending some money on a self hosted lemmy instance becomes nonsensical)

tbh if I hosted a lemmy instance and the users of my instance posted high quality content in quantity I would use it to train my own LLM, that would at least create some economic incentive for me to host such a page ... but managing spam and bots will be HARD

That is why you should always back up your comments on your personal device, would be nice if lemmy had an automated way of doing this (I should look into this more)
1
- Domain names are cheap, like $25/year.
  
  1
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...

0
- Well one instance shouldn't monopolize a community. If it takes a dump on one instance at least it exists elsewhere. If I want to start up my own cat community I don't see why that's an issue.
  
  1
  
  I agree, I don't particularly see this as an actual issue... Nothing stops you from subscribing to both.
  
  Just like there could be a saik0@gmail.com and a saik0@yahoo.com. Nobody is confused with emails when it comes to this... The difference is that it's slightly more work than reddit because r/aww is one particular thing and it's assumed we're talking about Reddit because of it's unique format. Here it's just c/aww on lemmy.ml, but that's a bit of the point of the !aww@lemmy.ml structure of naming.
  
  I LOVE that there's !aww@lemmy.ml and !aww@lemmy.world. Different communities ran by different groups will end up with different content. Then I can shop for the content I want myself.
  
  Nobody can singularly own the name. I always found that to be a big problem on reddit. r/trees comes to mind, if there was an actual arborist community that want r/trees, well they were fucked. And that's kind of jacked. This way it doesn't matter. Just pick a different instance that doesn't already have c/trees and post there... or better, start your own instance to host it.
  
  I don't know... in the future people could even start up instances of lemmy on domains like lemmy.jobs, lemmy.help or lemmy.hobby to aggregate major communities based on topics. lemmy.jobs for instance could be an instance that houses professional the arborist and the domain would make it clear the intent. Or even better... drop the lemmy all together and register jobs.social or similarly descriptive domain names.
  
  I know we're all a hodge-podge of domains now because a lot of us are just spinning up instance on domains we already have... but the potential is there.
  
  1
- 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.
  
  1
  
  Maybe have them coalesce based on channel name, but have local mods on each server. It'd be great if you could share moderation between trusted servers or trusted mods on different servers as well (this could be on a per-community or per-server basis).
  
  1
- I don't get argument about duplicates. The same situation was on reddit - you've got few, sometimes more, subs about same topic. You could subscribe to whichever you wanted. Why on Lemmy this is suddenly a problem?
  
  1
  
  I think users are still having trouble with the mental model for browsing Lemmy.
  
  The first interaction with the service is already fragmented - you need to choose where to create an account and start browsing. Even though you can browse communities from other servers, people are now seeing them through the lens of "fragmented" "my server vs other server" and that creates the illusion that these duplicates are somehow a huge issue.
  
  But duplicates can actually be quite useful - a community called "memes" on Lemmy.world could attend to a different audience than a community also called "Memes" but made in an instance entirely in French.
  
  Also, if two instances have two communities you enjoy, with the same name... Subscribe to both? Nothing stops you from doing that. It's okay. Reddit had "me_irl" and "meirl" which were the exact same, but with different mods, a relatively similar number of subscribers and quite honestly the same content. I didn't know the actual difference between the two, and I still do not know - I just subscribed to both and kept getting depressing memes to cry before going to sleep. No issues.
  
  0
- That's true, and the point I guess. You sub to all relevant communities and the overlap isn't an issue because it's different communities with different instances making content with others interacting through federation. The "subreddit" is diversified to the top communities in all of the highest subscribed instances. It's just the nature of the beast, but once you find all the top comms it probably doesn't seem so bad.
  
  1
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.

0
- That's news to me. I thought serverto-server interactions would be heavier since other instances will keep fetching contents from your instance once they start federating. I guess it's better to join less populated instances instead of crowding on a single instance.
  
  1
Every server just has a cache … there is no profit for the whole network …

I wouldn't say that caching is no profit. Yesterday there were several times when lemmy.ml was struggling or effectively down for some people, but despite complaints over there I could read lemmy.ml communities just fine through my instance. Caching meant that I was isolated from the service interruption, and the lemmy.ml server was isolated from my contribution to its load.

0
- As I said, there is no profit from empty instances. Of course, the federation itself is good and fail-proof in this way. But if nobody asks for this cache, it's just an Internet Archive of a sort.
  
  0
  
  It only takes one user for an instance to not be empty. Every bit of decentralisation adds resilience to the whole. But more decentralisation adds more resilience, so let's try to spread out the communities and users.
  
  1

You've viewed 40 comments.