Protocol implementation notes
Field-by-field mapping between draft-04 and this implementation, including the gaps this project fills.
draft-ayerbe-trip-protocol-04
1. Breadcrumb fields
A breadcrumb is a CBOR map keyed by the integers 0–8. The signature covers the deterministic CBOR of fields 0–7; the block hash is SHA-256 over the full encoding (0–8).
| key | name | type | meaning | notes |
|---|---|---|---|---|
| 0 | index | u64 | Position in the chain, contiguous from 0 | Enforced identically on the verifier |
| 1 | identity | bstr(32) | Ed25519 public key of the attester | Constant for the whole chain |
| 2 | timestamp | u64 | Unix seconds | Drives the §4.1 / §4.2 interval rules |
| 3 | h3 cell | u64 | H3 cell (transported as hex to avoid JS precision loss) | res 10 is about 15,000 m² |
| 4 | resolution | u8 | 7 to 10 | This implementation defaults to 10 |
| 5 | context digest | bstr(32) | SHA-256 over h3 / time bucket / Wi-Fi / cell / IMU | Missing parts are omitted entirely |
| 6 | prev hash | bstr(32) | null | Previous block hash; null at genesis | Forms the hash chain |
| 7 | meta flags | map | Includes the exploration session flag | §4.2 |
| 8 | signature | bstr(64) | Covers the deterministic CBOR of fields 0–7 | Ed25519 |
2. Where the draft is silent, and what this implementation chose
The draft deliberately leaves transport binding, naming and blockchain anchoring to companion specifications. That is an invitation rather than a gap.
| Gap | Draft | This implementation | Where |
|---|---|---|---|
| Transport binding | Not specified | libp2p relay, multiple verifiers, real-time challenge channel (companion draft direction) | trip-server WS + GPv1 design |
| Naming system | Not specified | did:geoyuan + W3C DID Document; display names go in alsoKnownAs | trip-core::did |
| Blockchain anchoring | Not specified | EVM anchoring of epoch roots and a revocation model (no tokens, no trajectory anchoring) | GeoTITRegistry.sol |
| TIT field numbering | Not specified | A GYIP-0003 internal convention; to be re-pinned once -05 lands | trip-core::tit + golden vectors |
3. Numeric determinism
Interoperability requires the same logic to produce the same bytes. The following conventions are pinned by golden vectors; any language following the same steps should land within the stated tolerance.
| Topic | Convention | Verified by |
|---|---|---|
| Deterministic CBOR | RFC 8949 §4.2 canonical form; same logic yields identical bytes on any platform | Golden vectors in tests/vectors/golden-vectors.json |
| PSD numeric conventions | Naive O(N²) DFT, f_k = k/N, ordinary least squares, IEEE-754 f64 | Cross-implementation α drift below 1e-9 |
| Lévy normalisation | 512-node composite Simpson after the substitution t = u·e^s | Drift below 1e-9 |
| Quantiles | Linear interpolation with rank = p·(n−1) | Calibration reports are reproducible |
| ROC | Descending threshold sweep, ties merged, trapezoidal AUC over FPR | No dependence on tie ordering |
4. Chain rules, implemented twice
Each rule exists twice: on device (WASM, refusing to append to the local chain) and on the verifier (Rust, refusing to store the evidence). They are independent, so defeating one still leaves the other — which is exactly why the end-to-end test observes 400 responses.
Observed: collecting two breadcrumbs at a fixed coordinate makes both the client self-check and the server reject, with the server returning “duplicate h3 cell at consecutive index 1”.