Juraj on Nostr: Released nostr:nevent1qqsz8tfwjjp5f20e9z70c8csdh7zdkq823qmdnmc7qtasj58aynwhrsgftkmj

quoting
nevent1q…tkmj

During recent discussions about the security of decentralized inference through routstr (nprofile…qeaf) people raised a valid concern: how can we be sure a provider doesn't read our prompts, or alter tool calls to backdoor the machine or the code it generates? Or how do we know the provider does not swap the model for a cheaper one and charge you full price? The usual answer is a TEE, a trusted execution environment. TEEs are hard to audit in practice. You trust the hardware vendor and re-verify a whole software stack after every update. We can do better, and now we do.

Routstr has a confidential mode. Your client talks TLS 1.3 directly to the upstream provider (Venice, for my node), and the Routstr node in between only relays encrypted records. Client and node compute the TLS keys together, so the node can add its API key without ever seeing your prompt or the answer, and it can't change a single byte of the response, tool calls included. Zero-knowledge proofs pin the model and the token cap, and you pay for the usage the provider itself reported. All of this rests on math and on the certificates you already trust, with no enclave or special hardware anywhere.

It works today on routstr.cypherpunk.today, through routstrd (I'm running opencode agents on it) and right in the browser, where the page does every check itself. It's new and experimental, so please try it and tell me what breaks.

Blog: https://juraj.bednar.io/en/blog-en/2026/10/10/confidential-inference-on-routstr-without-trusted-hardware/
Try it in the browser: https://jooray.github.io/routstr-confidential-pwa/
Paper: https://github.com/jooray/routstr-confidential/blob/HEAD/paper/paper.pdf
Code: https://github.com/jooray/routstr-confidential