Versioned, machine-checkable protocol contracts — born of Ryo choreographies, open to any language.
Hocket originates in the choreographic-programming model proposed in
RFC: Choreographic Protocols for Ryo: one program over
role-typed values (T @ Role), projected to endpoints by the compiler. But the
.hocket contract it defines is bound to no language — it is a flat JSON state
machine that any implementation, in any programming language, can monitor itself
against and verify its peers with, over the wire.
Hard rule zero: the contract is build output, never source. It is regenerated from the choreography like a lockfile. Any hand edit invalidates it.
| File | Contents |
|---|---|
hocket-0.1.md |
The hocket/0.1 specification — document format, operational semantics, versioning, handshake, encoding, transports, conformance |
Interactive walkthrough of the protocol (live monitor playground, contract anatomy, handshake rules): hocket.ryolang.org.
- One artifact. Roles, states, message schemas, error vocabulary — canonically hashed with JCS (RFC 8785). Same choreography → same contract → same hash.
- Every endpoint checked. Each role runs a monitor holding just
(session_id, current_state)over its own projection of the graph. - Sequence and shape, never semantics. A contract proves the client sent
PaymentAuthat the right time with the right fields — not thatcharge()charged the right amount. - Any language. Ryo is the origin, not a requirement. Conformance is judged by golden deterministic-CBOR traces over the wire, not by shared code — Rust, Swift, Kotlin, TypeScript, or anything else with a CBOR library.
Draft 0.1, pre-implementation. The state machine and the handshake are stable inputs to the v0.1 implementation; the sequence-level evolution calculus and contract registry are open work (§12 of the spec).
Pepe Navarro — creator of Ryo.
This specification is licensed under CC BY 4.0. Implementations of the protocol — in any language — are explicitly welcome and are not derivative works of this text.