melton-fdn/analysis/gap-analysis.md

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