LOUST-PRO/SnapPipe

The challenge

In my transport daemon the request handler context could drift from the auth state — a session that was authenticated could later lose its binding, and the handler would still dispatch. The identity and the work it was supposed to authorize were not tied together at the transport layer.

My role

I built an identity-anchored transport daemon in Rust where every handler invocation carries an attested identity token and the daemon refuses to dispatch unless the token chain verifies.

What I did

1. 01

   Attested-identity token per handler invocation

   Why: If a token chain does not verify, the handler does not dispatch. Period. The invariant holds at the transport, not at the application, which means a buggy application code path cannot break it.

   Trade-off: Slightly higher per-request latency for the token verification. The safety wins because the alternative is a silent auth drift.

2. 02

   Deterministic attestation chains

   Why: Audit-grade chains are easier to debug than probabilistic ones. A reviewer can replay the chain byte-by-byte and confirm what the daemon saw.

   Trade-off: Less flexibility for non-deterministic attestations. For an audit chain the determinism wins; for a performance-critical chain it might not.

3. 03

   Thin transport surface

   Why: Application code should not take on the identity-verification complexity. The daemon exposes a small request/response plus streaming surface so plug-in code stays simple.

   Trade-off: Less flexibility for exotic transport patterns. The thin surface is the product — anything exotic goes through a separate path.

What changed

• Auth-state drift

  Before: Possible (handler could dispatch against a stale session)

  After: Impossible — daemon refuses to dispatch on unverified chain

• Handler dispatch latency

  Before: About 5 milliseconds

  After: About 12 milliseconds (token verification overhead)

• Audit chain

  Before: Probabilistic — reviewer cannot replay

  After: Deterministic — replay byte-by-byte

Trade-offs

The runtime is stable but not currently active in production. The design carries over to the lzt-broker intent-filter work; the implementation does not need to ship as-is to deliver the lesson.

What I learned

Identity binding is best enforced at the transport, not at the application. The application is where bugs hide; the transport is where the invariant can hold against any application code.

Stack

• Rust
• transport
• identity

Repository

Evidence

• Repositoryhttps://github.com/LOUST-PRO/SnapPipe ↗