The interface · M06 · roadmap
The TechnoRides Protocol is the specification nodes, agents, and merchants speak: message contracts, authentication, versioning, and public routing rules. It's what turns a set of apps into a network of networks.
mTLS + per-message signatures
Mutual authentication between parties; every ledger event is individually signed.
Orders, status events, ledger events
Typed contracts for every mode, plus signed reputation and payment events.
Cross-network, public, neutral rules
Destination resolved by geography, service type, and node state — demonstrably neutral.
Heartbeat & authorization
A node enrolls, renews its dispatch authorization, and reports health — or stops processing.
Build status. The network layer — registry, ledger, roaming, and this protocol (M06) — is on the roadmap and shown as a target architecture, not a live service. The operation plane (node, apps, dispatch, payments, tracking) is what ships today.
Message contracts
The protocol defines the messages that move across the network — orders and status events for every mode, signed ledger events, and the node lifecycle. Same shapes everywhere, so a node, an agent, and a merchant all speak the same network.
Create, route, and track orders of any mode — moto, car, luxury, van, shuttle, bus, freight — with status events through the whole trip lifecycle. One contract per transition, idempotent by order id.
Reputation and payment events, each cryptographically signed at the source. The registry records only hashes and minimal amounts — never trip or passenger data. Reputation belongs to the driver and travels across networks.
The node lifecycle: enrollment, heartbeat, and the dispatch authorization a node renews while it complies. Without a valid authorization, a node can't process orders — neutrality enforced by the contract, not by trust.
Privacy by design. Trip and passenger data never enter protocol messages bound for the registry. Ledger events carry only hashes, amounts, and the method class — no personal data.
A message on the wire
Every protocol message is a typed envelope: a version, a message type, a signed body, and an idempotency key. Mutual TLS authenticates the parties; the signature proves the payload. This is what a node, an agent, or a merchant puts on the wire.
order.create, order.status, ledger.event, node.heartbeat# A node sends a routable order over mTLS
{
"protocol": "technorides/1.2",
"type": "order.create",
"idempotency_key": "ord_8f2a1c",
"body": {
"mode": "car",
"origin": { "lat": -34.6037, "lng": -58.3816 },
"destination": { "lat": -34.6158, "lng": -58.4333 },
"node": "ar-buenos-aires"
},
"signature": "ed25519:3a7f…b91c"
}
# → 202 Accepted · routed by public rules
{ "order_id": "ord_8f2a1c", "status": "routing" }Open & versioned
Semantic versioning with migration windows and two active versions on major changes. Public, neutral routing rules. Auth that proves both who you are and what you sent.
A breaking change never strands a node. Two versions run side by side through a published window, and the conformance suite proves you're ready before the old one retires.
The contract change ships with public release notes and a migration guide, ahead of any cutover.
Two active versions are negotiated in the handshake for a window of at least 90 days — no flag day.
Pass the suite on the new version to keep your dispatch authorization valid through the cutover.
Once the window closes, the previous major version is sunset on the published date.
In build. The protocol, its versioning policy, and the conformance suite are on the roadmap and shown as a target specification, not a live service. Version numbers shown are illustrative.
Conformance
A node joins the network only after it passes the conformance suite — a complete, automated test of every contract it must honor. Certification is what keeps routing neutral and the ledger trustworthy.
Every node certifies before it processes a single order. The suite exercises orders, status events, ledger writes, and the lifecycle handshake end to end.
Certify against a simulated node with scoped sandbox credentials — no production access required to prove your integration is correct.
Passing the suite is what unlocks a valid dispatch authorization. Re-certify on every major version to keep it.
SDKs
Three SDKs map to the three audiences that speak the protocol — retries with backoff, idempotency by order id, signed webhook handling, and an example per use case.
Embedded in the Node Gateway. Runs your operation against the protocol — dispatch, payments, and events, signed end to end.
For AI agents that request, offer, or orchestrate drivers. Wraps the Agent API with scoped OAuth and signed webhooks.
For merchants dispatching last-mile orders. Typed order creation, status events, and settlement, idempotent by order id.
In build. The SDKs, the simulated node, and the conformance suite are not yet released. Package names are placeholders.
Extensible
The protocol reserves a single extension point for future interoperability with external platforms — designed in, but not switched on. Interoperability is a future option, not a requirement to operate.
AIOS is an independent platform; interoperability between the two is reserved for the future, not required.
A versioned, namespaced slot in the envelope. External platforms can be admitted later through verification — never as a bypass of the network's neutral rules.
Get started
The protocol is the common language that turns a set of apps into a network of networks. Read the docs, install an SDK, and certify against the conformance suite.