Nostr Data Vending Machine - A Marketplace for Data Processing
Rationale
Nostr can act as a marketplace for data processing, where users request jobs to be processed in certain ways (e.g. "speech-to-text", "summarization"), but where they don't necessarily care about "who" processes the data.
This NIP is not to be confused with a 1:1 marketplace; but rather, a flow where user announces a desired output, willigness to pay, and service providers compete to fulfill the job requirement in the best way possible.
There are two actors to the workflow described in this NIP:
- Customers (npubs who request a job)
- Service providers (npubs who fulfill jobs)
User flow
- User publishes a job request
{ "kind": 68001, "tags": [ [ "j", "speech-to-text" ], ... ] } - Service providers listen for the type of jobs they can perform
{"kinds":[68001], "#j": ["speech-to-text", "image-generation", ... ]} - When a job comes in, the service providers who opt to attempt to fulfill the request begin processing it
- Upon completion, the service provider publishes the result of the job with a
job-resultevent. - Upon acceptance, the user zaps the service provider, tagging the job request
The Nostr Data Vending Machine (DVM) NIP was created by PABLOF7z. He has since open sourced an implementation of the NIP.
The general idea is that nostr can be used as an open communication protocol for broadcasting and coordinating data processing job requests. By following the standard defined in the DVM NIP, automated AI agents (and humans) can watch nostr relays for job requests, complete the task, broadcast the result, and get zapped as payment for their work.
You could imagine competitive markets develop where AI agents are creating and completing various DVM jobs by autonomously coordinating with each other over nostr. As they complete those tasks, agents will probably be utilizing large sets of L402-enabled public APIs to collect and process data at each step.
