Lemmy Instances are already blocking each other

Which is unfortunate because I think some neat projects flounder for lack of good onboarding.

I actually think a large problem with lemmy is that it's already too centralised. Each instance is trying to be a reddit. Which is all very nice, but it also means each instance is effectively in competition. I think each instance should be trying to be a subreddit.

The way it'd work in my head is that you'd have two types of instance. Front-end instances that are effectively curators/aggregators & identity providers. They effectively get to present you your front page and r/all. And this is entirely "if you don't like their curation choices, pick another". So here you'd get to pick if your instance is tech-focussed, foss-focussed, as-big-as-possible, family-friendly, politically charged, etc.

And honestly, the only thing stopping that instance from being an app that's not much more than an rss feed-reader, is that I've saddled them with being identity providers too. Which is not the world's biggest hurdle.

The second type of instance would be one subreddit. So moderators are instance administrators, you're trying to build one community in one place, etc. You're just trying to build one community in your one niche/topic, - and you're not trying to compete with other instances who are also trying to be everything to everyone.

I think this would present a lot of benefits. Front-end instances would naturally discover subreddits through the subscriptions their members make. For users, discovery would be through cross-posts, and curation amongst the subreddits their home instance already knows, etc. They can choose their own funding model, ad model, membership model, etc. And if they make choices that are wildly unpopular with their members, they can move to an instance with different ideas/ownership/spez without losing their communities in the process.

For subreddits, administrators can control their costs by, eg, choosing only to host text posts instead of images & media. Brand-owners can own their own communities/identities - ubuntu can run r/ubuntu on their own infrastructure with their own moderators, etc. And we should see a lot less pissing patches like the linked post, because subreddits aren't directly leaning on each other. Hell, there'd be nothing stopping youtube exposing their channels as pseudo-instances.

What I'd really love to see is a return to a world where one person can host their niche community on a $5 VPS - and still get all the benefits of being a subreddit. And at the same time, foss communities & company support forums can join right in without it being a huge risk to themselves, etc.

Asking for centralization is asking for another model where we put all our eggs in one basket, and then wonder why that basket has to kowtow to VC to pay for it all. What worries me is that right now, we're very focussed on breaking free from that, and no-one's exploring what we could actually gain from the alternatives.

And while this risks sounding incredibly hand-wavy - it's really just the forums we all grew up on, sharing a common API.

I've been working on an alternative that is, ultimately, a standalone and lightweight ActivityPub server that handles only one account at a time. The idea would be to serve an account as - in essence - it's own container. If a person just wants to run an instance for themselves off an old laptop in their livingroom (which is how I run my Mastodon instance), they can do that themselves if they have the skills - which I would strive to be minimal.

But, if they needed to rely on someone like beehaw, they could sintead join a "collective" - a central site on one domain that handles all incoming and outgoing messaging, DDOS protection, CDN caching, and even blocklist handling (e.g. reading a user's blocklist and blocking at the outermost layer) then passes what gets through to the individual service running on the backend. A collective could apply a site-wide blocklist, but the users would be able to opt back in because, at the end of the day, they are the ones who are actually federating with these other instances - the collective is, in essence, a firewall or "management layer", akin to an APIM for APIs.

Obviously, I'm not done building this, but I'm going to try and accelerate my work once I get some paid work off my desk. Why wouldn't something like this work? If an account wants to stay connected to a problematic server for whatever their reasons, how would that impact the rest of the collective if federation is handled at the user level?

Or, perhaps a better question, what's wrong with handling federation at the user level? Should I not be able to follow any account or block any account I want? Why must this fall on the backs of the admins?