v.0.0.6
v0.0.4 - Per requests and concerns: Defaults changed and options added to prevent overloading servers, hitting rate-limiting, filtering to top x communities, etc!
Thanks for your support!
I was working on something like this to add a bot user and follow active communities but got distracted. Looks like I can quit that side project hahah
I salute your efforts for working on it anyway
ahah thanks, for posterity this is how far i got. Only needed to add the command to follow https://github.com/Death916/lemmy-federation-bot
I’m happy to help or take PRs for lemmony. There is also https://github.com/Fmstrat/lcs which I didn’t know about until well into lemmony.
No. Keep at it. More alternatives is betterer.
I made my own tool before I even realised LCS or even Lemmony existed.
I wrote http://github.com/fmstrat/lcs a while back which does similar, but only grabs Top feed communities to reduce load.
I have been using lcs on another account for a small instance and it has been amazing for making the instance feel connected. Thanks!
Glad it’s working out for you.
When I discovered, I felt bad for not checking. As for the load stuff. I intended and wanted to see All the things, and I don’t currently have resource problems for my instance. :) We’ll see how that fairs as things continue to grow!
For anyone who might know:
So if I’m understanding this right, the bot account you create for this is the one subscribing to every community, so it’s known to the local system, right? As long as I’m not mixing up my main account and my bot account, there should be no observable change on my own account?
How is storage affected on this? If the bot account is subscribing to a number of communities across the fediverse, all that remote content is going to take up quite a bit of space, no?
And will 2FA be supported at any point?
So if I’m understanding this right, the bot account you create for this is the one subscribing to every community, so it’s known to the local system, right?
Yes
As long as I’m not mixing up my main account and my bot account, there should be no observable change on my own account?
Correct, I have it functioning this way and it works great.
How is storage affected on this? If the bot account is subscribing to a number of communities across the fediverse, all that remote content is going to take up quite a bit of space, no?
It does and it will continue to grow. This not not something the tool takes care of, not cleaning up anything old or stale. Space management and “unfollow” is on the roadmap! Currently I can only speak for myself and it is EVERYTHING and it is about 0.25 GB / day of database, and 6-10 GB / day of images.
And will 2FA be supported at any point?
Not on the roadmap. I don’t know how api calls in general work with 2fa since I have not tested or enabled it on my instance. :( Sorry.
EDIT: Changed database/pictures ratio after double checking actual numbers and not looking at used filesystem. :(
Hey, thanks for replying! Good to know about the subscription ownership. I only ran the discovery portion of the script just to dip my toe in the water, because I feared what would happen if I subscribed. That said, if I use the discovery flag, that’s just exposing the different communities to my instance, right? It’s not going to retrieve any remote content?
Good to see that storage management is roadmapped. I probably won’t invoke the Subscribe side of this for my bot account until then.
Understandable about 2FA. I’ll just be smart about my password usage and watch for any updates on that.
Thanks again!
It retrieves the last 10 posts and adds the community reference to your local database. It is the same as putting “!community@instance.com” in the search box and clicking search. The retrieval happens whether you look at the results or not.
Gotcha. Well that was a miscalculation on my part haha. Good to know for the future, though.
A clean up would be nice, maybe something where if there are no subscribers, or local user actions on a community (votes, comments) after a while it starts to remove them.
Hosting an instance myself, I’m not amused, because if forces my instance to literally sync all content there is on the lemmyverse, drastically increasing traffic, storage use etc.
Please don’t force resource consumption beyond any rational usage!
people should just block Federation from “Lemmy.management” to start with. one less activitypub abuser.
Personally, I think the solution for this, is better scheduling of activitypub messages, even possibly caching. What is not the solution, is defederating based off name alone. This leads to the slippery slope of eventual walled garden whitelisted-only Lemmy instance communities, which is not what federation is about.
People can defederate from an instance for any reason they want, but if I get what you’re trying to say: you think people should defederate from any instance that has a user that subscribes to all of their communities.
Saving this for when I make my own personal instance.
The script gets all of the publicly federated communities and “makes them known” to your local instance and then subscribes to them. “All” should be populated with activity from around the Lemmyverse.
Doesn’t that significantly increase the load on your instance and, if many instances use it, all instances? This system isn’t designed with the idea that each instance receives everything from every other instance.
It might be better to run this on a single dedicated site which people can come to to browse. If you could learn where each user had their account, you could send their upvotes, downvotes and comments to that instance.
It increases load during execution. Afterward it’s not significant. My instance is heavily instrumented and monitored. The load this incurs subscribing to 24000 communities is less than adding a single, moderately active user to your instance.
It’s a huge miss if the intended design was to silo information.
What this provides, as far as I’m concerned, is essential to prevent centralization to a few instances.
Is there a better way to do it inherently in Lemmy itself? Probably, and I am excited to help with that!
It is a significant difference if an instance has to federate literally every post made on the lemmyverse.
Well that sounds quite reasonable then. It definitely answers a need for better discoverability of material on Lemmy. And it would be great if something like this could ultimately be integrated into Lemmy itself.
I think your idea is on the right track when thinking longer term and assuming the worst case in both design and admin behavior. :)
The whole network needs to be split into “active” and “archive.” New activity (or at the very least stubs to where new activity is happening) needs to be updated regardless of where it occurs without having to capture anything extra.
If I’ve already run the last version recently is there a reason to run this new version immediately?
Not really. If it worked before, it should work the same, just has more options for control and granularity.
This seems pretty helpful, will spin it up soon and see how it goes.
This is a cool idea. I was curious how subs work and it makes a lot more sense to me now that I’ve spent the time getting my instance setup and read a ton of docs. It feels weird trying to build your list and communities on your own account, while it also populates your instance’s All list. Feels like all of my interests are just out there flapping in the breeze lmao.
As someone who has created a similar tool, I can understand where the concerns from other people come from, but your arguments have merits too, since as you’ve said, it only takes a user subscribing to the top communities to replicate what tools like these can do in a hundredth of the time.
Much of the issues that can arise from the usage of this tool, or an overly enthusiastic user subscribing to all the communities, is simply the centralization of top communities in top instances. In an ideal federated universe, instances like lemmy.ml, lemmy.world or even burggit.moe wouldn’t be the top instances that everyone knows, but rather the communities they host, would have be properly and evenly spread out through the fediverse, greatly lowering any load that any one server might get. Unfortunately, that is not the case, and the top servers have to contend with growing traffic, lowering performance, and of course, being the target of subscriptions from the other smaller Lemmy instances, which would only grow worse with usage of tools like this, and my own.
Is this socially acceptable? Is writing my own tool socially acceptable? Frankly, at this point, after reading all these comments, I’m not too sure myself. My only mitigating factor is that the tool I wrote for my personal Lemmy instance serves around ~50 people, thus I hope that, at the very least, those people would be able to benefit from having the communities pre-seeded for their viewing experience. No one really likes a barren front page after all.
I see that you’ve added a configurable option to only subscribe to the top N instances in each instance, which seems a bit more harsh than my own tool (which subscribes to any instance above a threshold), but given the views in this thread, and your other cross-posted threads, perhaps I’ll be looking to implement that into my own tool as well, before I get witch hunted myself.
That said, for anyone out there curious about numbers, subscribing to about ~800 communities, of which have about more than 50 users/month, my metrics have indicated a disk space usage of about 2GiB/day, 20% of a single CPU core, and about 8~10GiB/traffic a day.
I actually wrote it with the flip side of your centralization argument in mind. If a community exists outside of the popular ones a user may never even know of its existence. Having more show up SHOULD be better to prevent centralization no? It requires the users to change their browsing behaviour but at least they don’t have gonsearching offsite.
Well, yes, accessibility is what most Lemmy users are interested in. The majority of users don’t want to be told to manually crawl through lemmyverse.net, to find the communities that they might be interested in. It is for that reason that I wrote my own tool as well for my own instance, and the users on it.
Unfortunately, because of that reason, most people would rather register on larger instances like lemmy.ml, or lemmy.world, simply because it is easier to find communities on the site itself of larger instances, than smaller instances that do not run this tool, thus exacerbating the problem of centralisation in current Lemmy era.
Until Lemmy authors, or Lemmy admins start taking steps to reduce centralisation, be it by blocking registrations, or by somehow redirecting new users to newer or smaller instances, this will only lead to a feedback loop, where inevitably, an instance may grow so large to the detriment of the fediverse, be it sudden collapse of the instance because of funding (see vlemmy), or by hostile takeovers of the protocol (see Threads).
Wouldn’t doing this result in a massive amount of unnecssary load on the larger instances?
Yes, it would.
I don’t really think so, but i’m open to working with anyone if they see this happening, up to deleting the entire project.
Dumb question I know, but do I leave this running on my instance or on my own computer?
It doesn’t matter. Most of the work is happening on the instance, regardless of where the script is running.
So how does this operate now?
Sorry, by comparing now to what; or was as that a superfluous “now,” like “come on now?”
Well the last one would have just mass Overloaded instances. Just wondering how this one operates differently to prevent that.
The relevant change is this: https://github.com/jheidecker/lemmony/commit/9b0b7232a1a942615eb67a34f2526328a23fcdd5
It’s not meaningful though. It allows one to optionally limit to the top-n communities by active-user count, but the default is still unlimited and the docs still do nothing to explain the abusive load that excessive subscription puts on instances that host communities.
My dude, I appreciate your spirit, but we’re not going to focus on your irrational fear of abuse. I’ll defend myself for being accused of any such thing, or for being irresponsible. This is intended to make things better, and there’s no evidence it’s doing anything other than that.
If you want to contribute, by all means, show us where there is a problem, other than in your imagination, and it will be seriously considered. Until then, your opinion is still valuable, but you are speaking with authority about something you know little of.
My dude… If you want to contribute, by all means, show us where there is a problem, other than in your imagination, and it will be seriously considered.
I had no idea we were doing condescending pet names, this is a fun game. My sweet summer child…
- Federation ain’t doing great.
- Federated replication load scales with the number of instances multiplied by the number of communities they subscribe to.
- Server counts are growing at ~10x per month.
- The defaults of this script encourage single-user instances admins to bump their sub count ~70x from something like 100 communities to something more like 7000 communities.
- Users of this script actually literally don’t understand how federation works. They think they’re proxying through to the upstream instance while they browse rather than getting firehosed with the entire lemmyverse by they’re asleep.
It doesn’t take a rocket surgeon to figure out that global federation worker queues are not in great shape, or that a default that encourages single-user instance owners who have no idea what they’re doing to bump their sub count 70x isn’t helping the situation. If you think this is in my head I can’t help you. But I can help others understand that running this script with default settings is an awful and unnecessary idea.
Your argument does not gain validity by adding irrelevant verbosity:
Federation ain’t doing great.
The linked issue has nothing to do with this script or lemmony.
Federated replication load scales with the number of instances multiplied by the number of communities they subscribe to.
That’s a hasty generalization that you just made up.
Server counts are growing at ~10x per month.
That’s great! I hope they keep growing!
The defaults of this script encourage single-user instances admins to bump their sub count ~70x from something like 100 communities to something more like 7000 communities.
Nobody is encouraging anyone to do anything.
Users of this script actually literally don’t understand how federation works. They think they’re proxying through to the upstream instance while they browse rather than getting firehosed with the entire lemmyverse by they’re asleep.
That single user asked a question and got berated by a jerk.
It doesn’t take a rocket surgeon to figure out that global federation worker queues are not in great shape, or that a default that encourages single-user instance owners who have no idea what they’re doing to bump their sub count 70x isn’t helping the situation. If you think this is in my head I can’t help you. But I can help others understand that running this script with default settings is an awful and unnecessary idea.
You can help others understand what it is. That’s a great thing to do. It would be nice if you could do that without being a dick.
Federated replication load scales with the number of instances multiplied by the number of communities they subscribe to.
That’s a hasty generalization that you just made that up.
Sigh. No. No, that’s actually how the computational complexity scales and it’s not a difficult analysis to perform. Good luck to you though.
I think it depends on your instance. This version (same script, just updated) allows for more options IF your instance IS mass Overloaded, or you are scared it will be.
During the weekend all my communities jumped to 20-30 subscribers, but no participation. I went to see if almost all of the new subscribers were some variation of this bot.
I mean it is not doing anything wrong, it just feels like a huge letdown to see that none of the growth was organic. Are people really creating instances just for the sake of lurking around? What is the point?
