open-standards/joule-code/examples/transport-moqt
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science d14f583d92 Cargo: no minimum-supported-version floor, because the policy is latest stable
The repository tracks the latest stable Rust, pinned at the root. A
`rust-version` key states a *floor* -- the oldest toolchain a crate supports --
which is a different promise, and one this repository does not make. It also
said 1.97 while the pin was 1.98.0 and nothing verified it, so it was a claim in
the wrong direction and unchecked in both.

So it goes, everywhere:

    59  rust-version = "1.97"            (workspace and package declarations)
   417  rust-version.workspace = true    (members inheriting them)
   476  files, 476 deletions, 0 insertions

The 417 are why this is not the sixty-file change it looks like from a grep for
the value. A member inheriting a key that no longer exists does not fall back to
a default -- its manifest stops resolving. Removing the declarations without the
inherits would have broken every workspace that has members.

Deliberately untouched: `joule-code-rs/vendor/wtransport/Cargo.toml`. That is a
vendored third-party crate declaring a floor about itself, not about us, and our
pin is above it. Editing vendored source to satisfy our own policy would make
the copy diverge from upstream for no benefit.

Verified rather than assumed:

- all 493 `Cargo.toml` files in the tree parse (`tomllib`)
- `cargo metadata --no-deps --locked` resolves on `joule-code-rs`, `wai-rs`,
  `openpay`, `mesh-rs`, `sandbox-rs` and `jcp-rs` -- the check that actually
  exercises workspace inheritance, which a TOML parse does not
- no `Cargo.lock` changed; `rust-version` is not lockfile state

`wai/wai-verify/Cargo.toml` already carried a comment saying it omits
`rust-version` on purpose, so this makes the rest of the tree agree with the one
crate that had already decided.

What this gives up, stated plainly: cargo can no longer greet an older
toolchain with "requires rustc 1.97" and will instead fail wherever the code
first needs something newer. That is the cost of not maintaining a floor, and
it is the right cost when the floor was fiction.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-11-03 17:42:20 -05:00
..
tests
Cargo.lock sec: zstd 0.14.3 for RUSTSEC-2026-0391, -0398, -0403 and -0410 2026-10-26 11:36:49 -04:00
Cargo.toml Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
README.md

transport-moqt — CommunicationOS transport binding (the last federation layer)

A consumer binding showing a Joule Code collaboration's committed coding operations carried over CommunicationOS's MoQT transport — the network wire layer left deferred by spec/collab.md §2.

It closes the loop on the federation stack. The other three layers are already built and tested in joule-code-collab: BFT consensus (LockstepCluster), FROST threshold authorization (protected), and MLS group keying (tests/mls_keying.rs). This example adds the transport.

What it demonstrates

The whole stack, end to end, in one in-process test:

BFT consensus (LockstepCluster)  →  committed, op_id-ordered coding ops
   →  published as MoQT objects over CommunicationOS's transport (inv-moq)
   →  each object carries a real Ed25519 / BLAKE3 signed receipt
   →  a subscriber receives every op, verifies the signed receipts against the
      publisher's key, and recovers the original SignedOp intact

A second test shows the ownerless-trust property: a subscriber that requires receipts rejects a group whose signed receipt does not chain to a trusted publisher key — no central authority decides who is authentic.

The transport

The carrier is inv-moq — joulesperbit's MoQT (Media over QUIC Transport) wire protocol plus its JWP receipt extension, the CommunicationOS broadcast-media transport. It exposes Publisher / Subscriber / GroupHandle / Relay traits with object-level signed provenance and joule receipts.

The test drives inv-moq through its MockFabric, which runs the real publish/subscribe/receipt machinery in-process — real Ed25519 signatures, real BLAKE3 merkle receipts — with no QUIC and no network. inv-moq's quic feature is the real-wire path (quinn/rustls); the trait surface is identical, so this binding moves to the network by swapping the fabric, not the code.

This is a standalone workspace (path-deps inv-moq from joulesperbit and the joule-code-* crates), so the standard's reference library stays free of a joulesperbit dependency — the same discipline as examples/l3-jouleclaw.

Run

cargo test

Expected:

test untrusted_publisher_is_rejected ... ok
test committed_ops_replicate_over_communicationos_moqt_with_signed_receipts ... ok