#Aims and reasoning
A community needs ways to work together without making its application the institution that decides what the community is. A shared space can hold channels, tasks, needs, materials, documents, and knowledge while people and activities remain partly outside the record. Its map is useful because it is revisable, not because it is complete.
The direction is kaupapa-led and do-ocratic: understand the intention, take initiative with care, communicate effects, and remain answerable to affected people. Technical permissions protect private data and shared digital resources; they do not replace social judgment. Issue #11 owns interaction tests; the shared-core synthesis owns integration context.
#A community is a shared space, not a bigger group chat
Conversations remain something participants say to one another. An optional workspace can maintain channels, records, and jointly controlled objects without requiring a public institutional identity, complete membership taxonomy, or tenant owner before contribution. A community account is one possible digital container, not the owner of the real community or a third compulsory stream in TalkCo.
Kaupapa follows the user's definition: guiding principles rooted in shared philosophy and collective purpose, clarifying intention without reducing it to rules. A group, space, project, or item may carry or refer to it. It is neither an acceptance checkbox nor an automatically enforced policy language. An AI interpretation must not become an access-control verdict.
Spaces can refer to a festival's general kaupapa while describing their own practice. Editing that text records a change; it does not prove that everyone accepted a new shared understanding.
The map may be incomplete. “Near the kitchen”, “probably available”, and “ownership unknown” are useful records. Location does not imply ownership, helping does not imply sole responsibility, and a link does not prove endorsement. ValueFlows or another ontology may support a specialized view or export without becoming a prerequisite for recording a chair or task.
#Stewardship and facilitation are different jobs
Technical stewardship covers expressly granted digital powers such as enrollment, key changes, backup, hosting migration, and continuity. Facilitation supports people dealing with friction and harm. Neither power implies the other, and neither establishes control of a program or physical resource.
Roles can bundle understandable scopes, powers, duties, and review points. They may be held by several people or a collective. “Currently looking after this” is descriptive content unless someone separately grants technical authority; a broad title must not automatically inherit every specialized capability.
Ordinary interactions should include “I'm doing this”, “help wanted”, “here's what changed”, “I'm unsure”, and “this affects us”. Advice is not necessarily permission. Initiative over one's own contribution does not authorize another person's labor, use of a scarce shared resource, or disclosure of private information. Affected people must be able to respond without first becoming administrators.
#Shared custody needs boring defaults
Sensitive digital powers should be visible and recoverable without turning every edit into a governance transaction. The earlier two-of-three stewardship arrangement remains a candidate preset for specified sensitive operations, not a universal community constitution.
A quiet participant is not an absent or illegitimate steward. Activity counts and elapsed time alone cannot transfer authority. Small groups should see an accurate account of their custody arrangement rather than a claim of threshold protection they do not have.
#Routing must protect first and restore only when safe
Personal block and mute remain private, unilateral, and unaudited. Restorative participation is voluntary: a harmed person can choose no contact, represented contact, a written account, or protective separation. Threats, stalking, predation, targeted harassment, and coordinated abuse use the protective path. Category-specific illegal-content incidents use the separate legal/safety route (§08, §12).
Facilitators act within scope. Removing someone from one space does not automatically exclude them elsewhere or disclose their associations. Technical size supplies no broader social jurisdiction.
#Decisions need consent, not token weight
Most useful activity is not a formal decision case. Someone moving wet tools under cover should be able to act and record the new location afterward. Formal procedures remain available for significant shared commitments, protected budgets, scarce resources, sensitive keys, and recurring disagreement.
Advice, affected-party discussion, consent, and threshold authorization serve different purposes. Local addenda, trials, and alternative views need not trigger a constitutional fork. A festival may decline to use a space's version in its program without rewriting that space's record. Conflicting physical commitments still require people to resolve scarcity; copying a database cannot resolve them.
Community memory is not the technical audit trail. A coordination feed can reuse recorded intentions, changes, concerns, experiments, and outcomes. Recording is not the price of participation. A reported agreement establishes that someone reported it, not that everyone agreed; acknowledgment, disagreement, and correction remain possible. Silence from absent or offline participants is not collective consent.
#Admission is accountable without becoming a prize
Digital membership grants neither quantify belonging nor prove personhood. Invite-accountable, reviewed, small-group consent, and closed arrangements remain optional patterns. Invitations require acceptance within their intended scope; a fork does not transfer live invitations or enroll old members automatically.
#Anti-status mechanics are product requirements
Show relevant task responsibility rather than numeric power levels or public role ladders. Organize authority information by resource, domain, or action. Do not publish global moderator rosters, tenure medals, invite or contribution totals, vote/support counts, or cross-community performance histories. Quiet participation and care work must not count for less than visible activity.
Private accountability must not silently require permanently verifiable personal signatures on every contribution. Local evidence about how a record was received and transferable proof of original authorship are different choices.
#Forking and exit are anti-capture features
Leaving does not require permission. People may retain or export what they are entitled to retain and continue in another context. A different view, an adopted local version, a shared checkpoint, and a new community identity are distinct actions; most variation is not a hard fork.
Hard separation creates new future-access boundaries and opt-in membership. It must not automatically republish private history, reports, unrelated contributions, or a membership graph. Source endorsement is not a prerequisite for exit, and the original community is not the social winner merely because it came first. Physical property, money, and obligations need their own settlement.
#Discovery stays relational, even here
Discovery uses people, invitations, and deliberate references. Local search covers accessible material. Workspaces must not become person-wide activity repositories, global community rankings, or portable reputation indexes.
#Protocol and architecture
#Governance Surface Map
This boundary permits useful coordination without a universal administrative workflow. The validation owner may be an adopted library or a TalkCo component; the system must not maintain competing authority engines. The architecture chapter owns that composition decision. Storage and repair carry ciphertext without interpreting kaupapa or acquiring community powers.
| Object or relation | Proposed representation | Meaning it must preserve |
|---|---|---|
| Kaupapa, policy text, observation, intention | Typed content with revisions and optional references | A text change or report does not establish others' acceptance. |
| Adopted shared commitment | Explicit scoped record with its applicable acknowledgments or process | Acknowledgment and disagreement remain distinguishable from silence. |
| Technical grant | Resource, permitted action, holder, applicable policy state, term, and delegation limits | Descriptive responsibility cannot create a grant. |
| Coordination memory | Derived view of intentionally shared records | No automatic copy of safety cases or private technical history. |
| Private case | Separately encrypted evidence and outcome records | Restricted reviewers, disclosure, retention, and appeal. |
Exact schemas and authentication profiles remain open. No representation can turn a contested social claim into consensus by being stored in a log.
#Technology candidates for the shared workspace
| Seam | Likely candidate / alternative | Integration gate |
|---|---|---|
| Smaller shared core | Rust/Tokio plus SQLite/rusqlite; provisional experiment | One durable state owner for accepted events, retries, and local projections. |
| Collaborative content | Automerge, Yjs/Yrs, or another measured CRDT; optional adapter | Concurrent removal, malicious edits, dependent history, and late-reader admission. |
| Integrated workspace | DXOS/ECHO/Composer; whole-stack countercandidate | Compare identity, permissions, export, recovery, and total maintenance; do not assume a second SQLite authority store is required. |
| Action delegation | Biscuit, UCAN, or Meadowcap; bounded candidates | Adopt compatible scopes and revocation semantics; no implicit tenant superuser. |
| Private content | Object AEAD/HPKE, with OpenMLS where recurring groups justify it | Separate read, write, disclose, and recovery powers. |
| Synchronization | p2panda-sync or an adopted wider p2panda composition | Explicitly choose which library owns validation; test context and transport metadata. |
The sole candidate inventory owns qualifications and competing stacks. Optional ontology/export adapters remain outside the minimum act of contributing. The same shared core can serve TalkCo and a workspace without merging their audiences or requiring every user to install both modules.
#Variation — Separate approvals for a protected transition
A selected two-of-three preset can be represented as two independent approvals without requiring a shared signing secret. Each approval must bind the same operation, resource, prior state, and replay protection. Key release needs separate freshness rules because a later correction cannot retract a disclosed key. This preset applies only to named protected operations; routine authorized work need not wait for it.
#Variation — Threshold signing or conditional key release
FROST is a threshold signing protocol. It does not provide threshold decryption, social consent, or agreement on competing histories. A key-release committee has different collusion, outage, and recovery risks. Either option needs an explicit evidence profile: signatures can expose transferable control evidence, and encrypting them does not remove that property after disclosure.
Custody and recovery gates
A chosen preset names protected operations, grant holders, review/term rules, replacement, recovery, and unavailable-participant behavior. A single-custodian space is labeled accurately. No timer, participation score, hidden provider reset, or emergency superuser bypasses the accepted recovery policy. An old backup cannot restore revoked authority. Hosting that backup grants neither reading nor recovery power. Quorum counts must refer to authorized distinct custodians, not freely generated device keys.
#Local variation and a new community have different boundaries
An individual export, a checkpoint endorsed now, and original-author authentication establish different facts for later readers. Export must declare which is available. Exclude live invitations, unconsented member records, secret descriptors, recovery material, and private reports. Reusing ciphertext or source identifiers is permitted only inside the intended linkability boundary; §03 and lifecycle research own that boundary.
#Open Threads
- Low-overhead practice — #11. Test initiative, incomplete records, overlapping spaces, quiet participation, local variation, and repair without administrative prerequisites.
- Shared-object history — #2, #3, #5. Resolve technical grants, concurrent removal, late-reader evidence, and fork/export authentication.
- Sensitive custody — #4, #5. Select the operations that need multiple approvals, threshold signing, or conditional release; define failure and recovery before adoption.
- Evidence separation — #12. Keep community memory, private cases, technical integrity, and transferable proof distinct.
- Sequencing (OT-09-011). §12 owns launch scope. A shared core does not make the full workspace a launch requirement.