So I recently got an excuse rant about my opinions on federated tech. I think it’s pretty much the best we can hope for in terms of liberating tech, with very few niches where fully distributed tech is preferable.

Needing a server places users under the power of the server administrator. Why do we bother? "No gods, no masters, no admins!’ I hear you shout. Well, there’s a couple reasons…

Maybe using software is just an intrinsically centralized activity. One or a few people design and code it, and an unlimited number of people can digitally replicate and use it. Sure, it may be free software that everyone can inspect and modify… but how many people will really bother? (Nevermind that most people don’t even have the skills necessary.)

Okay, so we always kind of rely on a central-ish dev team when we use tech. Why rely on admins on top of that? I believe the vast vast majority of people doesn’t have the skills and time to operate a truly independent node of a fully distributed tech. Let’s take Jami as an example:

“With the default name server (ns.jami.net), the usernames are registered on an Ethereum blockchain.”

So a feature of Jami is (for most users) implemented as a centralized service. Yikes. You could build and run your own name server (with less embarrassing tech choices hopefully), but who will really bother?

But say you bothered, wouldn’t it be nice if your friends could use that name server too, and gain a little independence? That sounds a lot like decentralized/federated tech.

Keeping a decent service online is a pain in the butt. Installing SW updates, managing backups, paying for hardware and name services… nevermind just the general bothering to understand all that mess. And moderation, don’t forget moderation. I’m saying it’s not for everyone (and we should appreciate the fuck out of [local admin]).

I believe that servers and admins are our best bet for actual non-centralized tech. A tech-literate person tending a service for a small- to medium-size community is much more feasible than every person running their independent node (which will probably still depend on something centralized).

And maybe that’s just the way we bring good ol’ division of labour to the Internet. You have your shoemaker, your baker, your social media admin. A respectable and useful position in society. And they lived happily ever after.

  • rook@awful.systemsEnglish
    9·
    1 month ago

    I like the idea of small communities, but a major issue (possibly the biggest issue) as demonstrated by many mastodon servers over the years is longevity. What happens when your admin gets bored/burns out/dies/goes fash/is replaced with an asshole/is unable or unwilling to moderate effectively?

    I don’t particularly like the big mastodon hosts (eg. mastodon.social) but they’re probably still going to be here tomorrow, unlike eg. octodon.social who are winding down because adminning was too much (after 8 years, which was a pretty good run!) and they didn’t have any plans or processes in place to handle this eventuality.

    Between that sort of thing and stuff like matrix cryptography being full of holes and large matrix room management being a nightmare and email really being gmail, I’m slowly coming round to the idea that federation is too hard to do well and that if we could just manage a decentralised identity service and decent client software then it wouldn’t matter if servers didn’t talk to each other because we’d still have 90% of what people wanted from federation in the first place. Just a simple matter of engineering, I’m sure.

    • self@awful.systemsEnglish
      5·
      1 month ago

      I like the idea of small communities, but a major issue (possibly the biggest issue) as demonstrated by many mastodon servers over the years is longevity. What happens when your admin gets bored/burns out/dies/goes fash/is replaced with an asshole/is unable or unwilling to moderate effectively?

      this is something I’ve been thinking on quite a lot myself — how do we (being a small web service without effectively unlimited VC money to burn on cloud credits or an entrenched corporate infrastructure) have continuity in case anything happens? and as an established community, that continuity has to encompass our infrastructure, our data, and the understanding and expectations that make moderation work.

      • for infrastructure, we’re somewhat ok — our deployment code is open, and there’s just enough docs that a replacement admin can spin up an identical cluster with a bit of work
      • data’s a lot harder. I’d love to regularly publish a dump of our database with the sensitive details redacted to as many places as is practical (there’s a bunch of archive sites for this), but that would open us to a number of garden-variety and lemmy-specific attacks (and I won’t be describing those in public for obvious reasons, but established posters can inquire in DMs). most likely in the short term this’ll involve rsyncing full database and image storage dumps to trusted parties on a regular basis, though I’m open to any better ideas.
      • the problem of guaranteeing continuity of moderation is unsolved. the only idea I have in this direction is effectively a guild or co-op model that’d exist to teach and certify moderators and admins how to maintain communities like ours. I haven’t taken any steps in this direction, and there’s a lot to the idea that’s still effectively magic (how should certification work? what systems should be in place in case of bad actors? should this thing itself be a mostly technical solution or a mostly social one?), but it could potentially guarantee moderator continuity for federated systems other than ours too.