11 KiB
MEA ↔ rSpace-Online Capability Alignment
Analysis of how rSpace-Online's existing modules and architecture map to the requirements of the Mycelial Economics (MEA) framework.
Executive Summary
rSpace-Online is a remarkably strong candidate as an implementation substrate for MEA. The architectural alignment is deep — both systems share a local-first, offline-first philosophy, self-sovereign identity, bounded collaborative spaces, and modular composition. Roughly 70% of MEA's core infrastructure requirements are already addressed by existing rSpace modules or architectural primitives. The remaining 30% — primarily the exchange gradient engine, pod mitosis protocol, and relationship-cap enforcement — are well-defined extensions that fit naturally into rSpace's module system.
1. Core Concept Mapping
1.1 MEA Pod ↔ rSpace Space
| MEA Requirement | rSpace Capability | Status |
|---|---|---|
| Pod as fundamental unit (~8 members, max 12 for L0) | Space — bounded collaborative container with member list | ✅ Exists |
| Pod levels L0–L5 with different member caps | Space nesting (child spaces) with permission cascading | ✅ Partial — nesting exists, but no enforced level taxonomy or member caps per level |
| Pod metadata (purpose, creation date, state) | Space metadata schema, custom docSchemas per module | ✅ Exists |
| Pod state machine (forming → active → dividing → dissolved) | No built-in space lifecycle states | ❌ Gap |
| Membership state machine (pending → active → inactive/suspended) | Space roles & consent controls (4 visibility levels) | ✅ Partial — roles exist, no formal state machine |
Assessment: rSpace Spaces are a natural fit for MEA Pods. The key additions are: enforced member caps (trivial config), a Pod-level taxonomy (L0–L5 type field), and lifecycle state machines (moderate effort, fits the module pattern).
1.2 MEA Identity ↔ EncryptID
| MEA Requirement | rSpace Capability | Status |
|---|---|---|
| Self-sovereign identity, no central authority | EncryptID — WebAuthn passkeys, DID-based ownership | ✅ Direct match |
| Identity = participation history (continuously evolving) | Automerge event log tracks all actions per participant | ✅ Exists |
| Multi-device support | EncryptID supports multiple passkeys per identity | ✅ Exists |
| Trust derived from observable behavior | rNetwork module — social graph, reputation scoring | ✅ Exists |
| Anonymous until opted in | DID-based, no PII required at protocol level | ✅ Exists |
Assessment: Near-perfect alignment. EncryptID already implements the identity model MEA describes. The main extension would be formalizing a "coherence score" derived from participation history (rNetwork could surface this).
1.3 MEA Offline-First ↔ Automerge CRDT
| MEA Requirement | rSpace Capability | Status |
|---|---|---|
| Offline-first, mobile-first (Dharavi standard) | Automerge CRDT — local-first, conflict-free sync | ✅ Direct match |
| SQLite local storage | IndexedDB (browser) — functionally equivalent | ✅ Equivalent |
| Sync envelopes with vector clocks | Automerge sync protocol (built-in vector clocks) | ✅ Exists |
| Conflict resolution (last-writer-wins with audit) | CRDT automatic merge + conflict record logging | ✅ Exists |
| Event immutability (append-only audit trail) | Automerge change history is inherently append-only | ✅ Direct match |
| 4-layer data: device → server → shared → federated | rSpace 4-layer: Device (IndexedDB) → Server Backup → Shared Space Sync → Federated Replication | ✅ Direct match |
Assessment: This is the strongest alignment point. rSpace's Automerge-based data architecture was designed for exactly the connectivity constraints MEA targets. The 4-layer data model is almost identical. MEA's spec calls for SQLite (mobile-native); for a web-first deployment, IndexedDB is the direct equivalent. A future React Native or Capacitor wrapper could use SQLite underneath the same Automerge documents.
1.4 MEA Exchange Protocol ↔ x402 + rWallet + rFunds
| MEA Requirement | rSpace Capability | Status |
|---|---|---|
| Exchange gradient (50%–100% based on relational distance) | No built-in gradient pricing engine | ❌ Gap — core MEA innovation |
| Transaction lifecycle (draft → proposed → accepted → settled) | x402 payment protocol handles request/settle flow | ✅ Partial |
| Multi-currency / unit-of-account flexibility | rWallet — multi-chain Safe (Base, Optimism, Arbitrum) | ✅ Exists |
| Community treasury | rFunds — community funding pools with allocation rules | ✅ Exists |
Rate calculation: min(1.00, 0.50 + 0.10 * counterparty_level) |
Not implemented | ❌ Gap |
| Transaction anti-gaming (volume caps, burst detection) | No built-in rate limiting at transaction level | ❌ Gap |
Assessment: rSpace has strong payment rails (x402, rWallet, rFunds) but lacks
MEA's distinctive exchange gradient — the mechanism where transactions between closely
related pods get preferential rates. This is MEA's core economic innovation and would
need to be built as a new module (e.g., rExchangeGradient or integrated into the
existing rExchange module). The gradient formula is simple; the complexity is in
reliably determining relational distance between any two participants across the pod graph.
1.5 MEA Relationship Graph ↔ rNetwork
| MEA Requirement | rSpace Capability | Status |
|---|---|---|
| Pod-to-pod relationships (max 5 per pod at L0) | rNetwork — social graph with connections | ✅ Partial — no relationship caps |
| Relationship state machine (requested → active → severed) | rNetwork connection lifecycle | ✅ Partial |
| Relational distance calculation (pod level hops) | Not implemented as a graph metric | ❌ Gap |
| Relationship capacity constraints per pod level | Not enforced | ❌ Gap |
Assessment: rNetwork provides the social graph substrate. Extensions needed: relationship caps per pod level, a graph-distance calculation service (for the exchange gradient), and formal relationship lifecycle states matching MEA's spec.
1.6 MEA Governance ↔ rVote + rGov + rChoices
| MEA Requirement | rSpace Capability | Status |
|---|---|---|
| Pod-internal decisions (consensus within ~8 people) | rVote — voting within spaces | ✅ Exists |
| Multi-criteria evaluation | rChoices — multi-criteria decision framework | ✅ Exists |
| Governance primitives (proposals, quorum, delegation) | rGov — governance module | ✅ Exists |
| Membership admission/removal votes | rVote can be scoped to membership decisions | ✅ Exists |
| Mitosis trigger vote (when pod exceeds size) | No built-in mitosis trigger | ❌ Gap |
Assessment: Governance is well-covered. The main addition is wiring governance outcomes to pod lifecycle events (e.g., a successful mitosis vote triggers the pod division protocol).
2. Architecture Alignment Summary
| Architectural Principle | MEA | rSpace | Match |
|---|---|---|---|
| Local-first / offline-first | ✅ Core requirement | ✅ Automerge CRDT | 🟢 |
| Self-sovereign identity | ✅ No central authority | ✅ EncryptID + DID | 🟢 |
| Bounded groups | ✅ Pods with member caps | ✅ Spaces with roles | 🟡 (caps not enforced) |
| Modular protocol | ✅ Protocol layer defines valid interactions | ✅ RSpaceModule interface | 🟢 |
| Append-only audit trail | ✅ Event immutability | ✅ Automerge history | 🟢 |
| Sparse network topology | ✅ Limited inter-pod relationships | ⚪ Not enforced | 🟡 |
| Mobile-first UX | ✅ Dharavi standard | ⚪ Web-first (responsive) | 🟡 |
| Federated replication | ✅ Sync across nodes | ✅ Layer 4 federation | 🟢 |
Overall architectural match: Strong (6/8 green, 2/8 yellow, 0/8 red)
3. Module-by-Module Relevance
Directly Relevant rSpace Modules
| Module | MEA Concept Served | Notes |
|---|---|---|
| rNetwork | Relationship graph, trust, reputation | Needs: caps, distance calc |
| rFunds | Community treasury, pooled resources | Maps to pod-level treasury |
| rWallet | Multi-chain payments | Transaction settlement layer |
| rExchange | Token/value exchange | Needs: gradient pricing overlay |
| rVote | Pod-internal governance | Works as-is for small groups |
| rGov | Governance primitives | Proposal/quorum framework |
| rChoices | Multi-criteria decisions | Pod decision-making tool |
| rChat / rComments | Pod-internal communication | Direct use |
| rDocs | Shared knowledge within pods | Direct use |
| rFiles | Shared assets | Direct use |
| rCalendar | Pod coordination | Direct use |
Potentially Relevant
| Module | Possible Use |
|---|---|
| rMarket | Marketplace within/across pods |
| rTasks | Pod work coordination |
| rCanvas | Collaborative planning |
| rMetrics | Pod health / coherence dashboards |
4. What rSpace Already Provides (No Changes Needed)
- Identity infrastructure — EncryptID is MEA-compatible out of the box
- Offline-first data sync — Automerge CRDT matches MEA's sync requirements exactly
- Bounded collaborative containers — Spaces serve as Pods with minor config
- Governance tooling — rVote + rGov + rChoices cover pod-internal decision-making
- Communication — rChat, rComments, rDocs for intra-pod collaboration
- Payment rails — x402 + rWallet for transaction settlement
- Community funding — rFunds for pod-level treasuries
- Audit trail — Automerge's append-only change history
- Modular composition — New MEA-specific modules plug into the existing system
- Federated replication — Layer 4 data architecture supports multi-node sync
5. Strategic Assessment
rSpace isn't just "compatible" with MEA — it appears to have been designed with overlapping first principles. Both systems prioritize:
- Coherence over scale — bounded groups, quality relationships
- Sovereignty over convenience — self-sovereign identity, local-first data
- Protocol over policy — defining valid interactions structurally, not legally
- Emergence over control — modules compose; behavior emerges from composition
The MEA framework would function as a configuration + extension layer on top of rSpace, rather than requiring a ground-up rebuild. The new components (exchange gradient, mitosis protocol, relationship caps) are well-scoped and fit the existing module pattern.
A reasonable path forward would be to build MEA as an rSpace "flavor" — a curated set of modules with MEA-specific configuration and 2–3 new modules for the unique protocol elements. This preserves rSpace's generality while giving MEA a concrete, deployable implementation.