|
I run my own instance of Mastodon just for myself - and am thinking of doing the same for Lemmy. I, of course, can do that because I have the skills - most don't, so they must rely on sites like these for their accounts. 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? |