QUP, short for Quick Universal Protocol, is a compact binary protocol for durable state, telemetry, and request/response interactions across embedded systems. It targets small devices, mixed transports, and meshes that need a shared view of state without the implementation weight of larger, more general communication stacks.
Warning
QUP is a research project. The protocol specification is being proven and tested in real hardware, but the "reference" implementation is entirely AI-generated and unreviewed for now. The specification document has had days of human review, but I needed a working implementation quickly to prove QUP's usefulness.
Do not use in production. Do not rely on QUP in any manner. It's not ready yet, and will need a human-written implementation before ever being considered viable. As it stands, it does not meet the current standards I would otherwise expect for the Oro Operation System project.
- Binary framing with low parser cost.
- Explicit request/response interactions.
- Durable shared state.
- The ability to subscribe to changes to values from a particular node.
- Compatibility signaling through supported opcode sets.
- Message shapes that stay simple on constrained hardware.
- A narrow scope centered on embedded key/value state with explicit node ownership, not a general-purpose message bus, RPC framework, or production queue replacement.
- Nodes own data, report telemetry, and participate in the mesh.
- Most nodes are embedded devices, but any owner of data can be a node.
- Nodes own the data they expose. Other peers may query that data or request updates, but ownership stays with the node.
- A mesh is the wider network of nodes and transports that carry QUP traffic.
- Nodes are explicitly up or down in terms of reachability.
- Up means a node is presently reachable and can exchange QUP traffic.
- Down means a node is presently unreachable.
- Reachability is explicit. It is not inferred from stale values, missing telemetry, or the age of the last successful update.
- The initial value model is intentionally small: strings,
i64, and booleans.
QUP uses a small mandatory base vocabulary, explicit compatibility exchange, request/response semantics, and clear protocol-error boundaries.
- Keys are strings.
- Values are strings, signed 64-bit integers, or booleans.
- Durability is provided by the node and whatever storage backs that node.
This keeps the protocol focused on configuration, telemetry, and subscriptions without introducing a schema language into the transport layer.
For sessions with embedded nodes, repeated strings are exchanged through a session string table.
- The peer asks the node for its string count.
- The node returns that count.
- For each zero-based index, the peer asks for the string at that index.
- The peer retains that table for the life of the session.
- Get and set operations against that node use the string index instead of resending the string.
This keeps node-directed key references fixed-size after session setup. Messages that carry string values still have variable-length payloads.
- Discovery of nodes and their capabilities.
- Get and set operations on keys.
- Telemetry publication.
- Subscriptions to keys or key groups.
- Notifications when nodes appear, disappear, or change state.
Compatibility stays lightweight. Peers advertise which opcodes they understand, and new behavior grows by adding new requests, responses, and control messages instead of relying on version fields in the base frame.
qup-core: shared wire types and parser scaffolding.qup-embassy: Embassy-oriented embedded integration.qup-embassy-proc: derive macros forqup-embassyvalue types.qup: host-side implementations and shared utilities.qup-redis-bridge: Redis-backed QUP bridge scaffold.qup-test-cli: Tokio-based smoke client for exercising QUP nodes.qup-test-node: Tokio-based QUP test node with a stable mixed-permission key table.qup-test-tui: ratatui-based live key monitor for exercising QUP nodes.
- PROTOCOL.md: wire framing, encodings, command vocabulary, and payload layouts.
Copyright 2026 Joshua Lee Junon. Part of the Oro Operating System Project.
Licensed under either the MIT license or the Apache License, Version 2.0.
Major portions of the code were generated by Large Language Models (LLMs) and contain
AI-generated content. With the exception of the PROTOCOL.md specification, all code
and documentation is disclosed as the following: