Skip to content

Instantly share code, notes, and snippets.

@kahunamoore
Last active March 8, 2026 18:30
Show Gist options
  • Select an option

  • Save kahunamoore/bd201fe98bce112fd8abd123d45b16e9 to your computer and use it in GitHub Desktop.

Select an option

Save kahunamoore/bd201fe98bce112fd8abd123d45b16e9 to your computer and use it in GitHub Desktop.
Federated Co-op Source Network Trust Architecture

Integrating trust into ATProto cooperative governance

TrustNet plus Semaphore on ATProto custom lexicons is the most practical foundation for CSN V5's trust network, combining subjective multi-dimensional trust scores, anonymous ZK-based voting, and verifiable append-only audit logs — all implementable in your TypeScript/Express/PostgreSQL stack without blockchain dependencies. The ATProto ecosystem's lexicon extensibility, labeler infrastructure, and January 2026 DID:PLC streaming API provide the protocol-level primitives needed to make trust a first-class citizen of the federated network. Real-world cooperative governance patterns and hard lessons from fediverse trust systems (SourceCred's collapse, The Bad Space controversy, IFTAS's funding crisis) point toward a tiered, human-in-the-loop trust architecture where algorithmic scores inform but never replace democratic membership decisions.


Trust algorithms that fit cooperative-scale networks

For a platform serving 50–5,000 members, two complementary algorithms cover the full trust surface. Appleseed (via the trustnet npm package) provides subjective, per-member trust rankings with native multi-dimensional support — exactly what cooperative governance demands. The TrustNet library implements "trust areas" as a first-class concept, letting you run independent trust computations for financial decisions, governance votes, and technical contributions. At 500 members, Appleseed computes in 10–50ms per source node; at 5,000 members, 100–500ms — well within acceptable latency for background computation.

EigenTrust complements Appleseed by providing global reputation scores with strong Sybil resistance. The Karma3Labs go-eigentrust sidecar server (production-tested in the Farcaster ecosystem) converges in under 10 iterations, handling 5,000-member networks in 50–200ms. Its pre-trusted peer mechanism — where founding cooperative members serve as trust anchors — maps naturally to cooperative governance hierarchies. Running it as an HTTP sidecar alongside Express keeps the Node.js event loop unblocked.

For real-time trust queries (e.g., "can this member approve this transaction right now?"), MoleTrust-style depth-limited BFS delivers sub-20ms latency regardless of network size by capping path exploration at 3–4 hops. No npm package exists for MoleTrust, but the algorithm is straightforward BFS (~150 LOC) that can query directly against PostgreSQL's trust edge table.

Algorithm Type 500-member latency 5K-member latency Multi-dim trust Sybil resistance npm package
Appleseed (TrustNet) Local/subjective 10–50ms 100–500ms ★★★★★ native ★★★ moderate trustnet v1.0.1
EigenTrust Global <10ms 50–200ms ★★★ per-dimension runs ★★★★★ strong Go sidecar (go-eigentrust)
TidalTrust Local/pairwise <5ms <20ms ★★★★ ★★★ None (custom impl)
MoleTrust Local/depth-limited <5ms <20ms ★★★★ ★★★★ None (custom impl)
OpenRank/EigenTrust++ Global + personalized <10ms 50–200ms ★★★★ multi-scope ★★★★★ ts-eigencaster (TS wrapper)

The trustnet npm package (AGPL-3.0, dual-licensing available for nonprofits) is the single most relevant library. Built by Alexander Cobleigh and proven in Cabal's peer-to-peer chat moderation, it wraps Appleseed with a TrustHandler class that manages multiple trust areas. The underlying appleseed-metric package provides the raw algorithm if you need lower-level control. Both packages are stable but low-activity (~3 years since last publish) — fork readiness is advisable.

The recommended architecture layers these algorithms: TrustNet for per-member subjective rankings in Express request handlers, MoleTrust-style BFS for real-time authorization checks against PostgreSQL, and go-eigentrust as a background sidecar recomputing global scores every 5–15 minutes. Trust attestation events from ATProto's firehose trigger incremental cache invalidation, with full EigenTrust recomputation debounced as a periodic job.


ATProto already has the trust building blocks

ATProto's architecture provides three protocol-level primitives that CSN V5 can leverage immediately. Custom lexicons are the foundation: the PDS is lexicon-agnostic, accepting any valid JSON record regardless of namespace. A network.csn.trust.attestation lexicon can define trust endorsement records stored in members' repos — self-authenticating (signed by the member's key), portable across PDSes, and flowing through the firehose for indexing. The Lexinomicon style guide and Lexicon Resolution RFC provide design guidance, and the lexicon-community/awesome-lexicons repository shows real-world examples.

Ozone labelers serve as trust signal aggregators. Third-party labelers are not limited to moderation — they can publish positive attestations, membership verification badges, or reputation signals. The @skyware/labeler package provides a lightweight alternative to full Ozone deployment, and CSN V5's existing Ozone integration means the infrastructure is already in place. Labels propagate cryptographically signed through the AppView layer, giving trust decisions network-wide visibility.

The DID:PLC transparency log gained significant new capability in January 2026 with the /export/stream WebSocket endpoint for real-time sync and sequence-number-based pagination. DID operations — key rotations, handle changes, PDS migrations — are auditable trust signals. The str4d/plc tool validates audit logs, and ATmosphereConf 2026 includes talks on "DID:PLC War Games" and self-sovereign identity forks, indicating active community work on DID trust infrastructure.

HappyView deserves special attention for CSN V5. This lexicon-driven generic AppView framework by Trezy auto-generates XRPC endpoints from uploaded lexicon schemas, provides real-time firehose sync with cryptographic verification, and supports Lua scripting for custom index hooks. It dramatically lowers the barrier to building a trust-specific AppView — define your trust lexicons, deploy HappyView, and get a working indexed API with minimal code.

Brittany Ellich's groups-as-DID pattern from opensocial.community maps directly to cooperative membership: groups are represented as DIDs on a dedicated PDS, membership records live in individual users' repos (self-sovereign), and multiple AppViews can share the same group. Her ATmosphereConf 2026 talk "Who owns the group chat?" will detail the architecture further. This pattern provides a clean foundation for bilateral membership verification — the cooperative's DID and the member's DID both holding matching records, which CSN V5 already implements.


Verifiable credentials and selective disclosure are production-ready

The W3C Verifiable Credentials Data Model v2.0 became a full W3C Recommendation on May 15, 2025, comprising seven specifications. For cooperative membership credentials, the most relevant securing mechanism is SD-JWT (RFC 9901, finalized November 2025), which enables selective disclosure without the complexity of BBS+ signatures. A cooperative membership credential could contain employment status, membership tier, voting rights, capital account balance, and compliance certifications — with the holder choosing which attributes to disclose to each verifier.

The @sd-jwt/core package from the OpenWallet Foundation is the reference TypeScript implementation, compliant with RFC 9901. It works in Node.js, browsers, and React Native. For the VC framework layer, Veramo (@veramo/core) is the most comprehensive TypeScript option — plugin-based architecture supporting DID management, key management, credential issuance/verification in both JWT and JSON-LD formats, and extensible to custom DID methods.

No existing integration between W3C VCs and ATProto/did:plc exists, but the path is clear: use did:web for the cooperative's issuer identity (CSN V5 controls its domain), reference members by their did:plc identifiers as credential subjects, and store credential metadata as custom ATProto records. The VC ecosystem doesn't require the DID method to "know about" VCs — credentials are signed by the issuer's key and reference the subject's DID independently.

BBS signatures remain at IETF draft stage (the W3C VC-DI-BBS spec is a Candidate Recommendation, blocked on IETF finalization). They offer the strongest privacy properties — unlinkable selective disclosure where different presentations of the same credential cannot be correlated — but at higher implementation complexity. The @digitalbazaar/bbs-signatures package is the most current active library, aligned with IETF draft v8. For CSN V5's initial implementation, SD-JWT provides sufficient privacy with much lower integration complexity; BBS can be added later for scenarios requiring unlinkable presentations.


ZK voting is practical today for cooperatives

Semaphore v4 is the clear choice for anonymous governance voting. Purpose-built for anonymous group membership proofs, it runs entirely off-chain (no blockchain required), generates proofs in 2–5 seconds in the browser (WASM) and ~1 second in Node.js, and verifies in 10–50ms. The trusted setup ceremony was completed in July 2024 with 400+ participants. All packages are published under @semaphore-protocol/* on npm with full TypeScript types.

The integration pattern for CSN V5: the cooperative maintains a Lean Incremental Merkle Tree of member identity commitments (EdDSA public keys). When a vote occurs, each member generates a ZK-SNARK proof in their SvelteKit browser client proving they hold a private key whose commitment is in the group tree, without revealing which member they are. A deterministic nullifier (derived from identity + vote scope) prevents double-voting while maintaining anonymity. The server verifies proofs and records votes with their nullifiers.

Member registers → EdDSA keypair generated client-side
                 → Public commitment added to cooperative's Merkle tree (PostgreSQL)

Vote initiated  → Member's browser generates ZK proof (~3s WASM)
                → Proof + nullifier + encrypted vote sent to server
                → Server verifies proof against current Merkle root (~10ms)
                → Nullifier checked for double-vote prevention
                → Vote recorded anonymously

For high-stakes decisions requiring anti-collusion properties (preventing vote buying), MACI (Minimal Anti-Collusion Infrastructure) from PSE/Ethereum Foundation has been production-tested with 924,000+ whitelisted voters in the DoraHacks/Taiko deployment. However, MACI requires Ethereum smart contracts and a trusted coordinator — significantly more complex than Semaphore. It should be considered a Phase 2 addition for CSN V5, not the initial implementation.

The supporting library ecosystem is mature: snarkjs for core ZK-SNARK operations, @zk-kit/* packages for Merkle trees and cryptographic primitives, and circom/circomlib if custom circuits become necessary. All are battle-tested in production across the Ethereum ecosystem.


Append-only audit logs for trust accountability

Certificate Transparency's architecture maps directly to cooperative trust decision logging. Every membership approval, trust score change, voting result, and federation action becomes a leaf in a Merkle hash tree. Signed Tree Heads (root hash + tree size + timestamp + Ed25519 signature) provide tamper-evident snapshots. Inclusion proofs (O(log n) hashes) prove a specific decision was logged. Consistency proofs prove the log is append-only — no entries removed or modified.

For the PostgreSQL implementation, merkletreejs is the most flexible TypeScript library, with IncrementalMerkleTree supporting append-only operations. The @openzeppelin/merkle-tree package provides stronger security defaults (double-hashing leaves to prevent second preimage attacks) and multiproof support. For storage-backed trees, Keybase's merkle-tree package offers pluggable storage backends that can be pointed at PostgreSQL via Kysely.

The implementation pattern fits naturally into Express middleware:

  • Submit: Trust decision arrives → validate → assign leaf index → return Signed Certificate Timestamp (promise of inclusion)
  • Integrate: Background sequencer batches new entries every N seconds → computes new Merkle root → generates and stores STH
  • Verify: Any member requests inclusion proof for a decision → server returns sibling hashes → member verifies against known STH
  • Audit: External auditors (other cooperatives, regulators) reconstruct the full tree, verify all STHs are consistent, check for policy violations

Google's Trillian Tessera (beta, production-ready on GCP) provides the gold-standard reference architecture for tile-based transparency logs but requires a Go sidecar. For CSN V5's scale, a pure TypeScript implementation using merkletreejs with PostgreSQL storage is more pragmatic — the CT patterns (STH signing, inclusion/consistency proofs) can be implemented directly without Trillian's operational overhead.


Hard lessons from real-world federated trust

The fediverse blocklist ecosystem offers CSN V5's trust network a field guide of what works and what destroys credibility. Seirdy's tiered blocklist model — FediNuke (worst-of-worst, ~140 instances with documented receipts) → Tier-0 (semi-curated, broader) → supplemental lists — demonstrates that graduated confidence levels with transparent evidence is the most respected approach. Every entry has "receipts" — documented evidence justifying the listing.

The Bad Space controversy is the cautionary tale. Algorithmic aggregation of blocklists without human curation amplified errors: a bug incorrectly listed queer-friendly servers and the Linux kernel's social instance. Lack of visible receipts, unclear methodology, and no accessible appeals process destroyed credibility permanently. The key lesson: a single bug in a trust system can permanently damage trust in the trust system itself.

SourceCred's collapse (wind-down March 2022) provides the definitive case against fully algorithmic reputation. When Discord/Discourse contribution plugins were added, Goodhart's Law kicked in immediately — members changed behavior to game the algorithm rather than contribute. The project's own post-mortem identified the missing piece: making it easy for non-technical people to collectively weight what was rewarded. Pure algorithmic reputation leads to gaming; pure peer evaluation leads to popularity contests. Cooperative trust requires hybrid approaches.

Gitcoin Passport (now Human Passport after Holonym Foundation's acquisition, 2M+ users, 34M+ credentials) demonstrates the most successful Sybil-resistant identity model. Its composable "stamps" approach — different verifiable credentials contributing different scores — maps directly to cooperative membership criteria where employment verification, geographic residency, skills demonstration, and governance participation could each serve as trust signals.

IFTAS's critical funding crisis ($1.2M budget shortfall, February 2025) is perhaps the most important lesson: trust infrastructure is a public good that is chronically underfunded. Cooperatives must build trust system maintenance into their operating budgets, not treat it as volunteer work.


OpenID Federation finalizes at the right time

OpenID Federation 1.0 was approved as a Final Specification on February 17, 2026 — just weeks before this research. The specification maps remarkably well to ICA cooperative federation structures: ICA serves as the Trust Anchor, regional bodies (ICA Americas, ICA Europe) as Intermediate Authorities, national federations as second-level intermediaries, and individual cooperatives as Leaf Entities.

Trust Marks — signed JWTs asserting an entity meets certain criteria — provide the mechanism for cooperative identity certification. A national federation could issue Trust Marks for "verified worker cooperative" or "ICA Principle-compliant" that any relying party can cryptographically verify through the trust chain. Metadata Policies cascade down the hierarchy, enforcing minimum security requirements across all member cooperatives.

The TypeScript ecosystem is emerging but early: @openid-federation/core from the OpenWallet Foundation Labs is the primary library, actively developed but at Lab stage with limited documentation. The Italian spid-cie-oidc Node.js package is more mature but profile-specific. For CSN V5, OpenID Federation is a medium-term integration target — the specification is now stable, but TypeScript tooling needs 6–12 months of maturation. The CT-style audit log should log all federation trust operations (subordinate statement issuance, trust mark grants, revocations) for full accountability.


Cooperative membership gating has a well-established legal framework

ICA Principle 1 explicitly permits significant trust gating through two qualifications: members must be "able to use their services" and "willing to accept the responsibilities of membership." This provides legal and ethical basis for probationary periods, skill requirements, membership fees, geographic restrictions, and behavioral standards — as long as these don't discriminate on protected characteristics.

Mondragon's model is the gold standard for phased trust: 6–12 month probation, ~€14,000–18,000 capital contribution (financeable), confirmation by cooperative assembly vote, size limitation of ~400–500 workers per cooperative unit before splitting. Credit unions use field of membership rules — occupational, associational, or geographic common bonds — to define trust boundaries while remaining accessible. Worker cooperatives universally use probationary periods with peer assessment before full membership votes.

For CSN V5, these patterns translate to a trust progression system: applicant (identity verified, basic KYC) → provisional member (probationary period, limited governance rights, building trust score) → full member (cooperative assembly vote, full governance and capital rights) → trusted delegate (earned through sustained participation, eligible for delegation voting and federation roles). Each tier maps to specific trust score thresholds, VC credential tiers, and Semaphore group memberships.


Recommended architecture for CSN V5 trust integration

The following architecture integrates all researched components into CSN V5's existing Express 5 + PostgreSQL 16 + Kysely stack:

  • Trust graph storage: PostgreSQL table trust_edges(source_did, target_did, dimension, weight) with indexes on both source and target DIDs per dimension. Trust scores cached in trust_scores_global table, refreshed by background worker.

  • Subjective trust: TrustNet (trustnet npm) loaded per-request for member-specific trust rankings across financial, governance, and technical dimensions. Cache in Redis or in-memory with invalidation on trust attestation events.

  • Global reputation: go-eigentrust as Docker sidecar on localhost, called via HTTP from a Node.js background worker every 5–15 minutes. Pre-trusted peers = founding members + board.

  • Real-time authorization: Custom MoleTrust BFS (depth 3–4) querying PostgreSQL directly for sub-20ms trust checks on sensitive operations.

  • ATProto integration: Custom network.csn.trust.* lexicons for trust attestations stored in member repos. CSN Ozone labeler aggregates trust signals into labels. Firehose consumer triggers trust graph updates.

  • Verifiable credentials: Veramo framework issuing SD-JWT membership credentials against did:web:csn.network issuer identity, referencing member did:plc subjects.

  • Anonymous voting: Semaphore v4 off-chain groups. Member identity commitments in PostgreSQL Merkle tree. WASM proof generation in SvelteKit client. Server-side verification with nullifier tracking.

  • Audit log: CT-style Merkle tree over all trust decisions using merkletreejs with PostgreSQL storage. Signed Tree Heads every 60 seconds. Inclusion/consistency proof API endpoints.

  • Federation trust: OpenID Federation 1.0 for inter-cooperative trust chains (medium-term, pending TypeScript library maturation). Trust Mark issuance for cooperative identity certification. All federation operations logged to the Merkle audit log.

The critical insight from every failed trust system is this: governance of the trust algorithm matters as much as the algorithm itself. CSN V5 should expose trust computation parameters (Appleseed spreading factor, EigenTrust alpha, MoleTrust depth limits, trust dimension weights) to democratic governance — let the cooperative membership collectively steer how trust is computed, with transparent audit logs recording every parameter change. This is what SourceCred lacked and what killed it.

Conclusion

CSN V5 is unusually well-positioned for trust network integration. Its existing bilateral membership model, Ozone labeler integration, and three-tier data architecture already implement the foundational patterns. The ATProto ecosystem is converging on the right primitives — custom lexicons, third-party labelers, DID:PLC streaming, and groups-as-DID — while the cryptographic toolchain (SD-JWT finalized November 2025, Semaphore v4 audited, OpenID Federation 1.0 approved February 2026) has reached production maturity at exactly the right moment.

Three implementation priorities emerge. First, deploy TrustNet with multi-dimensional trust areas and the CT-style audit log — these provide the core trust computation and accountability infrastructure with minimal dependencies. Second, add Semaphore v4 anonymous voting for governance decisions where ballot secrecy matters — the off-chain mode requires no blockchain infrastructure. Third, integrate SD-JWT membership credentials and begin OpenID Federation trust chain resolution as the TypeScript libraries mature through 2026. ATmosphereConf 2026 (March 26–29, Vancouver) will be critical for coordination — multiple trust-relevant talks are scheduled, NorthSky (a Canadian cooperative running ATProto infrastructure) received the first IndieSky grant, and the "Coop: Open source Trust & Safety infrastructure for all" talk directly addresses CSN V5's domain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment