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 <noreply@anthropic.com>
This commit is contained in:
commit
573fe60816
|
|
@ -0,0 +1,5 @@
|
|||
.env
|
||||
.DS_Store
|
||||
*.swp
|
||||
*.swo
|
||||
node_modules/
|
||||
Binary file not shown.
|
|
@ -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.
|
||||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue