What four peer projects taught us: DisCO, Hypha, Polis/Decidim, and DarkFi

[Argocyte]

What Four Peer Projects Taught Us About Cooperative Infrastructure

Following on from the ICN architecture review (Discussion #90), this post synthesises what we learned from the four other projects that directly inform Iskander's design: DisCO, Hypha DAO 3.0, Polis + Decidim, and DarkFi. Detailed reference documents for each are now in docs/reference/.

This is a design principles post — the GitHub issues (#91–#99) track the specific implementation work.

---

1. DisCO: Making Invisible Labour Visible

DisCO's core contribution is economic, not technological: all labour must be counted, not just the work that ships.

The three value streams:

• Productive — code shipped, hardware assembled, client work invoiced ← currently tracked (IskanderHearth only)
• Reproductive — maintaining docs, tools, supply chain, governance processes ← invisible
• Care/Commons — onboarding members, mediating conflicts, facilitating meetings, pro-bono contributions ← completely invisible

The cooperative principle this serves: ICA P3 (Economic Participation) has historically meant "members share profits." DisCO's feminist economics reading is stronger: members contribute in ways that are currently unpriced by capitalism, and those contributions must be counted.

A member who spends two hours mediating a conflict is doing something that makes the cooperative viable. If that's not in the ledger, the ledger is lying.

For Iskander: The labour_log table (issue #91) and the Clerk's care work prompting close this gap in the governance layer. DisCO's REA/Valueflows vocabulary (vf:EconomicEvent, vf:Intent, vf:Commitment) is the canonical schema — Iskander should speak this language for interoperability with the broader cooperative tech ecosystem.

---

2. Hypha DAO 3.0: The Failure Taxonomy Every Agent Must Know

Hypha evolved through three generations of DAO design. The failure arc is as important as the current architecture:

Generation	Design Principle	How It Failed
DAO 1.0	Code is Law	Edge cases become irresolvable crises. Upgrade key holders become oligarchs.
DAO 2.0	Protocol Optimisation	Sophisticated actors game the mechanism. Token weight → capital = power.
DAO 3.0	Human-Centred (DHO)	Correct. Blockchain = notary. Humans = governors.

Iskander is DAO 3.0 by design. But these failure modes must be explicit in every agent SOUL.md, because the pressure to revert to DAO 1.0/2.0 patterns is real:

• "Can the Clerk auto-approve decisions when Polis consensus is high?" → DAO 1.0 pressure (code replacing human consent)
• "Can we weight votes by governance participation score?" → DAO 2.0 pressure (mechanism gaming)

The answer to both is no, and the reason is the failure taxonomy.

For Iskander: The badge system (issue #95) and charter history endpoint (issue #97) are the Hypha contributions. But the deeper contribution is the failure vocabulary — which should be in agent design documentation, not just this post.

---

3. Polis + Decidim: The Deliberation Stack

These two tools complete the deliberation picture:

Polis discovers existing consensus before a vote. Its vTaiwan deployment revealed that stakeholders already agreed on 7 key principles before formal deliberation even began. The deliberation question shifted from "how do we decide?" to "how do we act on what we already agree?"

Decidim structures extended participatory processes — weeks of multi-stage deliberation before a formal vote. 400+ cities and organisations use it. Its accountability module (tracking implementation status of passed proposals) is Iskander's biggest current gap.

The full stack:

[Polis] → consensus map → [Loomio discussion] → [Loomio formal vote]
                                                       ↓
                                              [Decision Recorder]
                                                       ↓
                                          [Accountability tracker]
                                                       ↓
                               [Clerk] periodic reminders until implemented

The critical finding: plan.md contained if polis_consensus_rate > 0.85: skip Loomio — auto-approving governance decisions based on algorithm output. This violates ICA P2 and has been filed as a critical fix (issue #92). Polis informs. Loomio decides. Always.

---

4. DarkFi: The Privacy Philosophy, Not the Technology

DarkFi builds the most private blockchain infrastructure that exists. Its AnonDAO makes votes anonymous at the contract-state-privacy level. We're not adopting DarkFi's technology (MACI + BrightID is the right choice for cooperative governance — more mature, has Sybil resistance, has cooperative-appropriate anti-coercion properties).

What DarkFi contributes is the privacy philosophy: privacy is foundational, not optional. The default is private; disclosure is a deliberate act.

Applied to cooperative governance, this produces the three-layer privacy model:

Layer 1: Individual behaviour  →  fully private
Layer 2: Role participation    →  visible to the cooperative community
Layer 3: Cooperative decisions →  fully transparent to all members

These layers are not in tension. They resolve the apparent conflict between DarkFi's lunarpunk anonymity and cooperative accountability:

• You can be completely private in how you vote (Layer 1 / MACI)
• You are visible in which governance roles you participate in (Layer 2 / Glass Box)
• The decisions your cooperative makes are fully transparent (Layer 3 / Decision Recorder)

A member who facilitates three meetings contributes visibly (Layer 2) without revealing how they voted on any proposal (Layer 1). This is cooperative accountability and individual privacy.

---

The Common Thread: FOSS, Federation, and Feminist Economics

Across all four projects, the design pattern is consistent:

• No proprietary lock-in — Polis (AGPL), Decidim (AGPL), Loomio (AGPL), MACI (MIT), DarkFi (AGPL), Hypha DHO contracts (GPL). Every integration target is open source.
• No central authority — DisCO federates via ActivityPub. ICN federates via bilateral agreements. DarkFi routes via gossip. Decidim governs itself with Decidim (Metadecidim). The pattern is federation of peers, not hierarchy of nodes.
• Invisible labour made visible — DisCO's three streams, Hypha's badge system, Decidim's accountability tracking. All three independently arrive at the same conclusion: cooperatives under-count the work that keeps them alive.

Iskander's architecture absorbs all of these. The reference documents are in docs/reference/. The issues are #91–#99.

---

Related: Discussion #90 (ICN / Scratch for Governance) | Docs: docs/reference/disco-learnings.md, docs/reference/hypha-learnings.md, docs/reference/polis-decidim-learnings.md, docs/reference/darkfi-learnings.md

[Argocyte]

The Missing Piece: Governance Documents as Typed, Provenance-Tracked Events

One gap in the peer project analysis worth surfacing: none of the four projects reviewed cleanly solve the "where do adopted documents live, and how does their adoption get linked to the vote that created them?"

• DisCO: excellent on labour tracking, REA/Valueflows vocabulary — but document lifecycle is informal
• Hypha DAO 3.0: the DHO concept (Decentralized Human Organization) includes roles and circles, but document storage is off-chain and not cryptographically bound to governance decisions
• Polis/Decidim: deliberation tooling, not document lifecycle
• DarkFi: strong on privacy, but no document governance model

This is the gap ICN calls Station 5 (Policy) and Station 8 (Receipts) in their closure loop. The "governance document becomes policy" moment is not tracked anywhere.

Research: FOSS Options for a Legal Bridge

I evaluated three options against what Phase C already has in the stack:

HedgeDoc — collaborative Markdown editor

• Strengths: real-time collaborative editing, clean UX for non-technical users
• Weaknesses: extra service (~300MB RAM), OAuth setup needed, no formal approval workflow
• Verdict: Nextcloud Text does the same job with zero overhead

Forgejo — self-hosted Gitea fork (git-based doc workflow)

• Strengths: versioned documents, PR review workflow, excellent for code-adjacent governance
• Weaknesses: ~200MB RAM, requires git literacy from members, PR workflow is alien to most cooperative practitioners
• Verdict: right tool for software governance, wrong tool for policy documents drafted by non-developers

Nextcloud Text + Approve — already in the Phase C stack

• Strengths: zero additional RAM (runs within existing Nextcloud container), native Authentik SSO, familiar Google Docs-like interface, Approve app ships with NC28+
• Weaknesses: Markdown rather than rich text (acceptable for governance docs)
• Verdict: use this

The Workflow This Enables

Member → "Help me draft a policy on X" → Clerk
Clerk → creates draft in Nextcloud governance/drafts/ → notifies Loomio thread
Members → comment in Loomio + annotate in Nextcloud Text
Loomio proposal created → links to Nextcloud doc → vote
Outcome → Decision Recorder (decision_type="governance_adoption", content_hash, ipfs_cid)
Clerk → moves doc to governance/adopted/ → tags it → Approve marks it adopted

The IPFS pin at adoption creates a cryptographic receipt: the adopted text is permanently bound to the governance decision. This is Station 8 in the ICN closure loop.

DisCO Vocabulary Alignment

One of the peer project learnings from DisCO is the REA/Valueflows vocabulary (vf:EconomicEvent, vf:Intent, vf:Commitment). The same vocabulary applies to document governance:

• vf:Intent = "we intend to adopt a policy on X" (Loomio discussion)
• vf:Commitment = "we are voting on this specific draft" (Loomio proposal + content hash)
• vf:EconomicEvent = "this document is adopted" (governance_adoption Decision Recorder entry)

Speaking this vocabulary makes Iskander's document governance records interoperable with the broader cooperative tech ecosystem (Valueflows, DisCO tooling, any REA-aware system).

Implementation Path

Filed as issue #113. The implementation touches:

1. Decision Recorder — new governance_adoption type with document_uri, content_hash, upstream_decision_ids, scopes
2. Clerk tools — nextcloud_create_document, nextcloud_move_document, nextcloud_tag_document (all Glass Box write actions)
3. Nextcloud Helm chart — enable Approve + Flow apps (zero RAM cost)
4. First-boot wizard — create governance/drafts/ and governance/adopted/ folder structure

This closes the provenance gap (issue #78), contributes to scope tagging (issue #77), and makes the closure loop (issue #82) actually close at Station 5 and 8.

[Argocyte]

Update 2026-04-12: Bonfire Networks is now a named peer project with a warm outreach lead at bonfire-networks/bonfire-app#1938. Reference memory R2 covers: Circles/Boundaries as the inter-coop @mentions primitive, 6 flavours mapped to Iskander needs, AGPL-3.0 + NLnet-funded. Per AGM A10, Iskander adopts Social + Community only. Full analysis in reference_bonfire_networks.md. — Et