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

  • poVoq@slrpnk.net
    link
    fedilink
    arrow-up
    7
    ·
    9 months ago

    This text has some good thoughts, but it fails to conceal the authors apparent dislike of the ActivityPub model that recognizes instance infrastructure as part of the community over the BlueSky model that has a gaping blind-spot there.

    As a result the article barely looks into instance level efforts for democratic governance and rather treats the infrastructure as some nebulous existing quality on which users can interact with each other and cooperate.

    The cynic in me thinks this blind-spot is intentional in the communication around Bluesky and its proponents, as it allows the owners of the necessary (cloud) infrastructure to retain a hidden power over its users.

    • Oliver Lowe@hachyderm.io
      link
      fedilink
      arrow-up
      3
      ·
      9 months ago

      @poVoq Agreed. It got me thinking. But feels almost entirely ideological, conflating social media (e.g. Twitter, Reddit) with “the digital world”.

      Saying git is a “failed attempt at decentralisation” just because GitHub is popular misses that GitHub is less critical infrastructure than it would be if we only had CVS or Subversion.

      I’m encouraged by incremental, practical decentralisation efforts outside of social media. It’s slow, kinda boring but it’s real and happening today.

      @fediverse

    • maegul@hachyderm.ioOP
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      @poVoq

      Perhaps a totally fair critique.

      But for me the instance node in the Fedi binds many things together however much their governance aims to be democratic: username, platform, defed policies, moderation, user data (ie posts).

      • Robin Berjon@mastodon.social
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        @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
          link
          fedilink
          arrow-up
          3
          ·
          9 months ago

          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 Berjon@mastodon.social
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

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

            • poVoq@slrpnk.net
              link
              fedilink
              arrow-up
              1
              ·
              9 months ago

              Making servers a commodity is a convenient illusion that cloud vendors invented for marketing purposes.

              To stay with the real-world metaphor: it is a bit like suburbs. They are sold on the illusion of individual freedom in your own home but with the required car ownership as the capture point and an endless list of negative externalities and expensive hidden infrastructure requirements making them entirely unsustainable.

              • Robin Berjon@mastodon.social
                link
                fedilink
                arrow-up
                0
                ·
                9 months ago

                @poVoq Cloud providers aren’t commodified, they’re not interoperable. You’re comparing a protocol with specific design to enable commodification with proprietary platforms. If you don’t understand the properties of ATProto that target that, your critiques are going to go well wide.

                • poVoq@slrpnk.net
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  9 months ago

                  True, but they are marketed as such, which is my point. Commodification is nearly always an illusion to vendor-lock or capture you in other ways you don’t suspect, which is exactly what ATProto seems to be designed for as well.

            • Robin Berjon@mastodon.social
              link
              fedilink
              arrow-up
              0
              ·
              9 months ago

              @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
                link
                fedilink
                arrow-up
                1
                ·
                9 months ago

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

              • Robin Berjon@mastodon.social
                link
                fedilink
                arrow-up
                0
                ·
                9 months ago

                @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
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  edit-2
                  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.

  • Adrian Cochrane@floss.social
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    8 months ago

    @maegul @fediverse Thanks @robin for the term “Google Search Fallacy”! I’ve been seeing variations upon it everywhere …

    Love this article!

    (I’ve toyed with decentralized search before & quickly came to the conclusion that the way we commonly think about it is thoroughly misguided)

  • Juan Luis@social.juanlu.space
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago

    @maegul @fediverse @robin This is a great summary:

    > failing to build the cooperation layer leads right back to capture no matter how good the tool. That’s why git is simultaneously an extremely successful self-certifying system and a failed attempt at decentralisation.

    💯