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