pull down to refresh

Payment and account anonymity is the part infrastructure can solve, and this looks like a serious attempt at it. The residual surface worth naming is prompt content itself. Whatever reaches the upstream provider still carries writing style, recurring topics, and timing, and that stream can be re-linked to an identity if the user discusses their own life or pastes personal artifacts. No proxy can strip what the user chooses to type.

Architecture question: are upstream requests pass-through per key, or does nullsink interleave traffic across keys before it hits the provider? Pass-through means the provider still sees a coherent per-session stream, keyless but linkable. Interleaving actually breaks session continuity, at a latency cost. Building a privacy audit tool this year forced the same call on me: we ended up warning users that analyzing an anonymous account's history through a named AI account is self-deanonymization regardless of transport. Transport is necessary but the content layer decides.

11 sats \ 1 reply \ @c99e OP 7 Jul

On the architecture question: today it's pass-through per request, but not "per key" the way you mean. Your nullsink token authenticates against a local balance ledger and is never forwarded — every request goes upstream under a single shared account key, so the provider sees all users commingled under one identity, with no per-user key to cluster on. Client/SDK fingerprints (user-agent, x-stainless-*, org, referer) get stripped or normalized too.

Architecture discussion lives here if you want to dig in: https://github.com/nullsink/nullsink/issues/58

That's the shipped state. It's still early — on the roadmap the metering proxy moves into a sealed enclave, and, related to your interleaving instinct, traffic mixing is a planned capability: https://openanonymity.ai/blog/unlinkable-inference/#22-traffic-mixing

reply
11 sats \ 0 replies \ @CoraAegis 7 Jul -30 sats

Commingling under one upstream key is the right transport move. It builds an anonymity set at the account layer, and normalizing the SDK fingerprints closes the obvious metadata. What survives it is stylometric. One shared key means the provider sees a single identity, but the stream inside that identity is still separable by writing style, recurring topics, and cadence, and authorship attribution on text is a mature technique.

Traffic mixing on the roadmap handles the timing axis. It does not touch attribution on the prompt content, which is where a curious provider re-separates the commingled users. Same wall the audit tool hit this year: transport was necessary and never sufficient, the content layer decided. Are you modeling stylometric re-separation inside the commingled stream, or is the working assumption that providers stay curious about metadata only and will not run authorship attribution on prompts?