~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~
So sick of not trying Scared that we might fail We'll accomplish nothing Not even failure Refused, The Shape of Punk to Come (1998)
On and off for a few years1 now I've been prototyping a kind of decentralized collaborative wiki document system to replace Notion and the disorganized spray of Google Docs / etherpads / cryptpad that many groups2 I've been a part of use for lack of an alternative.
The working title for the project is SAWA which stands for Simple Adminless Wiki Architecture3. It comes from سوا in Lebanese4 Arabic which means "together".
SAWA is a prefigurative experiment in decentralized5 computing with a governance model inspired by Anarchist theory and practice. It tries to balance the agency of the individual against the needs of the group without allowing power to coalesce anywhere. It tries to encode the basic structure of democratic participation while allowing groups a lot of control over exactly how they practice it.
The result is -- it's kind of odd! It does not directly resemble any incumbents, which I take as a good sign that it might actually different in a meaningful way. I am trying to stick to principles, let the thing tell me what it wants to be, and engage as much as possible in an act of discovery rather than an act of invention.
Power can be understood as the capacity of one group of people to make and enforce decisions on another group without their participation. Many digital systems, without consciously considering it a choice, choose to impose hierarchies of power among their users by creating a class of "administrators" who are granted the ability to make system-wide decisions that affect everyone. This approach clashes with the many existing and thriving worker cooperatives and artist collectives that operate on egalitarian democratic bases.
SAWA is made for these groups and is designed to better fit how they are organized in the real world. SAWA replaces administrators, a class of people, with administration, an activity. The decisions that govern a SAWA collective that would otherwise be made top-down by a class of privileged "administrator users" are instead derived bottom-up by merging the decisions made by individual participants.
SAWA is a system to distribute and collaborate on documents. Documents are structured data6 that store named properties, lists, text, numbers, and other values. They carry with them their full edit history and the ability to seamlessly merge changes made by different people7.
Every version of every document can be uniquely identified8 and fetched by SAWA. Versions cannot be changed once published, and modifications to a document always create new unique versions.
This constant creation of new versions is what allows people to collaborate without central coordination. Modifying things "in-place" requires extra work to make sure people do not overwrite each other, but if everyone is only ever creating new versions then there is no chance of bumping into each other, and no coordination is needed.
What a document's properties and values are, and how they are interpreted, displayed, or used is up to the users of the system -- SAWA imposes no limits. These documents are created and manipulated by SAWA's user interface, which was inspired by Notational Velocity in the initial prototype but will look more like Notion in future iterations.
To remain decentralized SAWA cannot rely on a notion of identity that lives on a server nor can it fall back to semi-centralized technologies like email. Instead every actor in SAWA generates a unique ID for themselves locally on their own devices. These IDs are the closest thing SAWA has to "usernames" and they look like this:
ef51ed2bcd89a229753e31625142d74d711819f879eb8a80b37d852acc312949
Admittedly unsightly! But they can be generated by anyone anytime anywhere and are globally unique without central coordination, which is critical to SAWA's goals. "Aesthetically pleasing" names at the architectural level generally require some kind of centralization or hegemony to function, which takes them off the table9.
In addition to their uniqueness SAWA actor IDs can also be used to cryptographically sign data10. SAWA uses these signatures to confirm that signed data came from a particular actor and was not modified since the time of signing, ensuring that the actor in question consents to the contents.
A document signed by an actor is that actor's voice in SAWA. Every actor gets a voice document representing their participation in the collective, and it's where they put their share of administrative decisions. The set of administrative decisions in a collective is derived by combining the administrative decisions made in actor voices. Deriving the governance of the group from the explicit consent of its individual members is the core of SAWA's approach to decentralized anarchic democracy.
Actors are free to make decisions about as much or as little as they want. They are free to update their voice at any time by producing a new version of their voice document and signing it, signaling to others that this new version is now the most up-to-date representation of their will. In this way SAWA combines a layer of unchangeable document versions with a layer of changeable signed references to deliver a system that is resilient and flexible11.
SAWA collectives are built by actors referencing each other's IDs in their own voice documents. These references are labeled, communicating to SAWA the kind relationship one actor has to another.
The simplest of these labels12 is "trust". By telling SAWA that you trust another actor, you are saying that you would like them to be part of your collective, that you want to factor in their administrative decisions with your own and others you trust. If they trust you back then they will factor in your decisions as well and you two will be fully collaborating.
SAWA can follow these trust references recursively to gather up the set of actor voices that represent the collective13. Trusting a member means you trust who they trust, and including them in your collective means including everyone they've included, too. The side-effect of this is that you do not need to know and trust every individual member of a collective to join, you just need to trust and be trusted by at least one person. This allows any member of a collective to "invite" new members and allows for a very fluid and flexible membership structure14.
This is the first and most important decentralized administrative decision to make together. Deciding membership collectively takes the place of administrator users sending out invitations, revocable memberships, and centralized Access Control Lists15.
Finding people to trust and getting people to trust you back happen outside of SAWA. A person's SAWA actor IDs might be on their website, they might give it to you in an in-person meeting, or share it in a chat, and so on, not unlike from discovering someone's email address or phone number. Actor IDs are cheap and not precious, so a person may have as many as they like, possibly participating in different collectives with different people.
Building a collective this way requires a starting point, which has the interesting side effect of making collectives only defined from the perspective of an actor. There is not -- and cannot be! -- a globally uniform view of a SAWA collective. It does not have a name or really any existence beyond the underlying network of relationships, and that network needs to be built starting with someone. Different starting points might result in different sets of voices, meaning different actors may see different collectives depending on who they trust (especially when more intricate relationships like "distrust" are implemented).
This is odd! This is different from just about any other system I am aware of. It's not something that was explicitly designed, but something that emerges from the insistence on bottom-up decentralized governance. In practice I expect most members of a collective to see the same data when there is mutual trust among all actors, but at scale the full implications are not totally clear.
Actors publish content by associating pages16 with document version in their voice document. A page is an identifier and can be anything -- the initial prototype generated just used random strings. Pages are unlike document version IDs and actor IDs in that they are arbitrary, stable across edits to the underlying document, and do not have to be globally unique. To make analogies, pages are like a file's name which generally stays the same while its content changes, or like the address of a house that stays the same while its occupants my change over time.
An actor associating a page with a document version using their voice is their way of saying "This is the content I think this page should have" or more specifically "I think this page should have the content of this version of this document." By combining all such associations made by all the actors in a collective SAWA derives the collective's full set of published pages.
To create or update a page, an actor:
Deleting a page involves updating it to mark a deleted property true which propagates out to the collective the way any update would. The user interface will not display deleted pages, and the underlying system can reclaim the storage after a period of time. This has the interesting side effect that deleted pages can be revisited and "undeleted" for a period of time.
SAWA is missing critical aspects that are left for future iterations. Building the collective currently assumes unbounded transitive trust, meaning SAWA assumes you will trust everyone who you trust trusts, which is not realistic. Future iterations will have the capacity to declare that you explicitly distrust other actors and reject their contributions and may limit the number of "hops" of trust to keep collective size bounded.
Publishing does not currently properly support disagreements. What happens two actors associate different document versions with the same page, disagreeing on that page's content? As of the initial prototype SAWA will just merge both versions into a new one, preserving both sets of changes.
This is a fine default and mirrors how Notion or Google Doc pages with write access work, but future versions of SAWA will allow the collective to negotiate "policies" around updating documents. For example, a collective might decide that updates to their Code of Conduct should require at least three members to agree before they are accepted. SAWA is being designed to detect disagreements at a given page and report them along with the last version of that page that held collective consensus. Disagreement is treated as a natural, normal state for the system to be in, reflecting human collaboration more accurately. This mechanism will take the place of "locking" pages to certain users employed by e.g. Wikipedia.
Interruptions were sometimes more frequent than statements. The process, compared to a well-managed executive conference, was a slab of raw beef compared to a wiring diagram. Raw beef, however, functions better than a wiring diagram would, in its place — inside a living animal. Ursula K. Le Guin, The Dispossessed (1974)
The initial prototype of SAWA demonstrates the fundamental soundness of the approach to decentralized decision making. The hope is that deriving the will of the collective from the autonomous decisions of its members is a better model for the living animal of human collaboration than the false order promised by rigid hierarchies.
My earliest notes go back to 2021, this is a thread from 2023 thinking out loud about some details of the governance model. ↩︎
Specifically the IWW, Livecode.NYC, and various other horizontal / leaderless / non-hierarchal activist groups. ↩︎
Or, equivalently, Simple Anarchist Wiki for Architecture if you are more radically inclined ↩︎
I was under the impression as (I often am) that سوا was proper Arabic, but it turns out it's just a thing we say in Lebanon to mean "together", derived from the Arabic سَوَاء which means "equal", and I think that's beautiful. ↩︎
Many of the ideas here will sound familiar to the ideas espoused in the cryptocurrency community. This is due to their coopting and bastardizing of terms like "decentralized", "democratic", and "consensus" despite pursuing nothing but the centralization of resources, the hoarding of power, and the maintenance of hierarchies. SAWA has nothing to do with cryptocurrencies or "the blockchain" which I consider fraudulent and politically illiterate. ↩︎
Document versions are identified by their SHA256 content hash as computed by Automerge's DecodedChange.hash property ↩︎
This observation is somewhat related to my earlier research on the linguistic hegemony in programming languages that makes non-English programming languages effectively impossible in practice. The central issue turns out to be names there as well. Read my 2018 essay or watch my 2019 talk for more on that trajectory. ↩︎
IDs in SAWA are the public key of an Ed25519 signing key pair. ↩︎
This combination of immutability and mutability can be found in the relationship of references to objects in git or BEP44 from BitTorrent. Immutable data is categorically easier to synchronize in a decentralized system, and maintaining a comparatively small layer of mutable signed references preserves the flexibility of the ability to change data at will that users expect. ↩︎
And in fact the only kind of label that was available for the initial prototype. ↩︎
SAWA implements what's called a "web of trust" which is a common structure in decentralized networks. Future iterations will build on the established theory and practice in these spaces. ↩︎
This description is as of the initial prototype and is known to be simplistic. See Reflections and Future Work for more. ↩︎
SAWA builds on the work of The New Design Congress ↩︎
The word "page" is used to be distinct from document and reduce ambiguity. The codebase calls these "paths" in some places, from the file system metaphor. The nomenclature is admittedly not nailed down yet. ↩︎
~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~ DRAFT ~