The mobilexyz protocol implements a network layer designed for elegance and simplicity while providing sophisticated spatial awareness. This proposal outlines how datastructs move through the network, persist across time, and enable machine understanding of three-dimensional space.
Mobilexyz uses websocket connections between clients and relays. Relays function as spatial data hubs, with built-in geographic awareness. Each relay announces its primary geographic regions of interest, enabling clients to connect to relays most relevant to their spatial queries.
The connection protocol is straightforward. Clients initiate websocket connections to relays and authenticate using their cryptographic keys (secp256k1). Once connected, clients can publish new datastructs, subscribe to spatial regions, and query historical spatial data.
Datastructs propagate between relays based on both priority and spatial relevance. The priority byte in each datastruct guides propagation speed, while spatial references determine which relays receive the data.
Each relay maintains a simple geographic index of its datastructs. When receiving a new datastruct, the relay checks its spatial references against its geographic coverage. Datastructs with spatial references within the relay's regions are stored and propagated to peer relays with overlapping coverage.
This geographic routing happens automatically through the relay network. High-priority datastructs (emergency, critical) propagate to all connected relays regardless of spatial relevance, ensuring critical information reaches the entire network.
Clients query spatial data through simple subscription messages:
Relays respond with matching datastructs, ordered by priority and timestamp. Continuous subscriptions receive new matching datastructs as they arrive.
The mobilexyz protocol implements a two-tier persistence model. Most datastructs live on relays, which store and forward spatial data based on relevance and priority. For critical spatial information, trusted community members can flag datastructs for permanent storage on IPFS.
These "spatial anchors" - the most important datastructs - might include building entrances, emergency routes, or historically significant locations. The process is community-driven: when multiple trusted creators flag a datastruct for permanence, participating relays automatically pin it to IPFS and maintain its availability.
This hybrid approach keeps the network efficient while ensuring crucial spatial data remains permanently accessible. Relays maintain rolling windows of recent datastructs, typically 30-90 days, while spatial anchors persist indefinitely through IPFS.
The protocol embraces graceful degradation. Invalid signatures or malformed fields don't trigger network errors - relays simply ignore the invalid components while processing valid parts of datastructs. This enables partial data recovery even when datastructs are damaged during transmission.
Version mismatches are handled through a simple fallback system. Relays process what they understand of newer versions while ignoring unknown fields. This ensures the network can evolve without breaking existing implementations.
Security builds on proven cryptographic standards. Every datastruct must be signed by its creators using secp256k1 signatures. Relays verify these signatures before propagation, preventing unauthorized modification of spatial data.
Spam prevention uses a combination of rate limiting and trust levels. Relays track creator behavior and may require proof-of-work for high-frequency publishers. The trust level byte in datastructs helps relays prioritize data from reliable sources during high network load.
Privacy considerations are handled through the protocol's inherent properties. While spatial data is public, creators can use different key pairs for different contexts. The protocol includes no personally identifiable information - only cryptographic identities and spatial references.
Relays form the backbone of mobilexyz, but the protocol remains relay-agnostic. Clients can connect to multiple relays for redundancy. Geographic distribution of relays naturally emerges as organizations run relays focused on their areas of interest.
The MVP stage focuses on basic relay functions:
The mobilexyz protocol includes a built-in economic layer powered by the mxyz token on Solana, enabling sustainable API access for artificial intelligence and robotics at scale. This design maintains the protocol's decentralized nature while providing resources for relay operators and spatial data contributors.
The mxyz token serves multiple functions in the protocol:
API consumers lock mxyz tokens in relay-specific smart contracts. These contracts automatically release payments based on API usage while maintaining proof of sufficient token balance for continued access. The payment flow uses Solana's low-fee, high-speed capabilities to enable per-query microtransactions.
Relays expose their spatial data through both websocket connections and a REST API designed for AI and robotics integration. The REST API enables high-volume spatial queries with standardized endpoints:
The API implements a tiered access model:
The API is designed specifically for machine understanding of space. Each query can specify required precision levels, confidence thresholds, and context types. For example, a delivery robot might query:
Responses include machine-readable spatial relationships, confidence scores, and real-time updates. The API supports both point queries for immediate navigation and streaming updates for continuous spatial awareness.
The API provides standardized endpoints for spatial queries:
GET /spatial/query Parameters: bounds: [min_x,min_y,min_z,max_x,max_y,max_z] type: physical|social|emergency precision: 0-255
GET /spatial/navigate Parameters: start: [x,y,z] end: [x,y,z] type: standard|emergency
GET /spatial/context Parameters: location: [x,y,z] radius: float type: all|physical|historical
The mobilexyz protocol introduces a novel system for linking digital content to physical space using "datastructs" - data structures that capture spatial relationships with rich contextual awareness. Each datastruct contains core identity and routing information, spatial coordinates, and contextual metadata.
The protocol builds on NOSTR's cryptographic foundation, using identical secp256k1-based identities and signatures. This enables users to use existing NOSTR keys and infrastructure while adding spatial capabilities.
- Version byte (0x01) - Creator count byte (0x00-0xFF, maximum 255 creators) - Primary Creator ID (32 bytes, NOSTR-compatible secp256k1 public key) - Reference ID (32 bytes) - Trust level byte (0x00-0xFF) - Priority byte (0x00-0xFF, with defined ranges for priority levels) - Timestamp (8 bytes, Unix epoch in seconds) - Reserved (5 bytes, zeroed) - Additional Creator IDs array (32 bytes per creator)
- Reference count (2 bytes) - For each reference: - Coordinates (24 bytes total: x,y,z as float64) - Precision byte (0x00-0xFF) - Type byte (physical, temporal, social, etc.) - Tag length (2 bytes) - Tag data (up to 70 bytes, UTF-8 encoded)
Fields are concatenated in strict order with no delimiters. This byte string is SHA-256 hashed, then signed using the creator's secp256k1 private key:
1. Header Components: version_byte (1 byte) creator_count (1 byte) primary_creator_id (32 bytes) reference_id (32 bytes) trust_level (1 byte) priority_byte (1 byte) timestamp (8 bytes) reserved (5 bytes) additional_creator_ids (n * 32 bytes) 2. Spatial References Length (2 bytes) 3. Spatial References Array: x_coordinate (8 bytes) y_coordinate (8 bytes) z_coordinate (8 bytes) precision_byte (1 byte) type_byte (1 byte) tag_length (2 bytes) tag_data (variable)
After concatenation, this byte string is:
The protocol's approach to error handling is implicit but important. Malformed datastructs are simply ignored rather than generating errors, enabling graceful degradation in imperfect network conditions. Invalid signatures or spatial references don't invalidate an entire datastruct - systems can still use valid portions of the data.
Implementation of mobilexyz requires careful attention to floating-point handling. The protocol specifies IEEE 754 double-precision format for coordinates, but implementations must handle potential rounding errors, especially when comparing spatial references.
Cultural and linguistic considerations appear in the tag data structure. While the protocol specifies UTF-8 encoding, tag conventions recommend using English prefixes with local-language content, enabling global interoperability while preserving local meaning.
The protocol's simplicity belies its capability for complex spatial relationships. Through careful composition of basic elements - coordinates, references, tags, and timestamps - mobilexyz can represent sophisticated spatial and temporal relationships while remaining accessible to simple implementations.