Community practice, permissions, and the limit of governance-as-code

This note preserves the reasoning that led to the current community chapter and community UX lane #11. It also records which authorization/governance systems remain useful implementation references after the shift away from trying to make the application a precise model of the real community.

#The failure mode is mistaking the map for the territory

A festival, mutual-aid group or community workspace changes faster than its database. People act with incomplete information. Objects move before someone updates a record. Responsibility may be shared, disputed or unknown. A person can help without accepting permanent ownership. Several spaces can depend on the same material without belonging to one organizational tree.

A system that requires a complete authority graph before every action turns ordinary coordination into administration. It also creates false precision: the database looks authoritative even when the people involved never agreed to its categories.

The application should therefore maintain a useful, revisable account, not a digital constitution that reality must obey.

Examples of useful incomplete records include:

• “probably available after dinner”;
• “currently near the kitchen”;
• “ask Mo; they were looking after this yesterday”;
• “ownership unknown”;
• “I’m planning to do this unless it creates a problem”;
• “this affects our space too.”

The system should not infer title, endorsement, obligation or permanent authority from those observations.

#Kaupapa is orientation, not executable law

The user-defined meaning of kaupapa is: a set of guiding principles rooted in shared philosophy and collective purpose, intended to unite people by guiding behavior and clarifying expectations without reducing intention to rules.

That belongs near the center of the community product because it helps people make judgments in situations nobody preconfigured.

A group, space, project, item or knowledge artifact may:

• state its own kaupapa;
• reference a broader shared kaupapa;
• add local interpretation or examples;
• revise the written text;
• record questions or disagreements about its meaning.

None of those operations should automatically become an ACL change or an AI verdict. A revision of wording does not prove collective ratification. A participant can argue that an action conflicts with the kaupapa without the software declaring a violation as a cryptographic fact.

The application should expose the shared intention clearly, then leave interpretation to people.

#Do-ocracy is the ordinary path

Do-ocracy is not one more formal decision procedure. Its purpose is to let people take useful initiative without first obtaining organizational permission for routine, reversible work.

The ordinary interactions should resemble:

• “I’m doing this”;
• “help wanted”;
• “here is what changed”;
• “I’m not sure; does anyone know?”;
• “this affects us”;
• “I tried this; it worked/didn’t work.”

Kiwiburn and community practices such as Noisebridge are useful examples of action-first participation. They are social references, not protocol specifications.

The limiting principle is:

Taking initiative over your own contribution does not grant authority to commit other people's labor, consume scarce shared options, disclose someone else's private information or seize a jointly controlled digital resource.

That is a judgment aid rather than an attempt to enumerate every future rule.

#Advice is different from permission

Some actions benefit from asking people with relevant knowledge or who will be affected. That does not mean every such action becomes a vote.

Loomio's advice-process description is useful because it separates consultation from permission: seek input, consider the consequences, then act and communicate.

The application can help find likely affected people from known links while making the incompleteness visible. It should say “these people/spaces appear affected from current records,” not “these are the only stakeholders.”

A missing response from an offline participant is not automatic consent.

#Roles are not ranks

The earlier Matrix comparison sharpened an important rejection: one scalar “power level” is the wrong representation.

An equipment custodian can have authority over custody transfers without outranking a safety reviewer. A space coordinator can organize one program without inheriting the ability to moderate unrelated conversations. A person responsible for key recovery need not control budgets.

A human-readable role can therefore be a bundle such as:

Generator custodian
scope: generator G-17
may: record custody transfer, schedule routine maintenance
must: keep location/accountability current
may not: sell the generator, spend festival money, moderate unrelated spaces
review: after festival closeout

Underneath, the technical authorization layer can use finer capabilities. The UI should not require ordinary participants to understand the cryptographic representation.

Avoid broad role inheritance. A “festival steward” should not automatically gain every capability held by specialized local roles.

#p2panda-auth shows why offline authorization needs explicit conflict semantics

p2panda's access-control CRDT work is one of the strongest implementation-oriented references because it treats authority changes under partition as a convergent data problem.

If Alice removes Bob while Bob is offline and Bob concurrently makes changes, there is no trusted global timestamp that automatically decides which happened “first.” The system needs a declared causal/conflict policy.

p2panda's strong-removal approach can invalidate concurrent authorization actions and recursively invalidate dependent authority changes. Its later notes discuss the harder application consequence: already-materialized CRDT state may need semantic correction or rematerialization when an authority history changes.

This is useful engineering evidence. It does not mean every normal social removal should retroactively erase Bob's previously legitimate work.

Different removals need different meanings:

• ordinary departure;
• future-access removal;
• moderation suspension;
• compromised-device revocation;
• expiration of a bounded grant.

A compromised-device event may justify stronger concurrent invalidation than an ordinary social departure. The application must not pretend those are the same operation.

#Keyhive is the strongest convergent-capability research reference

Keyhive combines local-first group management, delegation and cryptographic access concepts. It is especially useful for representing:

• a person as a group of authorized devices;
• nested groups;
• attenuated capability delegation;
• offline membership changes;
• revocation and encrypted collaboration.

The Ink & Switch notebook provides the clearest conceptual reference for that structure.

Its implementation has been described as pre-alpha/unstable and unaudited. It should influence our object/identity model and remain a monitored implementation candidate rather than become an unreviewed production security root.

#Willow/Meadowcap removes the assumption of one global owner

Meadowcap is useful because its communal namespaces do not require one namespace master above all participants. Individual participant subspaces can be rooted in their own keys and capabilities.

That solves a different problem from joint governance. A communal namespace can say who has authority to write Alice's subspace. It does not by itself decide whether Alice, Bob and Carol can collectively exclude Dave from a jointly controlled object.

Use Meadowcap as a capability/sovereign-authorship reference. Do not pretend “no global owner” eliminates the need to define shared-object membership and key release.

#Radicle demonstrates threshold canonicalization without universal hierarchy

Radicle shows a practical pattern where peers keep signed states and selected references become canonical under explicit delegate/threshold rules.

The useful lesson is not that every action should be voted on. It is that rare high-risk transitions can have a different acceptance rule from ordinary local work.

Examples where a threshold may be appropriate include:

• rotating shared root/recovery authority;
• approving a sensitive release;
• endorsing a checkpoint intended for new members;
• changing a technical grant template with broad consequences.

Cell edits, task updates and ordinary resource observations should not wait for a quorum.

#Matrix is a conflict-semantics reference, not the role model

Matrix demonstrates that permission-changing events need special deterministic state resolution and cannot be treated like ordinary chat content. That is a useful protocol lesson.

Its scalar room power levels are a poor fit for our product because they create a comparable hierarchy across unrelated capabilities. The product should use scoped powers/roles where technical authorization is needed and avoid displaying them as a general status ladder.

#Labels and attestations belong beside permissions, not inside one hierarchy

AT Protocol's label model is useful as a conceptual reference for signed, attributable classifications supplied by independent sources.

The important separation is:

hard technical authorization
    "this key may edit this protected object"

community moderation outcome
    "this space suspended this participant"

signed attestation
    "this training group recognizes this person as qualified"

local preference
    "I muted this person"

Those statements have different consequences and need not converge globally.

A “trusted formula reviewer” attestation can affect how a client presents a change without automatically granting write permission. A community can explicitly choose to use a qualification as an input to a technical rule where that is necessary.

Do not turn labels into a network-wide reputation score.

#Polycentric structure is useful only while it stays lightweight

Polycentric-governance research is relevant because several partly autonomous spaces may share resources and obligations without fitting one hierarchy. The general festival, Kitchen, Art, Logistics, a safety group and a temporary project can each have legitimate decision domains.

The software should represent enough of these relationships to make dependencies legible, not require a universal jurisdiction graph.

The practical default is subsidiarity-like:

• local matters stay local;
• shared resources bring the relevant shared agreement into view;
• material cross-space effects trigger conversation with affected people;
• a narrow common safety/privacy floor can constrain relevant actions without granting the safety function authority over everything;
• a broader body can decline to adopt a local version for a shared/public purpose without rewriting the local record.

Most differences are scoped versions/adoptions, not constitutional hard forks.

#Resources need several relations, but only when useful

For shared physical resources, “owner” is often too coarse. Depending on the coordination problem, it can be useful to distinguish:

• title claim;
• beneficial/common holding;
• physical custody;
• current allocation;
• right to use;
• maintenance/stewardship;
• location;
• modification authority;
• funding provenance.

Unknown and disputed are valid states.

Do not require all these fields merely to record a chair. The model becomes richer when a real coordination conflict needs the distinction.

ValueFlows is useful for its intent → commitment → observed-event vocabulary and resource/process links. It should remain an optional schema/export vocabulary rather than the mandatory data model for every community.

#Community memory is not the security audit log

A separate coordination/community feed is a strong design direction, provided it is not a second ledger requiring duplicate paperwork.

It can surface:

• intentions and offers;
• noteworthy changes;
• concerns and questions;
• informal agreements;
• experiments;
• outcomes and lessons that may become knowledge.

A technical history answers who/which device produced an authenticated operation and supports recovery/integrity. Community memory answers why people acted and what they believe happened.

A statement such as “Kitchen agreed to lend the generator” initially proves only that the author reported that agreement unless Kitchen acknowledges it under the relevant profile. “No objections recorded” is not equivalent to consent from people who were offline.

Sensitive reports, personal blocks and mediation conversations need different visibility and retention and should not automatically enter the general feed.

#Formal governance is an available tool, not the product's center

Some communities need explicit procedures for money, scarce shared resources, sensitive key operations or persistent conflict. The software can support:

• advice;
• affected-party acknowledgement;
• consent;
• N-of-M approval;
• emergency action with expiry/review;
• appeal;
• scoped fork/exit.

These should appear when their value exceeds their administrative cost.

PolicyKit, Decidim, sociocratic patterns, Hylo and similar systems remain interaction/process references. Their complete institutional models and administrator assumptions should not be imported automatically.

The default question is not “what procedure authorizes this action?” It is:

“What are we trying to do, who might this affect, and what context would help people act responsibly?”

#Tests for the product and protocol

• A participant can add useful incomplete information without establishing ownership or an organization chart.
• A routine reversible action can happen before it is recorded.
• A scarce-resource conflict surfaces the relevant dependencies without asking every festival participant to vote.
• A person can hold several unrelated scoped responsibilities without one numeric rank.
• A local version can differ from the broader adopted version without being silently overwritten.
• A technical removal, moderation action and compromised-device revocation have distinct semantics.
• A late/offline participant is not counted as consenting merely because no objection was received.
• A coordination feed can preserve useful context without ingesting private blocks/reports or becoming a contribution scoreboard.
• A host, relay or database administrator gains no social authority from infrastructure operation.

#Provisional conclusion

Use formal authorization for the things software can actually protect: decryption, mutation of protected shared state, key/device membership, recovery, storage leases and other named digital powers.

For everyday community life, favor kaupapa, initiative, visible effects, advice, repair and lightweight shared memory. Do not solve the difficulty of representing a community by making the representation compulsory.

The cryptographic implementation can draw from p2panda-auth, Keyhive, Meadowcap, contextual signatures/capabilities and threshold mechanisms, but its social surface should remain simpler than its internal machinery.

#Open questions

• Which digital operations genuinely require explicit technical grants in the first community prototype?
• Which authority changes need fresh/quorum evidence while ordinary local edits continue offline?
• Can one authorization implementation express device identity, shared-object roles and storage-service delegation cleanly without becoming a universal social-role system?
• What information should a community feed retain by default, for how long, and under whose audience?
• How do local adopted versions, current shared checkpoints and full constitutional forks appear without requiring users to learn version-control terminology?