this post was submitted on 10 Feb 2024
18 points (90.9% liked)

Fediverse

17734 readers
64 users here now

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of "federation" and "universe".

Getting started on Fediverse;

founded 5 years ago
MODERATORS
 

Decent Decentralisation

https://berjon.com/decent-imaginaries/

Good counter to the focus on protocols.

> a protocol needs to achieve two things: it needs to prevent the accumulation of power imbalances between parties … and it needs to make it easy for users to cooperate in building the the rules they want for how the protocol's operation affects them … the success of decentralisation and … of a democratic digital world **rides not only on liberation but also on organising**.

@fediverse

By @robin

you are viewing a single comment's thread
view the rest of the comments
[–] robin@mastodon.social 0 points 9 months ago (9 children)

@maegul @poVoq I'm well aware of democratic work at the instance level, I just don't think that it's the right granularity and I don't see how it doesn't get captured. I'm interested in solutions that work even for people who use Gmail.

I don't understand the Bluesky comment, it doesn't sound related to anything I've said or even to reality?

[–] poVoq@slrpnk.net 3 points 9 months ago (8 children)

You can't realistically separate a instance from its users, just like you can't separate a city (and its governance) from its inhabitants. This atomicity is a result of the real world infrastructure imposing itself on virtual communities. You can argue about "right granularity" all you want in that regard, but in result it just obfuscates where the "capture" happens and likely not for the better (as in the case of BlueSky).

[–] robin@mastodon.social 0 points 9 months ago (7 children)

@poVoq Except that there is no *necessary* requirement to reproduce the constraints of IRL infrastructure specifically at that location. A good question is why pick a server instead of, say, people who use the same undersea cable? Typically that's because cables are a commodity whereas servers provide a single point of capture. But there are two options: make the server democratic or make the server a commodity (a real one, with no power and near-zero switching costs).

[–] robin@mastodon.social 0 points 9 months ago (2 children)

@poVoq I used to think that treating the server as a cityish thing made best sense. But cities are dense, they are used for everything including many things we often don't think about (see Jacobs, etc.). The mapping doesn't work very well, except perhaps for people who are very much in one community rather than overlapping ones.

The ATProto approach is credible exit and all the properties that make servers into commodities. It means that you have better flexibility in dealing with infra.

[–] poVoq@slrpnk.net 1 points 9 months ago

Federation solves that issue as it allows server inhabitants to "shop" for all their multiple needs by visiting other servers.

[–] robin@mastodon.social 0 points 9 months ago (1 children)

@poVoq For instance, I think it would make *a lot* of sense to manage PDS infra with coops the way it's done in plenty of places for energy provision. Things become a lot harder to manage when the people who are good at providing a commodity *also* have to be good at CoMo. For completely different topics. In completely different languages. Etc. Decoupling really helps here.

[–] poVoq@slrpnk.net 2 points 9 months ago* (last edited 9 months ago)

Usually that decoupling already takes place on the level of VPS providers who are really good at providing a commodity service, but personally I think it is in the best interest of any slightly larger community to run their own hardware servers.

Yes it takes some effort to do so, but only when running your own servers can democratic governance of an instance really work, otherwise you are always beholden to various limitations of the VPS provider and its pricing structure.

load more comments (4 replies)
load more comments (4 replies)
load more comments (4 replies)