# 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)

1. **Identity infrastructure** — EncryptID is MEA-compatible out of the box
2. **Offline-first data sync** — Automerge CRDT matches MEA's sync requirements exactly
3. **Bounded collaborative containers** — Spaces serve as Pods with minor config
4. **Governance tooling** — rVote + rGov + rChoices cover pod-internal decision-making
5. **Communication** — rChat, rComments, rDocs for intra-pod collaboration
6. **Payment rails** — x402 + rWallet for transaction settlement
7. **Community funding** — rFunds for pod-level treasuries
8. **Audit trail** — Automerge's append-only change history
9. **Modular composition** — New MEA-specific modules plug into the existing system
10. **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.