193 lines
11 KiB
Markdown
193 lines
11 KiB
Markdown
# 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.
|