Confidential Data Vending Machines

This is a working research note from the ungovernable.tech project, not a finished design.

Data Vending Machines (DVMs) are a Nostr pattern (NIP-90) in which a user publishes a job request, such as "transcribe this audio" or "summarise these documents", and service providers compete to do it for a Lightning payment. Today the provider sees everything: the input, the output and often the identity of the requester.

The NIPs README marks NIP-90 as unrecommended and recommends use-case-specific microstandards. This note explores an existing DVM pattern; it does not establish NIP-90 as a recommended foundation for a new service.

Processing confidential data currently means one of two things: give up the privacy, or run everything locally. Local processing is viable for many tasks on consumer hardware, but not when the job is occasional and needs hardware you do not own, or when you want to use a model you cannot buy outright. Confidential computing offers a third way: both parties place their part (model and data) into an encrypted, attested virtual machine, and only the owner of the data receives the result.

Use cases

• Providing sensitive documents as retrieval context to a language model.
• Analysing confidential datasets without handing them to the analyst.

Sketch of the flow

1. Deploy a fresh confidential container for each job (for example with Confidential Containers on AMD SEV-SNP or Intel TDX).
2. Establish a secure channel with the user. The container generates a one-time Nostr key pair inside the enclave and contacts the user. On its own this is not enough: the user must be able to verify that the key was generated inside the attested environment, so the attestation report must bind the public key (Remote Attestation Architecture).
3. Gather the data. Either the user sends inputs over encrypted direct messages to the enclave key, or the DVM job flow is extended to hand the user the attested channel.
4. Execute the job.
5. Deliver the result over the secure channel.
6. Destroy the VM and its keys.

Open problems

• Attestation in confidential containers was immature when this note was started; an attestation service running in a trusted environment is needed to release secrets only to verified workloads (the CoCo Trustee key broker addresses this).
• GPU confidential computing requires specific hardware combinations (for example NVIDIA Hopper-class GPUs with a CPU TEE), and cloud support for confidential GPU nodes has been uneven (NVIDIA GPU TEEs).
• Pushing an entire VM per job is heavy; per-job confidential containers are lighter but have a larger trusted computing base.
• The provider still learns metadata: that a job happened, its size and timing, and the payment.

A first proof of concept ("something works") lives in the repository's simple-test/ directory.

Related reading

• Confidential AI Inference and Private LLM Inference Patterns
• NIP-90: Data Vending Machines — unrecommended in the NIPs README.

Primary sources

• NIPs README: NIP-90 status

Also in Identity, Social and TrustDecentralized Compute