This document defines the functional specifications for the Exonomy and Exocracy ecosystem, a decentralized, peer-to-peer platform designed to facilitate voucher-based economic interactions and community-driven project management. Exonomy aims to establish a decentralized platform for voucher-based exchanges, fostering trust and economic resilience. The platform leverages decentralized P2P technology, primarily OrbitDB built upon IPFS, as its core communication and data persistence infrastructure, ensuring offline-first operations, selective data replication, and decentralized governance triggers.
This document outlines the architecture, workflows, governance, and technical details of both Exonomy and Exocracy. It emphasizes asset autonomy, selective replication, and consensus mechanisms to promote trust, local economic resilience, and community impact.
- Exonomy: Peer-to-peer exchange of vouchers representing specific goods/services. Hosted within the Exonomy controller app via modules like 'Vallet' (wallet) and 'vBay' (marketplace).
- Exocracy: Collaborative task management with hierarchical potential and community oversight, hosted as a module within the Exonomy controller app.
- Key Principles:
- Voucher Primacy: Value anchored to tangible goods/services, valued in fiat.
- Selective Replication: Data propagates based on interactions, follows, and project membership via OrbitDB mechanisms.
- Contextual Consensus: Critical actions require agreement (often unanimous) from relevant community members within a specific scope (e.g., task completion).
- Decentralized Infrastructure: Utilize OrbitDB's CRDT-based synchronization capabilities over IPFS to minimize dependency on central servers for core data exchange and persistence.
- Local-First Resilience: Ensure uninterrupted voucher interactions and community governance workflows, even in offline or low-connectivity environments, leveraging OrbitDB's offline capabilities. The system is designed to function fully P2P, though optional community-run IPFS/OrbitDB nodes can bootstrap connectivity and ensure data availability.
- Trust-Driven Interactions: Implement reputation systems and consensus mechanisms triggered by OrbitDB events for secure, community-auditable interactions.
- Scalable Replication: Implement data sharing rules primarily for interaction-relevant parties, followed users, or project members, managed through OrbitDB access controls and application logic, minimizing resource overhead.
- Fiat Integration: Bridge traditional payment processors with decentralized voucher exchanges, using payment confirmation events to trigger state changes or enable voucher acquisition within the OrbitDB-based system.
| Term | Definition |
|---|---|
| Exonomist | A user who mints, exchanges, or redeems vouchers. |
| Exocrat | A user managing/contributing to Exocracy projects. |
| Voucher | A cryptographically signed promise of a specific product/service at a predetermined value. |
| Task | A unit of work within an Exocracy project, potentially linked to a method of funding including vouchers. |
| OrbitDB | A serverless, distributed, peer-to-peer database built on IPFS, enabling decentralized data storage & sync. |
| IPFS | InterPlanetary File System; a peer-to-peer hypermedia protocol for distributed file storage. |
| CRDTs | Conflict-free replicated data types enabling seamless offline/online state merging (used by OrbitDB). |
| UCAN | User Controlled Authorization Network; capability tokens for granular, delegable permissions. |
| DID | Decentralized Identifier used for users, communities, assets. |
- Data Layer: (Managed via OrbitDB databases over IPFS)
- Vouchers: JSON-LD/RDF-like documents stored in OrbitDB (e.g., Docs or KeyValue stores) with semantic metadata (author DID, owner DID, value, currency, expiry, terms, state, IPFS links for media).
- Tasks: Data structures in OrbitDB representing project tasks, potentially hierarchical, linking to parent projects, assigned Exocrats, status, and associated voucher CIDs or references for funding/compensation.
- Reputation: Scores (EXO-SCORE, EXOCRAT-SCORE) stored and updated in user profile databases (OrbitDB). User profiles (settings, followed users, etc.) also reside here.
- Chat Data: Messages stored in OrbitDB Feed or Log stores, linked to vouchers or tasks.
- Protocol Layer:
- OrbitDB: P2P database replication engine using pub/sub over IPFS for synchronization and CRDT-based state merging. Manages various database types (Docs, KeyValue, Feed, Log).
- IPFS: Decentralized storage for immutable assets like voucher media (images, videos), task evidence (photos), potentially large static files, and underlying storage for OrbitDB. Also supports OrbitDB operations.
- UCAN: Capability tokens potentially used for granting specific, often temporary, permissions (e.g., authorizing a specific voucher exchange, granting write access to a task database for an assigned Exocrat) that can also be iteratively delegated.
- Libp2p: Networking stack used by IPFS and OrbitDB for peer discovery, transport, and communication.
- Application Layer (Exonomy Controller App & Modules):
- Exonomy Host App: The main container application (e.g., built with Nuxt/Ionic/Capacitor). Manages overall P2P connections (IPFS/OrbitDB initialization), DID switching, and provides a framework for hosting pluggable modules.
- 'Vallet' Module: Manages user's owned/minted vouchers, DID profiles, interacts with OrbitDB voucher stores.
- 'vBay' Module: Public voucher marketplace interface. Queries public OrbitDB feeds/indices for discoverable vouchers, facilitates initiating exchanges.
- 'Exocracy' Module: Interface for creating, managing, browsing, and participating in projects and tasks. Interacts with OrbitDB project/task stores, handles crowdfunding/sourcing UI flows.
- Decentralized Chat Module: Integrates with voucher/task views, using OrbitDB Feed/Log stores for P2P messaging.
- (Potential Future Modules): Voucher-aware versions of apps like AirBnB, Uber, etc., plugging into the Exonomy host and leveraging its P2P infrastructure and voucher system.
The platform’s architecture relies on OrbitDB over IPFS for decentralized communication and data persistence.
- Decentralized Data Layer:
- OrbitDB provides serverless databases (Docs, KV, Feed, Log) stored on IPFS. Each user runs an IPFS node and opens/connects to relevant OrbitDB databases.
- Data synchronization occurs directly between peers via IPFS pub/sub channels associated with each OrbitDB database.
- Local-First Repositories:
- Each Exonomist effectively maintains local copies of the OrbitDB databases they access (e.g., their own profile/voucher DB, project DBs they participate in).
- CRDTs ensure that local changes made offline can be merged automatically and consistently when peers reconnect.
- Selective Replication via Access Control & Subscription:
- Data sharing is controlled by OrbitDB's Access Controllers (determining who can write) and by which databases/topics peers choose to connect to or subscribe to.
- For example, a private voucher might be in a database only accessible by the owner, while a public voucher is in a database with open read access. Project task data resides in databases accessible only to project members. Following a user means subscribing to their public feed database.
- UCANs can be used to grant temporary or specific write permissions to databases where needed (e.g., allowing a counterparty write access to update a shared state during an exchange).
- Decentralized Governance Triggers:
- Critical actions requiring consensus (e.g., task completion approval) are triggered by events within OrbitDB (e.g., a proposed state change). Application logic, potentially involving multi-sig logic simulated at the app layer or UCAN validation across stakeholders, enforces the consensus rules before committing the final state change to the relevant OrbitDB database.
- Unique identifiers for users, communities, and potentially assets. Likely based on public keys associated with the user's device/profile.
- Used extensively within OrbitDB access controllers and data entries to denote authorship, ownership, and permissions.
- Stored in CRDT-based OrbitDB repositories for conflict-free merging.
- Each DID identifies the primary OrbitDB databases associated with that user profile (e.g., personal voucher DB, profile settings DB).
- Switching between DIDs in the Exonomy app loads the profile data associated with the selected DID, connecting to the corresponding OrbitDB databases.
- Configuration data can be set to universal (app-level) or DID-specific scope (stored in the DID's profile DB), allowing payment methods or settings to be available globally or per-profile.
- Voucher Metadata:
- Vouchers modeled as structured data (JSON-like) within OrbitDB Docs stores, potentially using schemas (like JSON-LD context) for semantic meaning (currency, amount, issuer DID, expiry, linked media CIDs on IPFS).
- OrbitDB's append-only log structure provides inherent provenance tracking for data changes.
- Decentralized Indexing:
- Public voucher feeds might use OrbitDB Feed stores (append-only logs ideal for timelines) or Docs stores indexed by specific fields (e.g., category, location hash).
- Querying within OrbitDB (e.g.,
db.query()) allows filtering data locally based on content, enabling search without needing a central index. SPARQL could potentially be used over RDF-modelled data within OrbitDB stores if implemented at the application layer.
- Provenance Tracking:
- OrbitDB's underlying log structure immutably records operations (puts, deletes) with cryptographic hashes, ensuring data integrity and history.
- OrbitDB Access Controllers: Define write permissions for databases (e.g., only owner DID can write to personal voucher DB, multiple DIDs for shared project DBs). Read access might be open or restricted based on database address sharing.
- Capability Tokens (UCANs):
- Can be used to grant fine-grained, temporary, or delegable permissions beyond basic OrbitDB access control. E.g., Authorizing peer A to update a specific field in peer B's record during an interaction, validated before the
db.put()call.
- Can be used to grant fine-grained, temporary, or delegable permissions beyond basic OrbitDB access control. E.g., Authorizing peer A to update a specific field in peer B's record during an interaction, validated before the
- Replication Triggers (Subscription-based):
- Follows: Subscribing to another user's public OrbitDB Feed database replicates their public posts/voucher listings.
- Interactions: Exchanging vouchers might involve granting temporary write access (via UCAN or mutual agreement) to a shared temporary state DB or updating records in each participant's own DBs, with changes replicating between them.
- Project Membership: Joining an Exocracy project involves gaining access (address and potentially write keys/permissions) to the relevant OrbitDB databases for that project.
- Encryption & Privacy:
- End-to-end encryption for sensitive data (e.g., chat messages, private voucher terms) can be implemented at the application layer before data is put into OrbitDB. Keys could be exchanged via secure P2P channels (e.g., using libp2p streams) or managed via DIDs.
- Hotspot Profile Management: For local networking/replication using Bluetooth and Wi-Fi direct, potentially leveraging libp2p's transport options.
- Minting:
- Vouchers are minted by Exonomists who define parameters (product/service description, value, currency, expiry, media CIDs).
- The voucher data is created as an entry in the Exonomist's relevant OrbitDB store (e.g., a personal 'minted vouchers' Docs store). The Exonomist's DID is recorded as the author/initial owner.
- Publication:
- To make a voucher public, its data (or a reference/summary) is added to the Exonomist's public OrbitDB Feed store. Followers subscribed to this feed will replicate the entry.
- Feed entries include metadata and potentially links back to the full voucher details (if stored elsewhere and permissions allow). Social interactions (likes, comments) could be linked data or separate entries.
- Exchange:
- Peer-to-peer exchanges involve negotiation (e.g., via chat). Agreement triggers updates in the respective Exonomists' OrbitDB stores to reflect the change in ownership (e.g., updating the
ownerDIDfield). This might involve a multi-step confirmation process managed at the application layer, potentially using UCANs for authorization.
- Peer-to-peer exchanges involve negotiation (e.g., via chat). Agreement triggers updates in the respective Exonomists' OrbitDB stores to reflect the change in ownership (e.g., updating the
- Redemption:
- The current voucher owner presents it to the original author (issuer DID).
- The author validates the voucher (checks its status in their OrbitDB store) and confirms fulfillment. The voucher state is then updated to 'Redeemed' in the relevant OrbitDB store(s).
- State: Voucher entries in OrbitDB include a state field:
- Draft: Private entry in owner's DB.
- Listed: Entry exists in public Feed DB / discoverable store.
- Pending: Temporary state during exchange negotiation/confirmation.
- Exchanged:
ownerDIDfield updated. - Redeemed: Final state after fulfillment.
- Expired: State updated based on expiry date logic.
- Social Interaction & Moderation:
- Each voucher can host an unlimited number of dedicated chat rooms (implemented as OrbitDB Feed/Log stores linked to the voucher ID) for offers, counteroffers, and terms negotiation.
- Partial Payments/Offers: Buyers can propose composite offers (e.g., 60% cash payment confirmation + 40% barter voucher exchange). Chat rooms facilitate this negotiation. Split purchases can be coordinated in chat.
- Dynamic Pricing: Creators can update the 'Listed' voucher entry in their public feed/store.
- Moderation Controls: The voucher owner acts as Master of Ceremonies (MC) for associated chat rooms, managing access (via OrbitDB permissions or application logic), delegating moderation rights, etc.
- Barter/Exchange:
- Direct voucher-for-voucher exchange between Exonomists, updating ownership data in OrbitDB.
- Cash Integration:
- Payment processors (Stripe, PayPal, Wise, Venmo, Crypto Wallets, etc.) handle cash transactions outside the core P2P voucher system.
- Upon successful payment confirmation (communicated to the app), the application logic triggers the corresponding voucher ownership transfer within OrbitDB. This facilitates buying an existing voucher with cash. Plugin architecture supports adding future payment services.
- The 'Vallet' module interfaces with OrbitDB to present feeds:
- Internal Feed: Displays curated content based on subscriptions to other Exonomists' public OrbitDB Feed stores, project updates from relevant project DBs, etc.
- External Feed: Represents the Exonomist's own public OrbitDB Feed store, showing their listed vouchers, shared content, updates they wish to broadcast.
- Project/Task Creation: Exocrats create projects and tasks as data entries in dedicated OrbitDB stores (e.g., a 'projects' Docs store, with tasks potentially nested or linked). Metadata includes description, goals, status, manager DID, associated community members.
- Crowdfunding:
- Exocrats (Stakeholders) select one of their existing, minted vouchers (from their OrbitDB store) and 'attach' it to a specific task entry in the project's OrbitDB store. This attachment is a data update indicating conditional credit (e.g., adding the voucher CID and owner DID to a 'pledged_vouchers' array in the task data).
- The voucher itself remains in the owner's control but is marked (application state) or its state updated in OrbitDB to reflect it's pledged.
- Crowdsourcing & Exocrat Selection:
- Exocrats (Workers) browse tasks (querying project OrbitDB stores). They can offer their service vouchers (minted in their own store) as bids by creating a proposal linked to the task (e.g., an entry in a task-specific 'bids' OrbitDB store or via chat).
- Search Filters: Exocrats query project/task OrbitDB stores using criteria like keywords, value, crowdfunding status, location data, reputation scores (requiring access to relevant profile DBs), deadlines.
- Compensation Bundling: Exocrats propose combinations of pledged vouchers from the task's pool that meet their requirements. They might attach a 'wish list' requesting optional tips from overfunded tasks.
- Approval & Consensus (PM Role):
- The Project Manager (PM) reviews bids/offers. Approval triggers application logic:
- Selected pledged vouchers are marked for allocation (state update in project DB/task entry).
- A consensus check (e.g., requiring UCANs or confirmations from voucher owners recorded in the application layer or a dedicated consensus log DB) may be needed before finalizing.
- The assigned Exocrat (worker) gains relevant permissions (e.g., write access to task status fields in the project DB).
- Funds (vouchers) are released (ownership transferred in OrbitDB) only upon verified task completion.
- The Project Manager (PM) reviews bids/offers. Approval triggers application logic:
- Task Nomination & Acceptance: Exocrats can self-nominate or be invited. Acceptance enrolls the Exocrat, granting access to relevant project OrbitDB databases and participation rights.
- Overfunding & Voucher Release:
- Tasks can show pledged value exceeding target value.
- Exocrats claim compensation only up to the task’s declared value.
- Application logic automatically releases excess pledged vouchers (updates their state in OrbitDB) back to owners upon task completion confirmation.
- Overfunded tasks might allow Exocrats to request optional 'tips' from the surplus via wish lists, subject to individual owner approval.
- Unanimous Consent (Contextual):
- Required for specific critical actions within a narrow scope (e.g., a task's completion status update requires agreement from PM and assigned Exocrat(s), recorded via state changes in the OrbitDB task entry after app-level confirmation). Membership changes might require consensus within the specific project/task community (managed via OrbitDB access control updates).
- Asset Freezing (Author Control):
- Only the author of a voucher can 'freeze' their own voucher (update its state in their OrbitDB store to 'frozen') before an exchange is finalized, halting its use in interactions temporarily. Freeze/unfreeze actions are logged in the voucher's history (OrbitDB log).
- Reputation System:
- EXO-SCORE: Calculated based on data aggregated from OrbitDB records (e.g., count of vouchers issued where state became 'Redeemed', ratio of redeemed vs expired/cancelled, recent activity).
- Formula concept:
EXO-SCORE = f(Vouchers Successfully Redeemed by Others, Redemption Rate, Activity Metrics)
- Formula concept:
- EXOCRAT-SCORE: Calculated from project OrbitDB data (e.g., count of tasks completed as assigned Exocrat, positive confirmations from PMs/communities).
- Formula concept:
EXOCRAT-SCORE = f(Tasks Completed Successfully, Community Approval Indicators)
- Formula concept:
- Scores are stored in user profile OrbitDB stores and updated periodically by application logic based on new interaction/task data replicated via OrbitDB. Dynamic Adjustments reflect recent activity.
- EXO-SCORE: Calculated based on data aggregated from OrbitDB records (e.g., count of vouchers issued where state became 'Redeemed', ratio of redeemed vs expired/cancelled, recent activity).
- Dispute Resolution:
- Transparency: OrbitDB logs provide verifiable history of interactions and state changes. IPFS can store immutable evidence linked from OrbitDB records.
- Community Arbitration: If direct resolution fails, a pre-agreed community protocol (potentially involving a jury selected from project members or trusted community figures identified via DIDs) reviews evidence (from OrbitDB/IPFS) to propose a resolution. Enforcement relies on social consensus or pre-agreed application logic interpreting the outcome.
- Rage-Quit Mechanism: Participants might withdraw from projects. Application logic handles reassigning tasks and potentially returning unspent pledged assets (updating OrbitDB states accordingly), subject to project rules.
- Scalable Governance Structures:
- Delegated Roles: Roles like Facilitator, Liaison, Compliance Officer can be assigned within projects (recorded in project OrbitDB data), granting specific permissions (potentially via UCANs) or responsibilities managed by application logic.
- Modular Expansion: Projects and tasks can exist in hierarchies (linked via parent/child IDs in OrbitDB). Tasks might belong to multiple projects (requiring careful access control management across relevant OrbitDB stores). Communities are dynamically defined by membership lists within project/task OrbitDB databases. Cross-community collaboration involves selectively sharing access to relevant OrbitDB databases or replicating specific data between them.