LOUST-PRO/SnapPipe

El reto

En mi demonio de transporte el contexto del request handler podía derivar del estado de auth — una sesión que estaba autenticada podía perder su binding más tarde, y el handler seguía despachando. La identidad y el trabajo que supuestamente autorizaba no estaban atados a nivel de la capa de transporte.

Mi rol

Construí un demonio de transporte con identidad anclada en Rust donde cada invocación de handler lleva un attested identity token y el demonio rehúsa despachar a menos que la cadena de tokens verifique.

Lo que hice

1. 01

   Attested-identity token por invocación de handler

   Por qué: Si una cadena de tokens no verifica, el handler no despacha. Punto. El invariante se sostiene a nivel de transporte, no de aplicación, lo cual significa que un path de código de aplicación bugueado no puede romperlo.

   Trade-off: Latencia por request ligeramente mayor por la verificación del token. La seguridad gana porque la alternativa es un auth drift silencioso.

2. 02

   Cadenas de attestation determinísticas

   Por qué: Las cadenas de grado audit son más fáciles de debuggear que las probabilísticas. Un reviewer puede replay de la cadena byte por byte y confirmar lo que el demonio vio.

   Trade-off: Menos flexibilidad para attestations no determinísticas. Para una cadena de auditoría el determinismo gana; para una cadena performance-critical podría no.

3. 03

   Superficie de transporte delgada

   Por qué: El código de aplicación no debería tomar la complejidad de verificación de identidad. El demonio expone una superficie pequeña de request/response más streaming para que el código que se enchufa se mantenga simple.

   Trade-off: Menos flexibilidad para patrones exóticos de transporte. La superficie delgada es el producto — cualquier cosa exótica va por un path separado.

Lo que cambió

• Auth-state drift

  Antes: Posible (el handler podía despachar contra una sesión stale)

  Después: Imposible — el demonio rehúsa despachar ante cadena no verificada

• Latencia de despacho de handler

  Antes: Alrededor de 5 milisegundos

  Después: Alrededor de 12 milisegundos (overhead de verificación de token)

• Cadena de auditoría

  Antes: Probabilística — el reviewer no puede hacer replay

  Después: Determinística — replay byte por byte

Trade-offs

El runtime está estable pero no activo en producción actualmente. El diseño se traslada al trabajo de intent-filter del lzt-broker; la implementación no necesita entregarse as-is para entregar la lección.

Lo que aprendí

El binding de identidad se enforce mejor en el transporte, no en la aplicación. La aplicación es donde se esconden los bugs; el transporte es donde el invariante puede sostenerse contra cualquier código de aplicación.

Stack

• Rust
• transport
• identity

Repositorio

Evidencia

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