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!
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!
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).