rSpace-website/docs/R-ECOSYSTEM-ARCHITECTURE.md

1030 lines
63 KiB
Markdown

# r-Ecosystem Architecture
> Digital Collaboration Spaces as Public Goods
**Version**: 0.1.0 (Draft)
**Last Updated**: December 2024
**Status**: Vision Document
---
## Table of Contents
1. [Executive Summary](#executive-summary)
2. [Core Vision](#core-vision)
3. [Domain Portfolio](#domain-portfolio)
4. [Module Architecture](#module-architecture)
5. [Technical Foundation](#technical-foundation)
6. [Governance Primitives](#governance-primitives)
7. [Implementation Roadmap](#implementation-roadmap)
8. [Open Questions](#open-questions)
---
## Executive Summary
The r-Ecosystem is a suite of interoperable, local-first, privacy-preserving tools for digital collaboration. Each tool is:
- **A standalone public good** (usable at its own domain)
- **An embeddable module** (composable within any rSpace community)
- **Built on shared infrastructure** (CRDT sync, zk privacy, common data model)
The goal is to provide communities with the digital infrastructure for **collective agency** - the ability to coordinate time, space, money, work, and decisions without relying on corporate platforms or trusting central authorities.
---
## Core Vision
### The Problem
The legacy internet has become a collection of walled gardens:
- **Your data is commodified** - you are the product
- **Your attention is sold** - engagement metrics over human flourishing
- **Your privacy is an illusion** - surveillance capitalism is the business model
- **Your communities are platform-dependent** - Discord can ban you, Slack can raise prices
### The Solution
rSpace and the r-Ecosystem provide:
- **Local-first data** - your data lives on your devices, syncs when connected
- **Zero-knowledge privacy** - encryption by default, selective disclosure via zk proofs
- **Community ownership** - your space, your rules, your data
- **Interoperability** - modules compose together, communities can federate
### The Insight
What we're building is **infrastructure for the commons** - tools that enable collective action without requiring trust in a central party. This serves:
| Community Type | What They Need |
|----------------|----------------|
| Housing Co-ops | Shared expenses, meeting scheduling, maintenance coordination |
| Worker Co-ops | Governance, profit sharing, role rotation |
| Mutual Aid Networks | Resource pooling, need matching, volunteer coordination |
| Community Land Trusts | Participatory budgeting, land stewardship |
| Research Collectives | Grant management, contribution tracking |
| Neighborhood Associations | Local issue tracking, volunteer hours, event planning |
| DAOs (with good UX) | All of the above, plus on-chain settlement |
---
## Domain Portfolio
### Primary Modules
| Domain | Module | Layer | Core Function |
|--------|--------|-------|---------------|
| **rspace.online** | rSpace | Platform | Community space generator - the container |
| **rwallet.online** | rWallet | Economic | Treasury, shared funds, group economics |
| **rfunds.online** | rFunds | Economic | Campaigns, crowdfunding, matching pools |
| **rmaps.online** | rMaps | Spatial | Collaborative mapping, asset tracking, bioregions |
| **rcalendar.online** | rCalendar | Temporal | Event scheduling, availability, booking |
| **rtime.space** | rTime | Spatio-temporal | Time + Space fusion, possibility cones, timebanking |
| **rrules.online** | rRules | Governance | Constitution, roles, permissions, constraints |
| **rvote.online** | rVote | Governance | Decisions, elections, delegation, results |
| **rdemocracy.online** | rDemocracy | Governance | Deliberation, discussion, synthesis, consent |
| **rwork.online** | rWork | Labor | Tasks, projects, contributions, bounties |
| **rinbox.online** | rInbox | Communication | Secure messaging, threads, announcements |
| **rdata.online** | rData | Infrastructure | Schemas, storage, queries, exports |
| **rnetwork.online** | rNetwork | Infrastructure | Federation, discovery, cross-community |
| **rstack.online** | rStack | Infrastructure | APIs, SDKs, developer documentation |
| **rtube.online** | rTube | Media | Video hosting, recordings, streams |
### Redirect Domains
| Domain | Redirects To | Reason |
|--------|--------------|--------|
| r-space.online | rspace.online | Hyphen variant |
| rcal.online | rcalendar.online | Short alias |
| rtube.space | rtube.online | TLD variant |
### Deprecated/Redundant
| Domain | Recommendation | Reason |
|--------|----------------|--------|
| rgov.online | Redirect to rspace.online/governance | Too generic - covered by rRules + rVote + rDemocracy |
| rplans.online | Redirect to rcalendar.online or rwork.online | Ambiguous - split across other modules |
### Specialty/Niche (Optional)
| Domain | Use Case | Decision |
|--------|----------|----------|
| rtrips.online | Travel group coordination | Build if demand exists |
---
## Module Architecture
### Layer Overview
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ rSpace.online │
│ Digital Collaboration Space Generator │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ECONOMIC LAYER │
│ ├── rWallet.online - Treasury, multi-sig, streaming payments │
│ └── rFunds.online - Campaigns, grants, quadratic funding, matching │
│ │
│ SPATIAL LAYER │
│ └── rMaps.online - Locations, assets, bioregions, collaborative annotation │
│ │
│ TEMPORAL LAYER │
│ └── rCalendar.online - Events, scheduling, availability, booking │
│ │
│ SPATIO-TEMPORAL FUSION │
│ └── rTime.space - Possibility cones, timebanking, when+where unified │
│ │
│ GOVERNANCE LAYER │
│ ├── rRules.online - Constitution, roles, permissions, amendments │
│ ├── rVote.online - Decisions, mechanisms, delegation, results │
│ └── rDemocracy.online - Deliberation, synthesis, facilitation │
│ │
│ LABOR LAYER │
│ └── rWork.online - Tasks, projects, skills, bounties, contributions │
│ │
│ COMMUNICATION LAYER │
│ ├── rInbox.online - Secure messaging, threads, digests │
│ └── rTube.online - Video, recordings, streams, transcripts │
│ │
│ INFRASTRUCTURE LAYER │
│ ├── rData.online - Schemas, storage, queries, privacy controls │
│ ├── rNetwork.online - Federation, discovery, credentials │
│ └── rStack.online - APIs, SDKs, documentation, marketplace │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
---
### Economic Layer
#### rWallet.online - Group Treasury
**Purpose**: Enable groups to manage shared resources without trusting a central party.
```
┌─────────────────────────────────────────────────────────────────┐
│ rWallet.online │
│ Community Treasury │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Treasury Types: │
│ ├── Simple Pool (anyone can deposit, rules for withdrawal) │
│ ├── Multi-sig (N-of-M approval required) │
│ ├── Threshold (BLS signatures, no single key exists) │
│ └── Programmable (smart-contract-like rules, local execution) │
│ │
│ Allocation Mechanisms: │
│ ├── Direct allocation (treasurer assigns) │
│ ├── Proposal-based (vote on spending) │
│ ├── Streaming (continuous payments over time) │
│ └── Conditional (release on milestone completion) │
│ │
│ Account Modes: │
│ ├── Internal accounting (track who owes what, no real money) │
│ ├── Fiat integration (Stripe, bank accounts) │
│ └── Crypto integration (stablecoins, L2s) │
│ │
│ Privacy Features: │
│ ├── zk-Contributions (prove you contributed without amount) │
│ ├── Selective transparency (choose what's public) │
│ └── Audit trails (verifiable history) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
#### rFunds.online - Fundraising & Matching
**Purpose**: Run campaigns and coordinate collective funding.
```
┌─────────────────────────────────────────────────────────────────┐
│ rFunds.online │
│ Collective Fundraising │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Campaign Types: │
│ ├── Crowdfunding (goal-based, all-or-nothing optional) │
│ ├── Grants (application + review workflow) │
│ ├── Matching Rounds (QF, retroactive, conviction) │
│ └── Subscriptions (recurring community support) │
│ │
│ Funding Mechanisms: │
│ ├── Quadratic Funding (small contributions amplified) │
│ ├── Conviction Voting (time-weighted preference) │
│ ├── Retroactive Funding (reward proven value) │
│ ├── Milestone-based (funds released on completion) │
│ └── Rage Quit (contributors can exit before deadline) │
│ │
│ Integration: │
│ ├── rWallet → successful campaigns deposit to treasury │
│ ├── rRules → who can create campaigns, approval flow │
│ ├── rVote → community decides on matching allocations │
│ └── rNetwork → cross-community matching pools │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### Spatial Layer
#### rMaps.online - Collaborative Mapping
**Purpose**: Collaborative understanding and annotation of place.
```
┌─────────────────────────────────────────────────────────────────┐
│ rMaps.online │
│ Spatial Intelligence │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Layer Types: │
│ ├── Asset Maps (community resources, shared tools, skills) │
│ ├── Event Maps (where things are happening) │
│ ├── Memory Maps (historical, narrative layers) │
│ ├── Bioregional Maps (watersheds, ecosystems, foodsheds) │
│ └── Proposal Maps (planned changes, zoning alternatives) │
│ │
│ Collaboration Features: │
│ ├── Collaborative Annotation (pins, polygons, paths) │
│ ├── Layer Permissions (who can edit which layers) │
│ ├── Version History (see how the map evolved) │
│ └── Conflict Resolution (overlapping claims) │
│ │
│ Privacy Features: │
│ ├── Fuzzy Location (area rather than point) │
│ ├── Ephemeral Sharing (location expires after event) │
│ └── zk-Proximity (prove you're nearby without exact location) │
│ │
│ Integration: │
│ ├── rCalendar → event locations │
│ ├── rTime.space → spatio-temporal queries │
│ ├── rWallet → location-based allocation, local currency zones │
│ └── rWork → where tasks need to happen │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### Temporal Layer
#### rCalendar.online - Time Coordination
**Purpose**: Coordinate time across a group without a central arbiter.
```
┌─────────────────────────────────────────────────────────────────┐
│ rCalendar.online │
│ Temporal Coordination │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Event Types: │
│ ├── Proposals (times seeking consensus) │
│ ├── Committed (locked in, affects availability) │
│ ├── Recurring (patterns with exception handling) │
│ └── Conditional (triggers based on other events/state) │
│ │
│ Coordination Features: │
│ ├── Availability Aggregation (when can we all meet?) │
│ ├── Resource Booking (shared spaces, equipment) │
│ ├── RSVP Management (invited, attending, declined) │
│ └── Deadline Tracking (countdown, reminders) │
│ │
│ Privacy Features: │
│ ├── Busy/Free only (hide event details) │
│ ├── Ring Availability (appear free to subset) │
│ └── zk-Attendance (prove you attended without revealing when) │
│ │
│ Integration: │
│ ├── rMaps → location for events │
│ ├── rTime.space → spatio-temporal fusion │
│ ├── rWallet → booking fees, event budgets │
│ └── rWork → task deadlines, sprint planning │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### Spatio-Temporal Fusion
#### rTime.space - Possibility Cones & Beyond
**Purpose**: Unify space and time into a coherent coordination substrate, enabling novel forms of collective planning.
```
┌─────────────────────────────────────────────────────────────────┐
│ rTime.space │
│ Spatio-Temporal Coordination Fusion │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CORE CONCEPT: POSSIBILITY CONES │
│ ════════════════════════════════ │
│ │
│ A "possibility cone" represents where a person/resource │
│ COULD BE at future times, given their current location │
│ and movement constraints. │
│ │
│ Future │
│ △ │
│ /│\ │
│ / │ \ ← Possibility expands with time │
│ / │ \ │
│ / │ \ │
│ / │ \ │
│ ▔▔▔▔▔▔▔▔▔▔▔▔▔ │
│ NOW │
│ (current location) │
│ │
│ When cones OVERLAP = coordination is possible │
│ When cones DON'T overlap = physically impossible to meet │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ FEATURES: │
│ │
│ Possibility Cone Queries: │
│ ├── "When/where can Alice and Bob BOTH be?" │
│ ├── "Who could reach the community center by 3pm?" │
│ ├── "What's the earliest we could all meet downtown?" │
│ └── "Visualize everyone's cones on the map" │
│ │
│ Travel-Aware Scheduling: │
│ ├── Automatic travel time calculation between events │
│ ├── Conflict detection with spatial awareness │
│ ├── Route optimization for multiple stops │
│ └── "Leave now" notifications based on destination │
│ │
│ Time Banking Integration: │
│ ├── Track time contributions (volunteer hours) │
│ ├── Time as currency (mutual credit) │
│ ├── Skill-weighted time (specialist hours) │
│ └── Commitment tracking (promised future time) │
│ │
│ Collective Futures Visualization: │
│ ├── Aggregate possibility cones for groups │
│ ├── "When could ALL of us be together?" │
│ ├── Retreat/gathering planning with spatial constraints │
│ └── Carpool/rideshare coordination │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ VIEW MODES: │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ MAP + TIME │ │ CONE OVERLAY │ │ TIMELINE + │ │
│ │ SLIDER │ │ VIEW │ │ LOCATION │ │
│ │ │ │ │ │ │ │
│ │ Scrub through │ │ See everyone's │ │ Horizontal │ │
│ │ time to see │ │ possibility │ │ time axis │ │
│ │ who's where │ │ cones expand │ │ with map │ │
│ │ when │ │ into the │ │ thumbnails │ │
│ │ │ │ future │ │ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ INTEGRATION: │
│ ├── rMaps → spatial data, locations, distances │
│ ├── rCalendar → temporal data, events, availability │
│ ├── rWallet → time credits, compensation for time │
│ ├── rWork → task time estimates, scheduling │
│ └── rNetwork → cross-community coordination │
│ │
└─────────────────────────────────────────────────────────────────┘
```
**Why rTime.space is distinct from rMaps + rCalendar:**
| Module | Primary Dimension | Core Question |
|--------|-------------------|---------------|
| rMaps | Space | "Where is everything?" |
| rCalendar | Time | "When is everything?" |
| rTime.space | Spacetime | "What's possible given space AND time?" |
rTime.space doesn't replace the other two - it provides a **fusion layer** that enables queries and visualizations that neither can do alone.
---
### Governance Layer
#### rRules.online - Constitutional Framework
**Purpose**: Define and maintain the operating system of the community.
```
┌─────────────────────────────────────────────────────────────────┐
│ rRules.online │
│ Constitutional Framework │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Visual Constitution Editor: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ IF [proposal type] = "budget > $1000" │ │
│ │ THEN [decision] = "supermajority (66%)" │ │
│ │ WITH [constraints]: │ │
│ │ - quorum: 50% of active members │ │
│ │ - voting period: 7 days │ │
│ │ - veto: treasurer can block (override: 75%) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Rule Categories: │
│ ├── Membership (who can join, how, exit rights) │
│ ├── Roles (creation, assignment, permissions, terms) │
│ ├── Decisions (mechanisms per decision type) │
│ ├── Resources (allocation rules, spending limits) │
│ ├── Amendments (how to change these rules) │
│ └── Dissolution (what happens if community ends) │
│ │
│ Templates: │
│ ├── Housing Co-op (consensus, maintenance, reserves) │
│ ├── Worker Co-op (profit sharing, hiring, firing) │
│ ├── DAO (token-weighted, delegation, rage quit) │
│ ├── Club (simple majority, dues, events) │
│ └── Research Collective (contribution tracking, IP) │
│ │
│ Version Control: │
│ ├── Every rule change tracked │
│ ├── Diff view for proposed amendments │
│ └── Historical audit trail │
│ │
└─────────────────────────────────────────────────────────────────┘
```
#### rVote.online - Decision Engine
**Purpose**: Make and record collective choices.
```
┌─────────────────────────────────────────────────────────────────┐
│ rVote.online │
│ Decision Engine │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Voting Mechanisms: │
│ ├── Simple Majority (>50%) │
│ ├── Supermajority (66%, 75%, configurable) │
│ ├── Quadratic Voting (voice credits, preference depth) │
│ ├── Conviction Voting (time-weighted continuous signal) │
│ ├── Ranked Choice (instant runoff) │
│ ├── Approval Voting (vote for all acceptable options) │
│ └── Consent (proceed unless blocking objection) │
│ │
│ Delegation: │
│ ├── Liquid Democracy (delegate your vote) │
│ ├── Domain-specific delegation (different delegate per topic) │
│ ├── Transitive delegation (your delegate can re-delegate) │
│ └── Instant recall (take back your delegation anytime) │
│ │
│ Privacy: │
│ ├── Open voting (see who voted how) │
│ ├── Sealed voting (hidden until reveal phase) │
│ ├── zk-voting (verify without revealing individual votes) │
│ └── Anonymous voting (no one knows who voted how) │
│ │
│ Lifecycle: │
│ ├── Draft → Under Review → Open for Voting → Closed → Result │
│ ├── Quorum requirements │
│ ├── Time limits │
│ └── Result certification │
│ │
└─────────────────────────────────────────────────────────────────┘
```
#### rDemocracy.online - Deliberative Space
**Purpose**: Facilitate understanding before deciding.
```
┌─────────────────────────────────────────────────────────────────┐
│ rDemocracy.online │
│ Deliberative Space │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Discussion Features: │
│ ├── Threaded discussions with synthesis │
│ ├── Argument mapping (pro/con/nuance visualization) │
│ ├── Temperature checks (non-binding sentiment) │
│ ├── Perspective gathering (ensure all voices heard) │
│ └── AI-assisted summarization of positions │
│ │
│ Facilitation Tools: │
│ ├── Speaking queue (fair turn-taking) │
│ ├── Time limits (prevent filibustering) │
│ ├── Check-ins / go-rounds (hear from everyone) │
│ ├── Breakout groups (small group discussions) │
│ └── Consent rounds (identify blocking concerns) │
│ │
│ Synthesis: │
│ ├── Collaborative document editing │
│ ├── Option generation (brainstorm alternatives) │
│ ├── Convergence tracking (are we getting closer?) │
│ └── Ready-for-vote signal (community sentiment) │
│ │
│ Anti-patterns it prevents: │
│ ├── Voting before understanding │
│ ├── Loudest voice wins │
│ ├── Binary framing of complex issues │
│ └── Premature closure │
│ │
│ Flow: rDemocracy (deliberate) → rVote (decide) → rRules (codify)│
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### Labor Layer
#### rWork.online - Contribution Tracking
**Purpose**: Coordinate who does what and track contributions.
```
┌─────────────────────────────────────────────────────────────────┐
│ rWork.online │
│ Contribution Tracking │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Task Management: │
│ ├── Task creation with descriptions │
│ ├── Assignee management │
│ ├── Status tracking (open, claimed, in progress, done) │
│ ├── Dependencies (task A blocks task B) │
│ └── Priority and tags │
│ │
│ Project Coordination: │
│ ├── Project containers (group related tasks) │
│ ├── Milestones │
│ ├── Kanban / board views │
│ └── Sprint planning │
│ │
│ Contribution Recognition: │
│ ├── Skill registry (what can people do?) │
│ ├── Contribution history (what have people done?) │
│ ├── Peer recognition (kudos, thanks) │
│ └── Reputation building │
│ │
│ Bounties: │
│ ├── Open bounties (anyone can claim) │
│ ├── Assigned bounties (specific person) │
│ ├── Competitive bounties (multiple submissions) │
│ └── Retroactive bounties (reward after the fact) │
│ │
│ Integration: │
│ ├── rWallet → bounty payments, expense reimbursement │
│ ├── rTime.space → time tracking for tasks │
│ ├── rCalendar → task deadlines, sprint events │
│ └── rRules → who can create tasks, assign bounties │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### Communication Layer
#### rInbox.online - Secure Messaging
**Purpose**: Private, secure communication within and across communities.
```
┌─────────────────────────────────────────────────────────────────┐
│ rInbox.online │
│ Secure Communications │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Channel Types: │
│ ├── Announcements (one-to-many, role-gated posting) │
│ ├── Discussions (threaded, topic-based) │
│ ├── Direct Messages (E2EE, ephemeral option) │
│ └── Digests (summarized updates, configurable frequency) │
│ │
│ Features: │
│ ├── E2EE by default (Signal protocol or similar) │
│ ├── Offline-first (sync when connected) │
│ ├── Reactions & threading │
│ ├── Mentions & notifications │
│ └── Search (local index, never sent to server) │
│ │
│ Anti-Features (by design): │
│ ├── No read receipts (unless opted in) │
│ ├── No typing indicators │
│ ├── No "last seen" tracking │
│ └── No algorithmic prioritization │
│ │
│ Integration: │
│ ├── rRules → proposal notifications, voting reminders │
│ ├── rCalendar → event reminders, RSVP requests │
│ ├── rWallet → payment requests, budget alerts │
│ └── rWork → task assignments, bounty announcements │
│ │
└─────────────────────────────────────────────────────────────────┘
```
#### rTube.online - Community Media
**Purpose**: Video hosting and streaming for community use.
```
┌─────────────────────────────────────────────────────────────────┐
│ rTube.online │
│ Community Media │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Content Types: │
│ ├── Meeting recordings (auto-transcribed, indexed) │
│ ├── Educational content (tutorials, onboarding) │
│ ├── Announcements (video updates from leadership) │
│ └── Events (live streams, archived) │
│ │
│ Features: │
│ ├── E2EE video (members-only content) │
│ ├── Transcription & search │
│ ├── Clip creation (share highlights) │
│ ├── Collaborative annotation │
│ └── Bandwidth-aware (quality adaptation) │
│ │
│ Privacy: │
│ ├── No external tracking │
│ ├── View counts optional │
│ ├── Consent management for recordings │
│ └── Automatic expiration options │
│ │
│ Integration: │
│ ├── rCalendar → auto-record scheduled meetings │
│ ├── rInbox → video message threads │
│ └── rData → video metadata, transcripts searchable │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### Infrastructure Layer
#### rData.online - Community Data Layer
**Purpose**: Structured data storage with privacy controls.
```
┌─────────────────────────────────────────────────────────────────┐
│ rData.online │
│ Community Data Layer │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Data Types: │
│ ├── Structured (tables, forms, surveys) │
│ ├── Documents (collaborative writing) │
│ ├── Files (shared storage, version controlled) │
│ └── Streams (real-time data feeds) │
│ │
│ Capabilities: │
│ ├── Schema definition (define your data structures) │
│ ├── Views & queries (filter, sort, aggregate) │
│ ├── Import/export (CSV, JSON, standard formats) │
│ ├── Computed fields (formulas, derivations) │
│ └── Inter-community sharing (federation queries) │
│ │
│ Privacy Controls: │
│ ├── Per-field visibility (public/members/roles) │
│ ├── Aggregated only (share stats, not records) │
│ ├── zk-queries (prove facts without revealing data) │
│ └── Data retention rules (auto-expire sensitive data) │
│ │
└─────────────────────────────────────────────────────────────────┘
```
#### rNetwork.online - Federation & Discovery
**Purpose**: Connect communities together.
```
┌─────────────────────────────────────────────────────────────────┐
│ rNetwork.online │
│ Federation & Discovery │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Federation Features: │
│ ├── Cross-community proposals (joint decisions) │
│ ├── Shared funding pools (matching across communities) │
│ ├── Resource sharing (borrow/lend between groups) │
│ ├── Credential portability (reputation travels) │
│ └── Federated search (find across the network) │
│ │
│ Discovery: │
│ ├── Public directory (opt-in community listings) │
│ ├── Topic/interest tags │
│ ├── Geographic proximity │
│ └── Network graph (communities connected to yours) │
│ │
│ Trust & Verification: │
│ ├── Community attestations ("we vouch for them") │
│ ├── Shared member verification │
│ ├── Cross-community moderation │
│ └── Dispute resolution protocols │
│ │
└─────────────────────────────────────────────────────────────────┘
```
#### rStack.online - Developer Platform
**Purpose**: Enable developers to build on the r-Ecosystem.
```
┌─────────────────────────────────────────────────────────────────┐
│ rStack.online │
│ Developer Platform │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Documentation: │
│ ├── API reference (all modules) │
│ ├── SDK guides (JavaScript, Python, etc.) │
│ ├── Protocol specs (CRDT schemas, sync protocol) │
│ └── Self-hosting guides │
│ │
│ Module Marketplace: │
│ ├── Official modules (rWallet, rCalendar, etc.) │
│ ├── Community modules (third-party extensions) │
│ ├── Templates (pre-configured community types) │
│ └── Integrations (bridges to external services) │
│ │
│ Developer Tools: │
│ ├── Local dev environment │
│ ├── Testing framework │
│ ├── Module scaffolding CLI │
│ └── Simulation tools (test governance scenarios) │
│ │
│ Open Source: │
│ ├── All core modules MIT/Apache licensed │
│ ├── Protocol specifications open │
│ └── Reference implementations │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## Technical Foundation
### Local-First Architecture
```
┌─────────────────────────────────────────────────────────────────┐
│ User's Device (Browser) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ Application Layer ││
│ │ rSpace UI + embedded modules (rWallet, rCalendar, etc.) ││
│ └───────────────────────────┬─────────────────────────────────┘│
│ │ │
│ ┌───────────────────────────▼─────────────────────────────────┐│
│ │ State Management ││
│ │ ││
│ │ ┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ ││
│ │ │ Yjs/ │ │ SQLite/ │ │ zk Circuits │ ││
│ │ │ Automerge │ │ IndexedDB │ │ (snarkjs) │ ││
│ │ │ (CRDTs) │ │ (storage) │ │ │ ││
│ │ └──────┬──────┘ └──────┬───────┘ └────────┬────────┘ ││
│ │ │ │ │ ││
│ │ └─────────────────┴──────────┬──────────┘ ││
│ └───────────────────────────────────────┼──────────────────────┘│
│ │ │
│ ┌───────────────────────────────────────▼──────────────────────┐│
│ │ Sync Layer ││
│ │ ││
│ │ [WebRTC Direct] ←→ [WebSocket Relay] ←→ [libp2p/Matrix] ││
│ │ ││
│ │ Encrypted payloads only leave device ││
│ │ Sync servers never see plaintext ││
│ │ ││
│ └───────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────┘
```
### Recommended Tech Stack
| Layer | Technology | Rationale |
|-------|------------|-----------|
| **Sync & CRDT** | Yjs | Mature, well-supported, used by Notion/Tldraw |
| **Storage** | IndexedDB via Dexie.js | Better ergonomics than raw IndexedDB |
| **Networking** | y-webrtc + y-websocket | P2P when possible, relay fallback |
| **Cryptography** | libsodium.js | Fast, audited, E2EE primitives |
| **zk Proofs** | snarkjs + circom | Most mature in browser |
| **UI Framework** | Next.js + React + folkjs | Already in use, HTML as computing substrate |
### Unified State Model
Every rSpace community has a single CRDT document tree:
```
community-abc/
├── meta/ # Community metadata
├── members/ # Membership registry
├── rules/ # rRules - governance constitution
├── wallet/ # rWallet - economic layer
│ └── campaigns/ # rFunds - fundraising
├── spatial/ # rMaps - locations, assets, layers
├── temporal/ # rCalendar - events, availability
├── spacetime/ # rTime.space - fused queries, possibility cones
├── governance/ # rVote + rDemocracy
│ ├── discussions/ # Deliberation threads
│ ├── proposals/ # Formal proposals
│ └── decisions/ # Ratified decisions
├── work/ # rWork - tasks, time logs, skills
├── messages/ # rInbox - channels, threads
└── data/ # rData - arbitrary structured data
```
### Cross-Module References
Modules link to each other via references:
```typescript
interface Event {
id: string;
title: string;
when: { start: DateTime; end: DateTime; };
where?: { place_id: string; }; // → spatial/places/
links: {
wallet_item?: string; // → wallet/transactions/
proposal?: string; // → governance/proposals/
task?: string; // → work/tasks/
};
}
```
---
## Governance Primitives
### Decision Mechanisms Library
| Mechanism | Best For | Trade-offs |
|-----------|----------|------------|
| **Simple Majority** | Quick, low-stakes decisions | Can ignore minority |
| **Supermajority** | High-stakes, irreversible decisions | Can be hard to reach |
| **Quadratic Voting** | Expressing preference intensity | Complex, requires voice credits |
| **Conviction Voting** | Continuous, evolving preferences | Slow, favors patient actors |
| **Ranked Choice** | Elections, multiple options | Complex to understand |
| **Approval Voting** | Find broadly acceptable option | Doesn't capture preference depth |
| **Consent** | Collaborative, aligned groups | Requires trust, can be slow |
### Role Systems
| Pattern | Description | Use Case |
|---------|-------------|----------|
| **Static Roles** | Fixed admin/member/observer | Simple organizations |
| **Rotating Roles** | Term limits, sortition | Prevent power concentration |
| **Earned Roles** | Contribution-gated access | Merit-based organizations |
| **Delegated Roles** | Representatives chosen by members | Scalable governance |
| **Contextual Roles** | Different roles per domain | Complex organizations |
### Constraint Patterns
| Constraint | Purpose | Example |
|------------|---------|---------|
| **Time Locks** | Cooling off periods | 48 hours between proposal and vote |
| **Quorum** | Minimum participation | 50% of members must vote |
| **Veto Rights** | Minority protection | Treasurer can block spending |
| **Constitutional Limits** | Protect fundamentals | Changing membership rules needs 75% |
| **Exit Rights** | Freedom to leave | Can withdraw your contributed funds |
---
## Implementation Roadmap
### Phase 1: Foundation (Months 1-4)
**Goal**: Local-first sync infrastructure + basic rSpace container
- [ ] CRDT-based sync working in browser (Yjs)
- [ ] Basic rSpace container (create community, invite members)
- [ ] Simple permissions (admin, member)
- [ ] Works offline, syncs when connected
- [ ] Basic UI shell
**Domains Active**: rspace.online
### Phase 2: Economic Layer (Months 5-7)
**Goal**: rWallet MVP + basic rFunds
- [ ] Treasury tracking (internal accounting mode)
- [ ] Simple proposals with majority voting
- [ ] Transaction history
- [ ] Basic multi-sig (N-of-M approval)
- [ ] Simple crowdfunding campaigns
**Domains Active**: rspace.online, rwallet.online, rfunds.online
### Phase 3: Spatio-Temporal Layer (Months 8-10)
**Goal**: rMaps, rCalendar, rTime.space MVPs
- [ ] Shared calendars with events
- [ ] Availability aggregation
- [ ] Collaborative map annotation
- [ ] Asset tracking on maps
- [ ] Basic possibility cone queries
- [ ] Time banking (hour tracking)
**Domains Active**: + rmaps.online, rcalendar.online, rtime.space
### Phase 4: Governance Layer (Months 11-14)
**Goal**: rRules, rVote, rDemocracy
- [ ] Pluggable decision mechanisms
- [ ] Role system with permissions
- [ ] Visual constitution editor
- [ ] Deliberation threads with synthesis
- [ ] Basic liquid democracy
**Domains Active**: + rrules.online, rvote.online, rdemocracy.online
### Phase 5: Labor + Communication (Months 15-17)
**Goal**: rWork, rInbox
- [ ] Task management
- [ ] Contribution tracking
- [ ] Bounty system
- [ ] E2EE messaging
- [ ] Threaded discussions
**Domains Active**: + rwork.online, rinbox.online
### Phase 6: Infrastructure + zk Privacy (Months 18-22)
**Goal**: rData, rNetwork, rStack + privacy features
- [ ] Formal data layer
- [ ] Federation between communities
- [ ] Developer API + SDK
- [ ] zk voting
- [ ] zk contributions
- [ ] Credential verification
**Domains Active**: + rdata.online, rnetwork.online, rstack.online
### Phase 7: Media + Polish (Months 23-24)
**Goal**: rTube + ecosystem maturity
- [ ] Video hosting
- [ ] Meeting recordings
- [ ] Transcription
- [ ] Cross-module polish
- [ ] Performance optimization
**Domains Active**: + rtube.online
---
## Open Questions
### Technical
- [ ] Which CRDT library? (Yjs vs Automerge)
- [ ] Self-hosted relay infrastructure or use existing (Matrix)?
- [ ] Which zk proving system? (snarkjs, Noir, RISC Zero)
- [ ] Mobile apps or PWA-only?
### Product
- [ ] Freemium model or purely community-funded?
- [ ] Which community types to prioritize first?
- [ ] How much customization vs opinionated defaults?
### Governance
- [ ] How is the r-Ecosystem itself governed?
- [ ] Who decides on protocol changes?
- [ ] How to prevent capture by well-funded actors?
### Legal
- [ ] What legal structure for the project?
- [ ] How to handle money transmission regulations (rWallet)?
- [ ] Privacy regulation compliance (GDPR, etc.)?
---
## Related Resources
### Conceptual Foundations
- [Ink & Switch: Local-First Software](https://www.inkandswitch.com/local-first/)
- [RadicalxChange: Governance Primitives](https://www.radicalxchange.org/)
- [Ostrom's Principles for Commons Governance](https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principles_for_Common_Pool_Resource_(CPR)_institution)
### Technical References
- [Yjs Documentation](https://docs.yjs.dev/)
- [CRDTs: The Hard Parts](https://www.youtube.com/watch?v=x7drE24geUw)
- [snarkjs/circom](https://docs.circom.io/)
### Related Projects
- [Loomio](https://www.loomio.org/) - Collaborative decision-making
- [Open Collective](https://opencollective.com/) - Transparent fundraising
- [Gitcoin](https://gitcoin.co/) - Quadratic funding
- [Colony](https://colony.io/) - DAO infrastructure
---
## Changelog
- **2024-12-12**: Initial draft created