CC-Protocol Technical Documentation

CC-Protocol is a unified communication protocol designed for the Computational Choreography system. It provides standardized message formats for real-time sensor data streaming, latent state visualization, and control commands across distributed devices and services. The protocol enables seamless integration between iOS devices capturing motion data and backend services running machine learning models for motion analysis and synthesis. The protocol is designed with three primary goals: low-latency real-time communication suitable for interactive applications, flexible extensibility to support new sensor types and message formats, and cross-platform compatibility between Swift/iOS clients and Rust backend services. The cc-protocol implements a layered architecture consisting of three main layers. The application layer contains domain-specific logic such as motion streaming and visualization services. The protocol layer handles message encoding, decoding, and type-safe serialization. The transport layer provides the underlying communication mechanism, currently supporting WebSocket with planned support for HTTP and UDP. This separation of concerns allows the protocol to evolve independently of the transport mechanism. The same message structures can be transmitted over different transports depending on the requirements of latency, reliability, and bandwidth. Every message transmitted through cc-protocol is wrapped in a NetworkMessage envelope. This envelope provides essential metadata for routing, delivery guarantees, and message ordering. The NetworkMessage structure contains a protocol version string identifying the protocol revision (currently "0.1.0"), a unique 64-bit message identifier for tracking and acknowledgment, a microsecond-precision timestamp indicating when the message was created, sender and optional target identifiers for routing, the message payload itself, a priority value from 0 to 255 where 0 represents highest priority, a boolean flag indicating whether acknowledgment is required, and an optional reply-to field linking responses to their originating messages.