Crypto

Doing a bit of a self-experiment.

Goal: use my personal health and travel data to provide personalized diet and exercise recommendations for me, using frontier models but in a way that avoids leaking to them any private information.

Strategy: use a local model (Qwen 3.8 Flash Next) to orchestrate, and use powerful remote models as a tool call to benefit from higher-level thinking and knowledge that the local model does not have.

Three-layer approach to privacy:

Avoid leaking personally identifiable information, or leaking my identity through writing style -> local model writes the queries to the frontier model, not me
Avoid leaking who I am through the payment channel -> zkAPI
Avoid leaking who I am through networking / IP -> Tor

You need all three (and finally we have all three, at least to some extent)

A skill file teaches the local model when and how to construct minimally-data-revealing requests to remote models. Use zkAPI-wrapped-with-Tor as a CLI tool.

And everything works! I got the recommendations back, info from frontier models helped to improve them.

Main deficiencies:

https://t.co/1g81Mp1sWW

@VitalikButerin We're thinking about this at Gnosis VPN. A mixnet like HOPR can in principle route every packet over a different path to a different exit. The hard part is using that in practice.

Gnosis VPN establishes prepaid sessions to an exit. Relays are paid per packet and the exit can only answer through SURBs (single-use reply blocks) the client sends ahead, so it can reply without learning who you are. In theory sessions could be tiny and switch constantly, e.g. keep 100 open and cycle them per target IP. But:

The deeper problem is that the VPN's network interface only sees packets. It can't tell where one request to a server ends and the next begins, and each TCP/QUIC connection is pinned to one exit anyway. HTTP/2 puts many requests on one connection, many sites and apps sit behind the same CDN IPs, and TLS resumption and cookies relink whatever you manage to split.

The VPN could try to guess request boundaries from timing, treating an idle gap on a connection as the end of a request. That isn't great either:

The good news is that the VPN doesn't need to guess. Split tunnelling isolates the apps that matter, like your zkAPI CLI, from the rest of your traffic (like a long running Jitsi call with totally different traffic pattern and trust assumptions). On top of that we can expose a local SOCKS endpoint where each isolation key maps to its own exit from a pool of pre-warmed sessions. The app knows what a request is, so it uses a fresh key and a fresh connection per request, and you get request-by-request delinking for exactly the traffic that needs it.