commit 573fe6081649fe0f6eeb409524c2c30a589dfe34 Author: Jeff Emmett Date: Tue Apr 7 16:53:32 2026 -0400 Initial commit: MEA analysis in context of rSpace-Online Add the Mycelial Economics (MEA) PDF and analysis documents examining how rSpace-Online's existing module ecosystem aligns with MEA's protocol-based economic coordination framework. Co-Authored-By: Claude Opus 4.6 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e2ca79a --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +.env +.DS_Store +*.swp +*.swo +node_modules/ diff --git a/2026-03-29 Mycelial Economics (MEA) [Full].pdf b/2026-03-29 Mycelial Economics (MEA) [Full].pdf new file mode 100755 index 0000000..47210f9 Binary files /dev/null and b/2026-03-29 Mycelial Economics (MEA) [Full].pdf differ diff --git a/README.md b/README.md new file mode 100644 index 0000000..267db13 --- /dev/null +++ b/README.md @@ -0,0 +1,20 @@ +# Melton Foundation — MEA Analysis + +Research and analysis repository for evaluating the **Mycelial Economics (MEA)** framework +in the context of [rSpace-Online](https://rspace.online) collaborative tools. + +## Contents + +- `2026-03-29 Mycelial Economics (MEA) [Full].pdf` — Original MEA document (104 pages) +- `analysis/mea-rspace-alignment.md` — Detailed capability mapping: MEA requirements vs rSpace modules +- `analysis/gap-analysis.md` — Gaps and potential new modules / extensions + +## Context + +Mr. Melton shared the MEA framework — a protocol-based economic coordination system +built around small, bounded groups ("Pods") that grow through division (mitosis), +maintain intentionally sparse inter-pod relationships, and use a gradient-based +exchange protocol tied to relational distance. + +This repo examines how rSpace-Online's existing module ecosystem might serve as +an implementation substrate for MEA concepts. diff --git a/analysis/gap-analysis.md b/analysis/gap-analysis.md new file mode 100644 index 0000000..deaafea --- /dev/null +++ b/analysis/gap-analysis.md @@ -0,0 +1,192 @@ +# MEA Gap Analysis — What rSpace Needs to Add + +> Components from the MEA spec not currently covered by rSpace-Online, +> with implementation complexity estimates and suggested approaches. + +--- + +## Gap 1: Exchange Gradient Engine (High Priority) + +**MEA Requirement:** Transactions between participants are priced according to +relational distance. L0↔L0 (same pod) = 50% rate; each level of separation adds +10%, up to 100% for L0↔L5 interactions. + +``` +rate = min(1.00, 0.50 + 0.10 * counterparty_level) +``` + +**What's Missing:** +- Graph-distance calculation service (shortest path between two participants across the pod hierarchy) +- Rate-application middleware that intercepts exchange/payment flows +- Rate display in transaction UX ("you're paying 60% because you're 1 hop away") + +**Suggested Approach:** +- New module `rGradient` or extension to `rExchange` +- Maintain a materialized view of the pod relationship graph (updated on membership/relationship changes) +- Expose a `getRate(participantA, participantB)` function consumed by rExchange and rWallet +- Complexity: **Medium** — the formula is trivial; the graph traversal at scale needs caching + +--- + +## Gap 2: Pod Mitosis Protocol (High Priority) + +**MEA Requirement:** When a pod exceeds its effective size (12 for L0), it must +divide into two pods. This is biological — growth through division, not expansion. + +**What's Missing:** +- Mitosis trigger detection (member count exceeds threshold) +- Mitosis governance flow (vote to divide, select split) +- Automated pod creation (new Space, member reassignment, relationship inheritance) +- Post-mitosis relationship establishment between the two new pods + +**Suggested Approach:** +- New module `rMitosis` that monitors pod membership counts +- When threshold is reached: surface a governance proposal via rVote +- On approval: execute the split (create new Space, move members, establish inter-pod relationship) +- Preserves Automerge history in both resulting pods +- Complexity: **Medium-High** — the governance flow exists; the automated split logic is new + +--- + +## Gap 3: Pod Level Taxonomy & Member Caps (Medium Priority) + +**MEA Requirement:** Pods have typed levels (L0 through L5) with specific +member caps: L0 = max 12, L1–L5 = max 8 each. Different levels serve +different functions (L0 = primary creative, L1–L5 = functional aggregation). + +**What's Missing:** +- Pod level type field on Spaces +- Enforced member caps per level +- Level-specific behavioral rules (what an L3 pod can/cannot do vs an L0) + +**Suggested Approach:** +- Add a `meaPodLevel` metadata field to the Space schema +- Enforce member caps in the Space membership admission flow +- Level-specific rules as module configuration +- Complexity: **Low** — mostly configuration on existing primitives + +--- + +## Gap 4: Relationship Capacity Constraints (Medium Priority) + +**MEA Requirement:** Pods have limited relationship slots. L0 pods can maintain +max 5 inter-pod relationships. This ensures the network stays intentionally sparse. + +**What's Missing:** +- Relationship count enforcement per pod +- Relationship slot management (which relationships to maintain/dissolve) +- Visibility into remaining capacity + +**Suggested Approach:** +- Extension to rNetwork: add `maxRelationships` config per Space type +- Reject new relationship requests when at capacity +- Dashboard showing relationship slots used/available +- Complexity: **Low** — validation logic on existing rNetwork connection flows + +--- + +## Gap 5: Anti-Gaming / Rate Limiting (Medium Priority) + +**MEA Requirement:** The protocol includes anti-gaming measures: transaction volume +caps, burst detection, relationship cycling detection, and Sybil resistance. + +**What's Missing:** +- Per-participant transaction volume caps (daily/weekly) +- Burst detection (unusual transaction patterns) +- Relationship cycling detection (forming/dissolving relationships to game the gradient) +- Sybil resistance (one-person-many-pods exploitation) + +**Suggested Approach:** +- New module `rIntegrity` or extension to rGradient +- Transaction volume tracking with configurable thresholds +- Anomaly detection on relationship graph changes +- Sybil detection via EncryptID's device-binding (one passkey = one device = one identity signal) +- Complexity: **Medium** — the rules are specified; the detection heuristics need tuning + +--- + +## Gap 6: Pod Lifecycle State Machine (Low Priority) + +**MEA Requirement:** Pods have formal lifecycle states: +`forming → active → dividing → dissolved` + +**What's Missing:** +- State field on Spaces +- State transition rules (who can trigger, what conditions) +- Dissolved state handling (archive, read-only access to history) + +**Suggested Approach:** +- State field in Space metadata +- Transition validation in Space management flows +- Dissolved = read-only mode (Automerge doc frozen) +- Complexity: **Low** + +--- + +## Gap 7: Native Mobile Shell (Low Priority for MVP) + +**MEA Requirement:** Mobile-first UX designed for low-bandwidth, small-screen +environments (the "Dharavi standard"). + +**What's Missing:** +- rSpace is currently web-first (responsive but not native mobile) +- No offline-capable mobile app wrapper + +**Suggested Approach:** +- Capacitor or React Native wrapper around the existing web app +- Service worker for offline caching (partially exists) +- SQLite adapter for Automerge (replacing IndexedDB on mobile) +- Complexity: **High** — but not blocking for web-based MEA pilot + +--- + +## Implementation Roadmap Suggestion + +### Phase 1: MEA Configuration Layer (1–2 weeks) +- Pod level taxonomy (L0–L5 type field) +- Member caps per level +- Relationship capacity constraints +- Pod lifecycle state machine +- *All low-complexity, configuration-level changes* + +### Phase 2: Exchange Gradient (2–3 weeks) +- Pod relationship graph materialization +- Distance calculation service +- Rate calculation function +- Integration with rExchange / rWallet payment flows +- Rate display in transaction UX + +### Phase 3: Mitosis Protocol (2–3 weeks) +- Threshold monitoring +- Governance-triggered division flow +- Automated pod split (new Space creation, member reassignment) +- Post-mitosis relationship establishment + +### Phase 4: Integrity & Anti-Gaming (2–3 weeks) +- Transaction volume caps +- Burst / anomaly detection +- Relationship cycling detection +- Dashboard / alerts + +### Phase 5: Mobile Shell (4–6 weeks, can run in parallel) +- Capacitor wrapper +- Offline-first optimizations +- Low-bandwidth UX adaptations + +--- + +## Effort Summary + +| Gap | Priority | Complexity | Estimated Effort | +|---|---|---|---| +| Exchange Gradient Engine | High | Medium | 2–3 weeks | +| Pod Mitosis Protocol | High | Medium-High | 2–3 weeks | +| Pod Level Taxonomy & Caps | Medium | Low | 2–3 days | +| Relationship Capacity | Medium | Low | 2–3 days | +| Anti-Gaming | Medium | Medium | 2–3 weeks | +| Pod Lifecycle States | Low | Low | 1–2 days | +| Native Mobile Shell | Low (MVP) | High | 4–6 weeks | + +**Total new development: ~8–12 weeks** to bring rSpace from current state to +full MEA protocol compliance, with the first usable MEA pilot possible after +Phase 2 (~4–5 weeks). diff --git a/analysis/mea-rspace-alignment.md b/analysis/mea-rspace-alignment.md new file mode 100644 index 0000000..73e37f9 --- /dev/null +++ b/analysis/mea-rspace-alignment.md @@ -0,0 +1,192 @@ +# 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.