63 KiB
63 KiB
r-Ecosystem Architecture
Digital Collaboration Spaces as Public Goods
Version: 0.1.0 (Draft) Last Updated: December 2024 Status: Vision Document
Table of Contents
- Executive Summary
- Core Vision
- Domain Portfolio
- Module Architecture
- Technical Foundation
- Governance Primitives
- Implementation Roadmap
- 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:
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
- RadicalxChange: Governance Primitives
- Ostrom's Principles for Commons Governance
Technical References
Related Projects
- Loomio - Collaborative decision-making
- Open Collective - Transparent fundraising
- Gitcoin - Quadratic funding
- Colony - DAO infrastructure
Changelog
- 2024-12-12: Initial draft created