UNPKG

oneie

Version:

Build apps, websites, and AI agents in English. Zero-interaction setup for AI agents (Claude Code, Cursor, Windsurf). Download to your computer, run in the cloud, deploy to the edge. Open source and free forever.

870 lines (693 loc) 22.5 kB
--- title: ONE Protocol Standard Specification version: 1.0.0 status: Draft date: 2025-11-25 authors: ONE Protocol Foundation license: CC BY-SA 4.0 --- # ONE Protocol Standard Specification v1.0 **The Universal Protocol Layer for the Internet** --- ## Abstract ONE Protocol is an open standard for protocol-agnostic application architecture. It defines a universal data model and registry pattern that enables applications to integrate with infinite protocols without code changes. This specification defines the core ontology, protocol registry mechanism, and interoperability patterns that make ONE Protocol the universal protocol layer for the internet. **Key Innovation:** Protocols are data, not code. --- ## Table of Contents 1. [Introduction](#1-introduction) 2. [Core Concepts](#2-core-concepts) 3. [The ONE Ontology](#3-the-one-ontology) 4. [Protocol Registry](#4-protocol-registry) 5. [Data Structures](#5-data-structures) 6. [Protocol Integration](#6-protocol-integration) 7. [Interoperability Patterns](#7-interoperability-patterns) 8. [Security & Compliance](#8-security--compliance) 9. [Implementation Guidelines](#9-implementation-guidelines) 10. [Conformance](#10-conformance) --- ## 1. Introduction ### 1.1 Purpose ONE Protocol standardizes how applications integrate with multiple protocols (payment systems, blockchains, messaging platforms, storage providers, identity systems, etc.) by treating protocols as data rather than hardcoded integrations. ### 1.2 Goals - **Protocol Agnosticism:** Applications work with any protocol without code changes - **Infinite Extensibility:** Support unlimited protocols via registry pattern - **Interoperability:** Enable cross-protocol workflows and translations - **Future-Proof:** Work with protocols that don't exist yet ### 1.3 Non-Goals - Replace existing protocols (ONE Protocol orchestrates, doesn't compete) - Define protocol-specific implementations (protocols self-describe) - Mandate specific database technology (implementation-agnostic) ### 1.4 Terminology - **Protocol:** Any system with a defined interface (e.g., Stripe, Solana, SMTP) - **Protocol Definition:** Metadata describing a protocol's schema and requirements - **Protocol Registry:** Database of protocol definitions - **Protocol Handler:** Implementation that processes protocol-specific logic - **Ontology:** The 6-dimensional data model (Groups, People, Things, Connections, Events, Knowledge) --- ## 2. Core Concepts ### 2.1 Protocols as Data **Traditional Approach:** ```typescript // Hardcoded protocol logic if (protocol === 'stripe') { // Stripe-specific code } else if (protocol === 'solana') { // Solana-specific code } ``` **ONE Protocol Approach:** ```typescript // Protocol-agnostic logic const protocolDef = await registry.get(metadata.protocol); const handler = getHandler(protocolDef); return handler.process(metadata); ``` ### 2.2 The Universal Data Model ONE Protocol defines 6 core dimensions that model all digital interactions: 1. **Groups** - Isolation boundaries (multi-tenancy) 2. **People** - Authorization & governance 3. **Things** - Entities (users, products, content, tokens, etc.) 4. **Connections** - Relationships between things 5. **Events** - Actions that happened 6. **Knowledge** - Searchable content (RAG) **Key Principle:** These 6 dimensions never change. Protocol-specific details live in `metadata`. ### 2.3 Protocol Registry Pattern Protocols self-register with schema definitions: ```typescript { name: "solana_pay", version: "1.0", category: "payment", schema: { required: ["signature", "slot"], optional: ["memo"], types: { signature: "string", slot: "number", memo: "string" } }, examples: [ { signature: "5J7kMQ...", slot: 123456789 } ] } ``` --- ## 3. The ONE Ontology ### 3.1 Groups **Purpose:** Multi-tenant isolation and hierarchical organization. **Structure:** ```typescript interface Group { _id: Id<'groups'>; slug: string; // URL identifier name: string; // Display name type: 'friend_circle' | 'business' | 'community' | 'dao' | 'government' | 'organization'; parentGroupId?: Id<'groups'>; // Hierarchical nesting settings: { visibility: 'public' | 'private'; joinPolicy: 'open' | 'invite_only' | 'approval_required'; }; status: 'active' | 'archived'; createdAt: number; updatedAt: number; } ``` **Rules:** - Every entity MUST belong to a group (multi-tenant isolation) - Groups MAY be nested up to 5 levels deep - System-level entities belong to reserved "system" group ### 3.2 People **Purpose:** Authorization, governance, and AI agent identity. **Structure:** ```typescript interface Person { _id: Id<'people'>; groupId: Id<'groups'>; email?: string; role: 'platform_owner' | 'group_owner' | 'group_user' | 'customer'; permissions: string[]; // Granular permissions status: 'active' | 'suspended' | 'deleted'; createdAt: number; updatedAt: number; } ``` **Rules:** - Every action MUST have an actor (person or AI agent) - Roles define authorization scope - AI agents are people with `type: 'ai_agent'` ### 3.3 Things **Purpose:** Universal entity representation. **Structure:** ```typescript interface Thing { _id: Id<'things'>; type: ThingType; // 66 consolidated types name: string; groupId: Id<'groups'>; // Multi-tenant isolation properties: Record<string, any>; // Type-specific data (flexible) status: 'active' | 'inactive' | 'draft' | 'published' | 'archived'; createdAt: number; updatedAt: number; deletedAt?: number; // Soft delete } ``` **Thing Types (66 total):** - Core: `creator`, `ai_clone`, `audience_member`, `organization` - Business Agents: `strategy_agent`, `marketing_agent`, `sales_agent`, etc. (10 types) - Content: `blog_post`, `video`, `podcast`, `course`, etc. (7 types) - Products: `digital_product`, `membership`, `consultation`, `nft` (4 types) - Community: `community`, `conversation`, `message` (3 types) - Tokens: `token`, `token_contract` (2 types) - Knowledge: `knowledge_base`, `document` (2 types) - Commerce: `product`, `order`, `cart`, `invoice`, `payment_method` (5 types) - Protocols: `mandate`, `webhook`, `api_key` (3 types) - Infrastructure: `website`, `page`, `form`, `email_template`, etc. (10 types) - Analytics: `metric`, `insight`, `report`, `dashboard` (4 types) - Automation: `workflow`, `trigger`, `action` (3 types) - Media: `image`, `audio`, `file` (3 types) - Identity: `credential`, `session`, `oauth_token` (3 types) - Blockchain: `wallet`, `smart_contract`, `transaction` (3 types) **Rules:** - `properties` field is flexible (no schema migrations) - `properties` MUST be validated at application boundary - Protocol-specific data goes in `metadata` for connections/events ### 3.4 Connections **Purpose:** Relationships between things. **Structure:** ```typescript interface Connection { _id: Id<'connections'>; fromThingId: Id<'things'>; toThingId: Id<'things'>; relationshipType: ConnectionType; // 25 consolidated types metadata?: Record<string, any>; // Protocol-specific data strength?: number; // 0.0 to 1.0 validFrom?: number; validTo?: number; createdAt: number; updatedAt?: number; deletedAt?: number; } ``` **Connection Types (25 total):** - Ownership: `owns`, `created_by` - AI: `clone_of`, `trained_on`, `powers` - Content: `authored`, `generated_by`, `published_to`, `part_of`, `references` - Community: `member_of`, `following`, `moderates`, `participated_in` - Business: `manages`, `reports_to`, `collaborates_with` - Tokens: `holds_tokens`, `staked_in`, `earned_from` - Products: `purchased`, `enrolled_in`, `completed`, `teaching` - Consolidated (use metadata): `transacted`, `notified`, `referred`, `communicated`, `delegated`, `approved`, `fulfilled` **Rules:** - Consolidated types MUST include `metadata.protocol` - `metadata` MUST be validated against protocol definition - Soft deletes preserve audit trail ### 3.5 Events **Purpose:** Immutable audit log of all actions. **Structure:** ```typescript interface Event { _id: Id<'events'>; type: EventType; // 52 consolidated types actorId: Id<'things'>; // Who/what caused this targetId?: Id<'things'>; // Optional target groupId: Id<'groups'>; // Multi-tenant isolation timestamp: number; metadata: Record<string, any>; // Event-specific data } ``` **Event Types (52 total):** - Lifecycle: `thing_created`, `thing_updated`, `thing_deleted` - User: `user_registered`, `user_verified`, `user_login`, `user_logout`, `profile_updated` - Auth: `password_reset_requested`, `email_verified`, `two_factor_enabled`, etc. - Group: `user_invited_to_group`, `user_joined_group`, `user_removed_from_group` - Dashboard: `dashboard_viewed`, `settings_updated`, `theme_changed` - AI: `voice_cloned`, `appearance_cloned` - Agent: `agent_executed`, `agent_completed`, `agent_failed` - Token: `token_minted`, `token_burned`, `tokens_purchased`, `tokens_staked`, etc. - Course: `course_enrolled`, `lesson_completed`, `course_completed`, `certificate_earned` - Analytics: `metric_calculated`, `insight_generated`, `prediction_made` - Cycle: `cycle_request`, `cycle_completed`, `cycle_revenue_collected` - Blockchain: `nft_minted`, `nft_transferred`, `contract_deployed` - Consolidated: `content_event`, `payment_event`, `subscription_event`, `commerce_event`, `livestream_event`, `notification_event`, `referral_event`, `communication_event`, `task_event`, `mandate_event`, `price_event` **Rules:** - Events are immutable (never updated or deleted) - Retention policies define lifecycle - Consolidated types MUST include `metadata.protocol` ### 3.6 Knowledge **Purpose:** RAG (Retrieval-Augmented Generation) for semantic search. **Structure:** ```typescript interface Knowledge { _id: Id<'knowledge'>; knowledgeType: 'label' | 'document' | 'chunk' | 'vector_only'; text?: string; embedding?: number[]; // Vector for semantic search embeddingModel?: string; // e.g., "text-embedding-3-large" embeddingDim?: number; sourceThingId?: Id<'things'>; sourceField?: string; // e.g., "content", "transcript" chunk?: { index: number; tokenCount: number; start?: number; end?: number; }; labels?: string[]; // Free-form categorization metadata?: Record<string, any>; createdAt: number; updatedAt: number; deletedAt?: number; } ``` **Rules:** - Only embed content users will semantically search - Don't embed structured data (use filters instead) - Update embeddings when source content changes --- ## 4. Protocol Registry ### 4.1 Protocol Definition Structure ```typescript interface ProtocolDefinition { _id: Id<'protocol_definitions'>; name: string; // Unique protocol identifier version: string; // Semantic versioning category: 'payment' | 'messaging' | 'commerce' | 'identity' | 'storage' | 'blockchain' | 'other'; schema: { required: string[]; // Required metadata fields optional: string[]; // Optional metadata fields types: Record<string, 'string' | 'number' | 'boolean' | 'object' | 'array'>; }; examples: any[]; // Valid metadata examples documentation?: string; // Link to protocol spec publisher?: string; // Who published this protocol compliance?: { // Regulatory compliance pci_dss?: boolean; gdpr?: boolean; kyc?: boolean; regions?: string[]; }; status: 'active' | 'deprecated' | 'experimental'; createdAt: number; updatedAt: number; } ``` ### 4.2 Protocol Registration **Process:** 1. Developer submits protocol definition 2. Platform owner reviews and approves 3. Protocol becomes available immediately 4. No code deployment required **Example:** ```typescript await registerProtocol({ name: 'solana_pay', version: '1.0', category: 'payment', schema: { required: ['signature', 'slot'], optional: ['memo', 'reference'], types: { signature: 'string', slot: 'number', memo: 'string', reference: 'string' } }, examples: [ { signature: '5J7kMQ...', slot: 123456789, memo: 'Coffee payment' } ], documentation: 'https://docs.solanapay.com', status: 'active' }); ``` ### 4.3 Protocol Validation **Generic Validator:** ```typescript async function validateProtocolMetadata( registry: ProtocolRegistry, metadata: any ): Promise<ValidationResult> { // 1. Check protocol field exists if (!metadata.protocol) { return { valid: false, errors: ['Missing protocol field'] }; } // 2. Fetch protocol definition const protocolDef = await registry.get(metadata.protocol); // 3. Unknown protocol = warning (forward compatibility) if (!protocolDef) { return { valid: true, warnings: [`Unknown protocol: ${metadata.protocol}`] }; } // 4. Validate required fields const errors: string[] = []; for (const field of protocolDef.schema.required) { if (!(field in metadata)) { errors.push(`Missing required field: ${field}`); } } // 5. Validate types for (const [field, expectedType] of Object.entries(protocolDef.schema.types)) { if (field in metadata && typeof metadata[field] !== expectedType) { errors.push(`Field ${field} should be ${expectedType}`); } } return { valid: errors.length === 0, errors }; } ``` --- ## 5. Data Structures ### 5.1 Database Schema **Required Tables:** - `groups` - Multi-tenant isolation - `people` - Authorization - `things` - Universal entities - `connections` - Relationships - `events` - Audit log - `knowledge` - RAG/search - `protocol_definitions` - Protocol registry **Required Indexes:** - `groups`: `by_slug` - `people`: `by_email`, `by_group` - `things`: `by_type`, `by_group`, `by_status` - `connections`: `by_from`, `by_to`, `by_type` - `events`: `by_type_time`, `by_actor`, `by_target`, `by_group` - `knowledge`: `by_source`, `by_embedding` (vector index) - `protocol_definitions`: `by_name`, `by_category` ### 5.2 Metadata Standards **Protocol Metadata:** ```typescript { protocol: string; // REQUIRED: Protocol identifier [key: string]: any; // Protocol-specific fields } ``` **Example (Solana Pay):** ```typescript { protocol: 'solana_pay', signature: '5J7kMQ...', slot: 123456789, memo: 'Coffee payment' } ``` **Example (Stripe):** ```typescript { protocol: 'stripe', chargeId: 'ch_123', amount: 1000, currency: 'usd' } ``` --- ## 6. Protocol Integration ### 6.1 Integration Pattern **Step 1: Register Protocol** ```typescript await registerProtocol({ name: 'new_protocol', schema: { ... }, examples: [ ... ] }); ``` **Step 2: Implement Handler** ```typescript class NewProtocolHandler implements ProtocolHandler { async process(metadata: any): Promise<Result> { // Protocol-specific logic } } ``` **Step 3: Register Handler** ```typescript registerHandler('new_protocol', new NewProtocolHandler()); ``` **Step 4: Use Protocol** ```typescript await createConnection({ fromThingId: userId, toThingId: merchantId, relationshipType: 'transacted', metadata: { protocol: 'new_protocol', // ... protocol-specific fields } }); ``` ### 6.2 Handler Interface ```typescript interface ProtocolHandler { // Process protocol-specific logic process(metadata: any): Promise<Result>; // Validate metadata (optional, registry validates by default) validate?(metadata: any): Promise<ValidationResult>; // Translate to another protocol (optional) translate?(targetProtocol: string, metadata: any): Promise<any>; } ``` --- ## 7. Interoperability Patterns ### 7.1 Cross-Protocol Workflows **Pattern:** Chain multiple protocols in sequence. **Example:** ```typescript // Pay with Bitcoin → Mint NFT on Ethereum → Email receipt const payment = await processPayment({ protocol: 'bitcoin', txHash: '0x123...' }); const nft = await mintNFT({ protocol: 'ethereum', contractAddress: '0xABC...', tokenId: '42' }); await sendNotification({ protocol: 'smtp', to: 'user@example.com', subject: 'NFT Minted' }); ``` ### 7.2 Protocol Fallback Chains **Pattern:** Try protocols in priority order. **Example:** ```typescript const protocols = [ { protocol: 'solana_pay', priority: 1 }, { protocol: 'stripe', priority: 2 }, { protocol: 'paypal', priority: 3 } ]; for (const { protocol } of protocols) { try { return await processPayment(protocol, amount); } catch (error) { console.log(`${protocol} failed, trying next...`); } } ``` ### 7.3 Protocol Translation **Pattern:** Convert metadata from one protocol to another. **Example:** ```typescript // Stripe → Solana Pay translation async function translatePayment( stripeMetadata: any, targetProtocol: 'solana_pay' ): Promise<any> { return { protocol: 'solana_pay', signature: await convertToSolanaSignature(stripeMetadata.chargeId), slot: await getCurrentSlot(), amount: stripeMetadata.amount / 100 // Stripe uses cents }; } ``` --- ## 8. Security & Compliance ### 8.1 Authentication - All actions MUST have an authenticated actor - Use standard auth mechanisms (OAuth, JWT, etc.) - AI agents MUST be authenticated as people ### 8.2 Authorization - Role-based access control (RBAC) - Group-level isolation (multi-tenancy) - Permission checks at application boundary ### 8.3 Data Privacy - Soft deletes preserve audit trail - Hard deletes for GDPR compliance - PII encryption at rest ### 8.4 Protocol Compliance - Protocols self-declare compliance requirements - Filter protocols by regulatory needs - Automatic compliance enforcement --- ## 9. Implementation Guidelines ### 9.1 Minimum Viable Implementation **Required:** 1. Implement 6 core tables (groups, people, things, connections, events, knowledge) 2. Implement protocol registry table 3. Implement generic protocol validator 4. Support at least 3 protocols **Recommended:** 1. Vector search for knowledge 2. Soft delete support 3. Event retention policies 4. Protocol marketplace UI ### 9.2 Technology Stack **Database:** - Any database with JSON support (PostgreSQL, MongoDB, Convex, etc.) - Vector search capability for knowledge (optional but recommended) **Backend:** - Any language/framework - Must support async/await for protocol handlers **Frontend:** - Any framework - Must support dynamic protocol selection ### 9.3 Performance Considerations - Index all foreign keys - Use connection pooling - Cache protocol definitions - Batch protocol validations - Implement event retention policies --- ## 10. Conformance ### 10.1 Conformance Levels **Level 1: Basic Conformance** - Implements 6 core dimensions - Supports protocol registry - Validates protocol metadata **Level 2: Full Conformance** - Level 1 + - Implements all 66 thing types - Implements all 25 connection types - Implements all 52 event types - Supports protocol versioning **Level 3: Advanced Conformance** - Level 2 + - Supports protocol translation - Implements protocol fallback chains - Supports cross-protocol workflows - Implements protocol marketplace ### 10.2 Certification **Process:** 1. Implement ONE Protocol 2. Submit for certification 3. Pass conformance tests 4. Receive certification badge **Benefits:** - Listed on one-protocol.org - Access to protocol marketplace - Community support --- ## Appendix A: Protocol Examples ### A.1 Payment Protocols **Stripe:** ```typescript { name: 'stripe', category: 'payment', schema: { required: ['chargeId', 'amount', 'currency'], types: { chargeId: 'string', amount: 'number', currency: 'string' } } } ``` **Solana Pay:** ```typescript { name: 'solana_pay', category: 'payment', schema: { required: ['signature', 'slot'], types: { signature: 'string', slot: 'number' } } } ``` ### A.2 Messaging Protocols **SMTP:** ```typescript { name: 'smtp', category: 'messaging', schema: { required: ['messageId', 'to', 'subject'], types: { messageId: 'string', to: 'string', subject: 'string' } } } ``` **Discord:** ```typescript { name: 'discord', category: 'messaging', schema: { required: ['channelId', 'messageId'], types: { channelId: 'string', messageId: 'string' } } } ``` --- ## Appendix B: Migration Guide ### B.1 From Hardcoded Integrations **Step 1:** Identify all protocol integrations **Step 2:** Create protocol definitions for each **Step 3:** Refactor code to use protocol handlers **Step 4:** Migrate data to ONE Protocol schema **Step 5:** Test and deploy ### B.2 From Other Standards **From REST APIs:** - Map endpoints to thing types - Map HTTP methods to events - Store API responses in metadata **From GraphQL:** - Map types to thing types - Map mutations to events - Store query results in knowledge --- ## Appendix C: Governance ### C.1 ONE Protocol Foundation **Mission:** Maintain and evolve the ONE Protocol standard. **Responsibilities:** - Publish specification updates - Certify implementations - Maintain protocol registry - Community support ### C.2 Contribution Process 1. Submit proposal (GitHub issue) 2. Community discussion 3. Technical review 4. Approval/rejection 5. Specification update --- ## Appendix D: Versioning **Semantic Versioning:** - MAJOR: Breaking changes to core ontology - MINOR: New features (backward compatible) - PATCH: Bug fixes and clarifications **Current Version:** 1.0.0 **Upgrade Path:** - Implementations MUST support current version - Implementations MAY support previous versions - Deprecation period: 12 months minimum --- ## License This specification is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). You are free to: - Share — copy and redistribute the material - Adapt — remix, transform, and build upon the material Under the following terms: - Attribution — You must give appropriate credit - ShareAlike — You must distribute under the same license --- ## References 1. ONE Platform Implementation: https://github.com/one-platform/one 2. Protocol Registry: https://one-protocol.org/registry 3. Community Forum: https://forum.one-protocol.org 4. Certification: https://one-protocol.org/certification --- **ONE Protocol v1.0.0** **The Universal Protocol Layer for the Internet** © 2025 ONE Protocol Foundation. Licensed under CC BY-SA 4.0.