rich1.0redshift (npub1ft…redsh)https://nostr.ae/npub1ftt05tgku25m2akgvw6v7aqy5ux5mseqcrzy05g26ml43xf74nyqsredshnjumphttps://nostr.aePlease say more. How can we ensure that we're getting the attestation of the actual code? What can we demand from Tinfoil? This is what Routstr does right now (from my LLM): Trust boundaries worth knowing A few nuances from reading the code: 1. We follow the latest signed release. routstr-sdk does not pin a specific releaseTag or expected codeFingerprint by default. It verifies whatever the verifier says is the latest signed release of tinfoilsh/confidential-model-router. That's a "trust the release process" model, not a hardcoded allow-list. 2. The bundle is assembled by Tinfoil's ATC. The SDK fetches a pre-assembled bundle from https://atc.tinfoil.sh/attestation rather than fetching GitHub/Sigstore/AMD itself. This is safe because every component is independently signed/verified — the ATC is a proxy, not a trust root — but it's still a component in the path. 3. The verified repo is the router, not the model server directly. By default, configRepo is tinfoilsh/confidential-model-router. Downstream model enclaves are covered by Tinfoil's enclave chaining — the router verifies the inference enclave. Our client only directly verifies the first hop. 4. Headers are plaintext to the proxy. EHBP encrypts the JSON body. The auth token, X-Routstr-Model, and other headers are visible to the Routstr proxy. The model id inside the body is stripped to the bare upstream id and encrypted. 5. Dependency supply chain. We trust tinfoil@1.1.6, ehbp@0.2.3, and their transitive deps. The package lock pins them, but the npm registry supply chain is a boundary. So: yes, routstr-sdk does real Tinfoil attestation — client-side, before token spend, with encryption bound to the attested key. The main trust decisions are "follow latest signed router release" and "trust AMD + GitHub Actions/Sigstore + the Tinfoil npm package."