Open brainstorming: Money, small communities and inter-community trading and communication

This is a raw braindump. I hope this is allowed. I wish there was a wiki (perhaps my own site, but maybe one where it uses the fediverse to form a bigger “wiki-verse”) where I can braindump some stuff in a “sandbox” folder without bothering too many people while allowing others to read it.

I think, for this forum, I’ll do braindumps like this: Post the full thought process out in the open. However, once finalised, I’ll close this thread, and link to a new thread, where the first post is the finalised thoughts.

  • Money is an asocial way of trading effort.
  • But we can also trade effort in a social way, but that does not scale well.
  • Maybe we can have small, people-scale communities, where effort is done without expectation of money (eg family, relationships, friend groups)
  • While these communities trade value with other communities, money is expected.
  • Tree-like communities (where a leader of a community is part of a bigger leader-community) might not work well due to power imbalance.
  • Therefore a community does not need money where self-sufficient; and needs money in places that aren’t.
  • This means that people in the community need to give effort to society (jobs, “benefit whole world” things), to consume “benefit whole world” things too.
  • Why are there “benefit whole world” things? Because some things can’t be done by a small community. For example, chip manufacturing. Centralisation has efficiencies we cannot ignore. But perhaps it is okay to centralise as long as there is negligible network effect.
    • Is there anything that really has negligible network effect? Even open source software that you can fork with a single click, has network effects; knowledge, popularity, funding, the ability to dictate open protocols (like what Mastodon is doing to AP, and what Chromium is doing to HTML5)…

Related quote:

1 Like

The universe is big

Let’s say we have small communities maintaining their own software. How do these software communicate? An open protocol like AP? It might be very hard for consensus to be reached – indeed there is already a divide between the Mastodon developers and the developers of other Fediverse projects such as Misskey and Pleroma.

Do we really need consensus? Much like how the Fediverse does not have consensus on social norms (e.g. CW rules), and likely will never have consensus, but instead forms a sort of organic graph, where some servers are “more compatible” than each other. Should that be the case for open standards too? Where different implementations implement different de-facto standards and have differing levels of compatibility rather than waiting for a consensus?

That I think is already happening with AP. But it also happened with XMPP, did it not? And the fragmentation was a big UX issue. So maybe it’s not such a good idea. What about Matrix? They have a much more centralised way of creating the open protocol, which allows for higher velocity and de-fragmentation, but re-creates the issues of very big projects.

In essence: The universe is big. The bigness has to be somewhere; we cannot only talk about smallness(?). Where, and how do we manage it?

Related quote with possible solutions, once again from the same post:

The Do-Ocracy

https://communitywiki.org/wiki/DoOcracy

The Do-Ocracy feels very much like an informal computer-science-degree (which I’m pursuing) project. Whoever does the thing is in charge of it. Want to clean up the code base? You can just do it, etc.

For that a few things need to happen:

  1. Anyone should be able to just make changes to the software. This includes non-programmers. Abstraction is needed; perhaps visual programming. Note, visual programming is not just “coding but with blocks”! Excel is a good example of visual programming. Unity Shadergraph too.

  2. The contributors must be able to just contribute instead of going through a whole consensus process, and for that to work, the team must be small. And for that to work, the software must be build-able by a small team. Requires abstraction, then, modular building blocks (see npm/cargo/github/OOP?) likely from other communities.

For both 1 and 2, the small community building the software relies on other communities; inter-community trading or communication is needed.

Personal opinion: do-ocracy is good, it gets things done. But it must stay small… then where shall the big-ness go?

Wikipedia and Fediverse instances: Collaboration and Division

I am talking to myself… hello me! Hello, me. I like this way of brainstorming.

  • I am happy about how Fediverse instances are divided. My thought process: there is no way a single community (e.g. Twitter) is able to make everybody happy. Therefore, the ability to break up into instances with all sorts of rules (I am including single-user instances here), and the ability for different instances of similar rules to find each other organically is important. Essentially, division is important for everyone to keep their local culture.

    • Okay, so put everyone in a single-user instance. Full decentralisation, P2P. Does that work?

      • Actually, yes, it does, technically. In a hypothetical fediverse with full P2P (related: secure scuttlebug, Matrix P2P), everyone can indeed make their own rules, and the “organic discovery” rules still apply. It will still be a web of single-user instances discovering each other via boosts and follow-lists. But! There are a few issues with that. Firstly, technical skills required; one may solve it via automation (but who creates the automation?). Secondly, moderation skills required; blocking bad spam and abuse. Normal users don’t want to handle that, thus they delegate it to someone else. Who? Lastly, discovery via things like the federated timeline.

        • “Who?” Ah… there it is. There’s the do-ocracy. And do-ocracy implies small communities. Which is why… while centralisation provides efficiencies such as de-duplicating effort in ban lists and code of conduct (assume a big instance [e.g. 5k people] where most people share the same view point), it is better to split that into many similar communities of maybe 50 people max so do-ocracy may work.

          • “assume an instance where most people share the same view point” I don’t think this is a safe assumption to make. You cannot wrangle consensus from that many people.

          • Is Wikipedia not a do-ocracy? You cannot say that a do-ocracy implies small communities. I think you’d better read the wiki page again: CommunityWiki: Do Ocracy

            • Has anyone tried replicating the do-ocracy of Wikipedia in a code project? You know how Wikipedia has the whole “bold editing” thing, where “if in doubt, edit, someone can always revert it”. Why wouldn’t that work for code?

              • Uh… why do you want a “canonical” codebase anyway? Different people have different needs.

                • But how is Wikipedia different…?
              • In that page, they do indeed mention Open Source Software as an example of do-ocracy. Though does that actually work out in practice? Related: Coding is Social | Social Coding Movement

            • Related: Wikipedia community - Wikipedia. Check out the Criticism section. “Wikipedia seeks not truth but consensus, and like an interminable political meeting, the end result will be dominated by the loudest and most persistent voices.” - Oliver Kamm and “It was easier when I joined in 2004 … Everything was a little less complicated … It’s harder and harder for new people to adjust.” - Kat Walsh

              • So perhaps do-ocracy does imply small communities after all. Should I eschew wikis in favour of the “raw internet” (HTML pages linking to each other? Wikis only open to a select group of people?)
  • The ability for anyone to just make their own changes, for example, to the rules and the banlist is important. Obviously this won’t work with large instances; everyone will just try and ban one another. Thus, the ability to just make their own instances is important, and to protect this ability, there must be so many servers that anyone that tries to make an allowlist or somehow maliciously restrict federation will not be able to access the majority of the Fediverse (which is valid, but just to avoid a gmail-like scenario).

    • But… we have wikis. And wikis are collaborative; anyone can just make a change to it, as long as it’s within the rules… but similar to instances, you cannot just change the rules unless you fork the wiki entirely.

      • Well… we have wikias, don’t we?
  • So… when do we collaborate? When do we divide?

    • It seems that right now the answer is to divide into small communities. And collaborate within those small communities via a do-ocracy model (which probably requires small communities). Inter-community (hah, the OP topic!) communication is very much an important topic to discuss.

      • Can’t we just take inspiration from the Fediverse? Communication between communities (note: a single person can be in multiple communities at once) is ad-hoc and organic. Remember that within a Fediverse instance, the local timeline is not organic; it is simply every post. I’ll detail three examples. Software. [TODO]. Knowledge base. [TODO]. Food. [TODO].
  • I GOT IT! I think. Wikipedia is very simple to edit, and if you’re editing something simple, it’s hard to get wrong (and others can help). Imagine a piece of software as simple to edit as Wikipedia, without technical knowledge needed. The same collaboration will emerge, wouldn’t it? It is because today’s software is so hard to modify, that people find it easier to just bother the maintainers.

    • Right but I don’t think everyone can reach a consensus on the same thing… do we really need a consensus? Why do we need a consensus? Perhaps it is better if we divide. Asocial coding. And only socialising (forming a community) to de-duplicate efforts such as moderation… but what about technical skills? Sysadmin? Programming? It seems unfair to create a world where you must “depend on a nerd” to participate in the online world.
1 Like

I have changed my mind.

Here’s my new thought process:

  • United in diversity
    • Care more about local cultures, be able to live in division.
    • “You cannot wrangle consensus from 500 people.”
      • Probably the limit is 50 people at most.
  • Together we are stronger
    • Consensus (< 50 people) → Reuse → From Scratch
      • Ad-hoc consensus:
        • Anyone can just do it. But everyone else is affected.
      • Ad-hoc reuse:
        • Anyone can just do it. But no one else is affected except for maybe a few closest to you.
    • Reuse when you can ^
    • But reuse does not mean consensus. You don’t need to merge it back.
  • Least power principle
    • Yeah just allow for an API or something so you can actually transmit posts instead of entire webpages or god forbid applications.
  • Sovereignty: Ability to just make your own node
    • About 1 in 50 people (2% of the population) should be able to do this on the side. Doing it as a full-time job is not an option, they still need to be able to live their own life.
    • You can reuse. E.g. as a moderator this will be reusing previous blocklists, reusing server code or reusing hardware.
  • Accessibility: Ability to not make your own node ← most people will be here
    • You will join 1 of the 50 people. Note that I am not talking about a DoOcracy here!!! A DoOcracy already exists in mass — it’s capitalism.

Because I change my mind often I think it’s best for me to stick to a single brainstorming thread unless it’s clear it’s a new topic (e.g. the Centralisation is Inevitable article).

1 Like