DREAM

[system]

The Distributed Replicated Edge Agency Machine (DREAM) aims to enable peer-to-peer group collaboration.

Group Collaboration Among Peers

The DREAM Replicated Edge Agency Machine, is not really a machine. It’s more a methodology, a political approach to free technologies that enable people on the edge to create agency together.

Taking the opportune convergence of @spacekookie’s presence and @pukkamustard’s alpha release of Distributed Mutable Containers (DMC), we wanted to question group collaboration on the edge with Peer-to-Peer experts from Briar, Irde.st, and RetroShare, and to see how such group collaboration could, on Kookie’s proposal, become a software syndicate to engage like-minded researchers to share practical grounds: specifications, test cases, documentation, and more…

This is an invitation to bring group collaboration back in P2P.

• DREAM (@pukkamustard) → DMC (Distributed Mutable Containers)
• Irde.st (@spacekookie)
• Briar (Torsten Grote)
• Retroshare (Cyril Soler)

Distributed Mutable Containers

An alpha release of the reference implementation of DMC is scheduled for June 30th. You can read some background reference on data model and data storage. The Dromedar repositories contain OCaml code.

Irde.st

A framework for building decentralised networks via a routing algorithm, web of trust, and message store & forward protocol that allows for delay tolerant communication off the grid. Some (work in progress!) documentation can be found here or on the https://irde.st website.

@spacekookie is willing to open cooperation across peer-to-peer projects through the creation of a Syndicate that would enable shared specifications and test cases, collaborative documentation, etc.

Briar

Briar is a messaging app designed for activists, journalists, and anyone else who needs a safe, easy and robust way to communicate. Unlike traditional messaging tools such as email, Twitter or Telegram, Briar doesn’t rely on a central server - messages are synchronized directly between the users’ devices. If the Internet’s down, Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis. If the Internet’s up, Briar can sync via the Tor network, protecting users and their relationships from surveillance.

RetroShare

Retroshare is all about sharing and communicating with trusted Friends. This is the core design of Retroshare: a decentralised Friend-2-Friend network, which allows you to share stuff … not with the whole world… but with people you know and trust.

Topics of interest

• How do we work together, exist together in a shared space, what are our commonalities, our point of exchange ; how can we, from our experience in our different projects, express our specificity?

• Existing software based on P2P networks are mainly focusing on chat and social networking, there are other needs of interest to the community that can contribute to the development of the network.^[1]

• Organizing information and data is something many communities are mature enough to start doing on their own network and infrastructure.

• As people exist, work, and organize in groups, organizing access around group collaboration is an urgent necessity.

---

1. Please Stop Writing Secure Messaging Tools ↩︎

[natacha]

We are working here: Software Syndicate - HedgeDoc

[system]

Reproducing https://pad.public.cat/software-syndicate?both to gather feedback.

full text, work in process

Software Syndicate

Purpose (of this pad)

• Outline what a software syndicate is defined in its goals, methodologies, and functions.
• Describe how different software syndicates can operate towards a shared goal, …
• Create a guide on how to start your own software syndicate

What is a syndicate?

according to Webster dictionary:

1. a group organized to carry out a particular transaction or enterprise
2. an association of organized criminals
3. a workers managed entreprise

A syndicate is a structure where professionals/ businesses meet to facilitate their work by sharing ressources.
It is different from a union, as the later is a structure aimed at defending worker’s rights.
The choice of the syndicate structure responds to the reality that most free-software projects carry along an eutreprenarial or cooperative model.

In the third definition the term syndicate is associated to anarcho syndicalism as a method for workers in capitalist society to gain control of an economy, thus control and influence in broader society. Anarcho-syndicalism is our point of reference where different needs of society are organised locally at communal level then federated.

A communalist way of thinking about technology engages us in thinking needs at local level and looking to federate what gains can be mutualised.

Purpose (of the software syndicate)

What form can it take?

The software syndicate is a local alliance of developers and community interested in thinking the tools they use; it can take different forms both proposing both social and digital tools. There are already existing structures that we can build from, hackerspace network is one example, but other civil society structures can be a supportive base also. The software syndicate looks at transforming the decision process about software development among developers including users in the decision process.

Motivations

Organisations, groups, and projects under capitalism have the tendency to centralise.
This is both because of monetary incentives (it might be cheaper to just have one of something than many), as well as authority incentives; it is easier to control an organisation that is structured hierarchically.

This way of thinking has infected nearly every aspect of our society, including free software projects.
Generally projects are considered to have an “upstream”, a canonical source from which the software is created, distributed, and maintained.
This has a lot of downsides for the end-users of the software. For example, a canonical upstream puts every user of the application at the whim of its developers. If the software is changed in some way that many people dislike, the burden to fork is very high. After all each individual user (even if they have a tech background) might not be able to maintain the entire codebase by themselves, or be able (and have the connections) to build a new community around the fork.

Most forks fail [citation-needed]. There are of course exceptions (a very successful one being jellyfin forking from emby ca 2019^[1]), but the rule is that forking is a quite violent act that requires a lot of strength and energy to maintain.

The idea of software syndicates (or to turn the phrasing around syndicalist software) is to remove the notion of “upstream”. Software exists in the world, and is created and maintained by different software syndicates.
Maybe one of these syndicates originally created the software, but did so in a way that was easy for another syndicate to come along, adapt, and re-distribute to its users.
In effect this creates pre-emptive “soft forks” – forks that are still compatible with each other, but that might vary slightly in their functionality.

For developers this means that software is maintained by many different smaller projects. The original authors (mainline) of the software still exist, and changes can be given to them. Maybe many syndicates would regularly pull updates from mainline, in order to get the latest features that are being worked on. But patches could also be applied to a more “local” syndicate to the developer, if the change is not deemed to be useful outside of the sydicate’s community.

For users this means that software is available by many different smaller projects. Users of Linux distributions may already be familiar with this. Packages are not usually created by the software authors, but by distribution maintainers. Users already get their software from a kind of syndicate: their distribution. The idea of a software syndicate formalises this relationship, and invites others to create other such projects, independent of (or spanning over multiple) distributions.

If the usability of one version of the software is not to the liking of the user, it is much easier to find one that is. An example of this already in practise are mastodon forks, which are all (?) still compatible with the mastodon API and activitypub spec, but that add extra features that the mastodon mainline doesn’t want to support.

What is locality

• The social proximity of people to each other, and the communities they build
• Your friend circles, their friends – this is your “local” community
• Your fediverse server is a form or “local” community
• Of course physical locality plays a part – you may meet people in your city and then meet them again on the internet
• We are using a reproduction medium/tool (computers) that has global capacity, one software doesn’t fit all but still it can have quite a large scope unrelated to its place of production.
• Computer networks allow us to take advantage of a “larger” concept of locality embeding different relations.

Oportunities

• The ability to localise the development and maintenance of software – to remove the “knowledge silo” from development in Germany, F̷̪̤̋ṟ̵͙̾͗a̷̛̩̎n̴͙͙̿́c̸̙͙̈e̵̪͒, the UK, and Netherlands, this implies looking for others elsewhere.
• Building social structures that transcend projects, giving users and developers a “closer” contact to the software they use
• Destroying the notion of personality-driven development
• More control over the software that people use, not being dependent on a single group of developers to “care about your use case”
• Rethink free software engineering around actual collective needs rather than individual developer’s itches.

Challenges

1. How to deal with Not Invented Here (NIH) syndrome? I.e., how to ensure that common functionality gets to the main branch and does not end up into too many forks duplicating functionality?
2. How to engage with distribution packages?
3. How to avoid balkanization, e.g., such as with Freifunk?
4. How to ensure processes remain common although not centralized?
5. What tools are needed? E.g., ForgeFed…
6. Can we extend these principles to funding (i.e., to ensure development remains funded globally)?
7. Can we use Elinor Ostrom’s principles for the governance of the Commons?
8. What can be localised and what can be mutualised?

Methodology

• “Automated” ways of tracking features, changes, deprecations, … between versions of a software maintained by different syndicates
• Core-minimalism: keep the core part of your project as small as possible to make it possible for other syndicates to extend the software in many different ways
• Create a forum to discuss notions, changes, and

Interlude

Excerpts from Heather Marsh’s Glossary:

Community: A group affiliated around allocation of common resources. Communities may be societies, where allocation is through social relationships, or trade economies, where allocation is through trade.

Consciousness: A subset of reality filtered through empathic networks and sometimes subjected to the laws of endoreality through an endofilter.

Concentric circle: Peer promoted voices or ideas in a transparent, permeable structure where those at the centre receive the most amplification and ideas are audited and taught to the outer circles by knowledge bridges.

Corporate feminism: Feminism which emanated from the United States in the 1960s and was heavily guided by both the CIA and corporate interests. It created an endogroup out of an exosocial struggle for liberation.

Example: The DREAM Software Syndicate

Objectives

• Create, maintain, and distribute software related to decentralised communities and networking.
• Act as a test-bed and example syndicate for others to copy, modify, and adapt – either for the same set of projects, a sub-set, or a different set of projects

Means

Governance

See below for final text…

---

1. See Introduction | Jellyfin ↩︎

[how]

Heather Marsh’s A Societal Singularity article in Autonomy, Diversity, Society seems very relevant to me to both this discussion and the larger thx-topic of collective radical care.

Here’s a collage for the latter: a-societal-singularity.pdf (630.0 KB)

And a quote for the former:

In open source software, the code for each project is available for all to see. Even if the end user cannot understand the code, they can go to discussion groups or listen to programmers who have read and audited the code, and they can read the bug reports. Any urgent bugs will be broadcast to the general population and amplified by media as we have seen many times. The people with the greater knowledge of the system will provide knowledge bridges for people at a more novice level and increasingly, that is how people are learning to code. Good ideas from forum discussions can be read and possibly implemented by the developers as well. Transparency goes both ways.

Open source software projects with forums open to all are a perfect working example of fully transparent and audited systems of elite knowledge. While the decisions are made by the developers, input, review and acceptance or rejection of the software is the right of the user group. If the developers refuse to listen to the user group and another development team is willing to work on the project, the original code can be forked and modified to meet the user requirements. This means existing ideas can only be opposed by another fully developed, open and transparent epistemic community which also must be audited by knowledge bridges. They can’t be attacked just by demagogues and rhetoric. They can only be opposed by another working solution, so the user group has a choice between two or more working solutions instead of simply rejection or acceptance. This is only possible if the information is free for anyone to use or modify. Ownership of ideas is in complete opposition to both stigmergy and concentric circles, so it is in complete opposition to rapid progress, finding the best solutions and self governance.

The open software movement has driven most technology based fields into a flat and accessible relationship with the public and social media has done the same for journalism. As people become more accustomed to real and participatory news and culture, they will demand the same of science and academia. As science and academia develop their own direct relationships with their user communities, they will be in a position to shun those in industry or politics who refuse to support them or attempt to manipulate them. Politicians and industrialists are not necessary in a fourth age societal structure. Knowledge industries are and it is essential that local affinity groups learn how to communicate and support them directly.

We can never have idea and action based governance without the reliable information provided by fully open, transparent, epistemic communities and knowledge bridges. The ability to create a body of knowledge for review must not be restricted to one class. Access to and ownership of our knowledge must be a human right.

[natacha]

@how

As science and academia develop their own direct relationships with their user communities, they will be in a position to shun those in industry or politics who refuse to support them or attempt to manipulate them.

As of now Science and academia tend to reproduce corporate biases in order to communicate with the larger public. If we wanted to get away from this scheme it feels we should organise networks of independent research centers and knowledge producing organisations. In different places. Such developments are in progress maybe listing existing ones can be useful.

@how

Politicians and industrialists are not necessary in a fourth age societal structure. Knowledge industries are and it is essential that local affinity groups learn how to communicate and support them directly.

The complexity of the system appeal to demanding investigative journalism structures that are not easy to bring together and produce articles and texts that are not easy to access if you do not have time, and previous knowledge.

[how]

According to Heather Marsh, the fourth age reclaims « a new framework for society building, more diverse, flexible and mutually supportive »: « A fourth model for nations must meet both our social needs and our need to develop to our full potential, ensure local autonomy but protect global commons, and put social responsibility back in communities but provide a global safety net for those shunned or harmed locally. »

I find it relevant to come back to Elinor Ostrom’s principles for the governance of the Commons (PDF) using intertwingled^[1] polycentric systems, especially Rule 8 (see also pages 281 and following):

8. Nested enterprises. Appropriation, provision, monitoring, enforcement, conflict resolution, and governance activities are organized in multiple layers of nested enterprises (based on E. Ostrom 1990, 90)

Quoting from page 271:

One can translate the design principles into a series of questions that could be asked when thinking about improving the sustainability of a common-pool resource system. For local appropriators, a rough translation of the first six design principles into a set of initial questions would be:

1. How can we better define the boundaries of this resource, and of the individuals who are using it, so as to make clear who is authorized to harvest and where harvesting is authorized?
2. How can we clarify the relationship between the benefits received and the contributions to the costs of sustaining this system?
3. How can we enhance the participation of those involved in making key decisions about this system?
4. Who is monitoring this system and do they face appropriate incentives given the challenge of monitoring?
5. What are the sanctions we are authorizing and can they be adjusted so that someone who makes an error or a small rule infraction is sufficiently warned so as to ensure longer-term compliance without our trying to impose unrealistic sanctions?
6. What local and regional mechanisms exist to resolve conflicts arising over the use of this resource?

The seventh and eighth principles are targeted at a higher level of governance. They could be translated as:

7. Are there functional and creative efforts by local appropriators to craft effective stewardship mechanisms for local resources that should be recognized?
8. How do we create a multiple-layer, polycentric system that can be dynamic, adaptive, and effective over time?

These are not, of course, the only questions appropriators and officials should ask in an effective design process, but they can be thought of as a good beginning.

---

1. nod to Ted Nelson’s Computer Lib/Dream Machines, 1974:

   « EVERYTHING IS DEEPLY INTERTWINGLED. In an important sense there are no “subjects” at all; there is only all knowledge, since the cross-connections among the myriad topics of this world simply cannot be divided up neatly. »

   ↩︎

[natacha]

What are we talking about:

Social and technical infrastructures

• Hackerspaces
• Git repositories
• Chats Irc Forums etc…
• Non profits and Commons networks
• Life necessities thinking that maybe source of funding for a free conception of software can rarefy => Direct association with social centers might become necessary for survival.

What is this software we are talking about, what are the decision processes they refer to.

• Main projects: (Frameworks Languages OS …)
  – Central decision processes
  – Central repository that is the reference point

• Protocols
  – Engaging larger community decision processes embedded in existing capitalist economy
  – One source for the protocol, however implementations can superseed the protocol definition and transform its application

• Librairies
  – Different scales engaging from the individual to the community and can be reused independently.

• Softwares
  – Developped according to local and/or global needs
  – Can be redundant
  – Different decisional processes often relying on one main developer, bus factor.

Examples

• Wikipedia
  – Creates a hierarchy that reproduces existing domination systems.

• Existing hierarchical systems:
  – Debian Constitution system D example
  – oppositions: Devuan minority difficulties maintenance depending on external sources
  – Differences: Ach linux

• Groups of common Interest
  – Different existing P2P projects
  – Different commons pojects

A software syndicate, for whom? - HedgeDoc

[how]

Nous devons composer avec le monde tel qu’il devient, pas avec le monde tel que nous le souhaiterions. En veillant toutefois à rester au plus proche de ce que nous pensons que ce monde souhaiterait, en expérimentant et en bricolant, et en priant que le monde ne s’irrite pas de nos erreurs.

— Vinciane Despret, Autobiographie d’un poulpe, p.120 isbn:9782330147631

Castellano

Tenemos que lidiar con el mundo tal y como es, no con el mundo tal y como nos gustaría que fuera. Pero tenemos que mantenernos lo más cerca posible de lo que creemos que el mundo querría, experimentando y retocando, y rezando para que el mundo no se enfade por nuestros errores.

English

We have to deal with the world as it becomes, not with the world as we would like it to be. But we have to stay as close as possible to what we think the world would want, experimenting and tinkering, and praying that the world doesn’t get angry at our mistakes.

Euskara

Munduarekin bihurtu den bezala osatu behar dugu, ez munduarekin nahi genukeen bezala. Hala ere, gure ustez mundu honek nahi duenetik hurbilago egon dadin begiratuz, esperimentatuz eta distira eginez, eta mundua gure akatsetatik irrika ez dadin ikusiz.