Data Vending Machines and Agent Work
Data vending is the strange Commerce corner where a Nostr event becomes a job request, a service provider becomes a market participant and payment becomes a negotiation over compute.
Money in, data out
NIP-90 uses one of the clearest phrases in the Nostr standards world: money in, data out. It describes a marketplace for on-demand computation where a customer publishes a job request and service providers can return results, feedback and payment requests. It is not a shop. It is a job board for machines.
The NIP reserves request kinds in the 5000-5999 range, result kinds in the 6000-6999 range and kind 7000 for job feedback. A translation job, transcription job, summarization job, image task or analysis task can become an event. Service providers can respond with processing status, errors, partial results, payment-required messages or final output.
This belongs in Commerce because the product is work. The customer wants a result. The service provider wants payment. The relay carries the market conversation. A wallet or zap flow can settle value. That is a very different commercial pattern from a T-shirt listing or a creator tip.
The standard is useful and messy
The canonical NIP-90 page is marked unrecommended with the warning that it got out of control and that use-case-specific microstandards are preferable. That warning needs to stay visible. It does not mean the idea died. It means the broad standard tried to hold many kinds of compute work and became too large as a universal answer.
For you, this is actually helpful. It tells us how to treat data vending: not as a finished industry standard, but as a family of product experiments around job events, bidding, encrypted inputs, result events, feedback states and payment behavior.
The useful reading path avoids the trap of pretending there is one clean Data Vending Machine market. There are many possible markets: transcription, translation, machine-assisted prompts, media processing, indexing, search, moderation, analytics and agent actions. Each needs its own trust model.
The job request is a small contract
A NIP-90 job request can include inputs, output format, parameters, a bid, relays where service providers publish responses and a target service provider. Inputs can be text, URLs, Nostr events or prior job outputs. Parameters can be public or encrypted. The result can include the original request, input reference, customer pubkey and an amount with an optional BOLT11 invoice.
That structure reads like a small contract. The customer says what they want, where responses belong and what they may pay. The service provider decides whether to process, ask for payment first, show a partial result or return an error. The protocol leaves room for different risk models.
The ambiguity is useful for experiments and difficult for users. If a service can ask for payment before producing anything, the customer needs reputation. If a service can produce first and ask later, the provider needs confidence. If input is sensitive, encryption and data retention matter. If outputs can be low quality, the market needs review or repeat behavior.
FoundUPS belongs here as an economic story
FoundUPS appears in this route because it points toward agent work, compute networks and project formation. Whether a specific implementation changes over time is less important than the question it raises: what happens when an open social protocol can carry tasks, identities, proof, payment and coordination for small projects or agents?
That is the real Commerce story. A future Nostr economy may include people hiring people, people hiring software, software requesting other software, and communities funding useful outputs. The line between marketplace, grant, bounty and compute job starts to blur.
The danger is buzzword fog. Agent economy pages can become meaningless very quickly. The article needs to tie the idea to observable mechanics: what event starts the job, who signs it, who sees it, who performs it, what output arrives, how value moves and what evidence remains after the work is done.
Privacy is not optional
Data vending can expose sensitive inputs. A transcription job may include private audio. A summarization job may include unpublished text. An analysis job may contain business data. A moderation job may expose community conflict. NIP-90 allows encrypted parameters and encrypted outputs, but product safety depends on much more than one tag.
You need to ask where inputs are stored, whether the service provider logs them, whether relays can infer metadata, whether payment identifies the customer, whether output is public and how retries or job chaining affect privacy.
This is why Data Vending sits beside Privacy and Wallets in the wider map. Commerce without privacy literacy becomes extraction.
How to judge a data vending product
Do not judge it only by the demo. Ask what job kinds it supports, whether it publishes NIP-89 service announcements, how it handles payment-required feedback, whether it can prove completion, whether it encrypts inputs, whether it publishes partial samples, how it resolves disputes and whether the output can be independently checked.
A simple transcription service may be easy to verify. A complex agent task may be much harder. The more subjective the output, the more reputation matters. The more private the input, the more trust and encryption matter. The larger the payment, the more the product needs receipts, limits and dispute paths.
A good Commerce hub gives you these questions before it sends them into the archive.
The market is a queue of promises
Data vending sounds mechanical, but every job request is a promise. The requester promises a task, constraints and possible payment. The service provider promises work, quality and delivery. Relays carry the conversation. Wallets or invoices settle value. The result may be public, encrypted, partial or useless.
This is why NIP-90 needs careful product writing. A transcription job and an agent workflow are not the same market. A translation can be checked by a human reviewer. A summarization can be subjective. A search-indexing job may require trust in data coverage. A moderation job may involve sensitive community material.
The event model is flexible enough to describe many jobs. That flexibility is also the reason the canonical NIP warns that the broad approach became unwieldy. Builders need narrower product agreements around specific work types.
You should treat data vending as a family of markets, not one market.
Payment timing changes trust
A service can ask for payment before work, after work or after a preview. Each timing model creates a different trust problem. Pay first and the requester risks junk output. Pay after and the provider risks unpaid labor. Pay after a preview and the system needs a way to reveal enough value without giving the whole result away.
NIP-90 feedback states such as payment-required, processing, error, success and partial are useful because they let a client show the state of the job. But the commercial design still matters. Does the provider have a reputation? Is the invoice tied to the job? Can the requester verify the output? Can a bad result be disputed?
For small jobs, the market may tolerate rough trust. For larger agent work, it cannot. The more money or private data involved, the more the system needs receipts, constraints, identity and a support path.
This is the kind of detail that turns a protocol page into a useful Commerce page.
Agents need public boundaries
FoundUPS-style agent economics become interesting only when you can see the boundary of the agent. What can it do? Who runs it? Which key signs its actions? Which wallet pays or receives? Which relays carry requests? Can humans intervene? What happens when the agent makes a bad decision?
Without those boundaries, agent commerce becomes theater. A page can say autonomous, decentralized or AI-assisted and still tell you nothing. The useful story is about authority, payment, visibility and accountability.
Nostr is a natural place to experiment because keys, events and relays can make agent actions inspectable. But inspectable is not the same as safe. A signed bad action is still a bad action. A public job request can still leak private intent. A payment can still reward low-quality output.
The Commerce hub should invite curiosity without swallowing hype whole.
Privacy is the hidden cost of compute markets
Many data vending jobs are built from private material: audio, drafts, notes, datasets, images, messages or business files. If a user sends that material to a service provider, the payment may be the least sensitive part of the transaction. The data itself can be the real cost.
Encryption helps, but it does not solve everything. A provider must decrypt or process the input somehow. Relays may reveal metadata. Output may expose source information. Logs may persist. Payment records may connect a user to the task. A model or worker may retain material outside the protocol.
This is why data vending should link naturally to Privacy and Wallets. You need to understand both the payment permission and the data permission.
A good data vending product explains what it reads, what it stores, what it returns and what it forgets.
NIP-89 matters in the background
Data vending becomes easier to discover when service providers can announce what they handle. NIP-89 recommended application handlers and service discovery patterns sit in the background of this world because a requester needs to know which tool can process which job. Without discovery, a job market becomes a guessing game.
A good product will not make users manually hunt for a provider every time. It can show known service providers, supported job kinds, prices, reputation, examples and privacy posture. That is where the machine market begins to feel like a product rather than a protocol exercise.
Discovery also creates ranking power. The client that decides which service providers appear first can influence who earns money. That is another reason data vending is a governance and commerce topic, not only a developer topic.
You should watch how discovery is handled, because it quietly shapes the market.
Quality is harder to verify than payment
Payment can be binary. An invoice is paid or it is not. Quality is harder. A transcription can contain subtle errors. A translation can be fluent and wrong. A summary can omit the important part. An image task can look good while violating the brief. A search job can miss sources the user expected.
This means data vending markets need quality signals. Samples, previews, ratings, repeat providers, public examples, dispute paths and reputation all matter. Without them, the cheapest provider wins until users stop trusting the whole market.
Nostr can publish some of those signals, but product design has to make them readable. Raw feedback events do not help a normal person unless the client translates them into context.
A mature data vending product will feel more like a marketplace for verified work than a slot machine for random outputs.
Agent work needs spending limits
An agent that can request work or spend money needs limits. That is true whether the agent is a personal assistant, a project coordinator, a media processor or a market bot. Without limits, a mistake becomes financial exposure.
NWC-style budgets, scoped permissions, approval steps and revocation paths can make agent commerce safer. But the user still needs to understand the chain of authority. Did the human approve the job? Did the agent approve it? Did the wallet pay automatically? Could the agent be tricked by a malicious event?
These questions sound advanced, but they will become ordinary if Nostr-based agents become useful. The Commerce hub should prepare you now by tying agent excitement to spending boundaries.
That keeps the topic grounded in real product safety.
The first useful markets will be narrow
The broad data-vending idea is seductive, but the first useful markets are likely narrow. Transcribe this file. Translate this note. Summarize this article. Generate a preview. Index this event set. Label this image. Check this spam report. Each has a clearer input, output, price and verification path than a vague agent task.
Narrow jobs let clients build better UX. They can show expected output, sample providers, typical price, privacy warnings and completion states. They can compare providers. They can let users repeat a known task instead of inventing a contract each time.
That is probably why the NIP-90 warning points toward use-case-specific microstandards. A smaller standard can do one job well. A universal compute market can become too abstract for real users.
The Commerce page should teach this bias toward narrowness.
A result event is not the same as a useful answer
A provider can publish a result event and still disappoint the customer. The output may be low quality, late, incomplete, unreadable, wrong format or disconnected from the input. Protocol success and user success are different things.
This is why result previews, quality samples, repeat-provider history and dispute language matter. A client should not treat every result event as a satisfied customer. It should help the user decide whether the work is actually useful.
The same lesson appears across Commerce. A listing is not a purchase. A zap is not a fulfilled promise. A paid invoice is not delivery. A result event is not satisfaction.
Good commerce writing keeps the protocol object and the human outcome separate.
Compute markets may start as developer tools
The earliest strong users for data vending may be developers, researchers and power users rather than mainstream consumers. They already understand jobs, APIs, events, outputs and verification. They can tolerate rough edges if the tool saves time.
That does not make the topic niche forever. Many consumer products began as developer workflows. If job requests, wallet payments and provider reputation become stable, simpler consumer-facing surfaces can hide the mechanics later.
The useful question is where the workflow is already painful enough that people will tolerate a new protocol path. Search indexing, media processing, translations, bot work and event analysis are plausible early zones.
This page points you toward those practical first markets rather than describing an abstract machine economy.
What to open after this page
After the data-vending overview, open NIP-90 with its warning label in mind. Do not read it as a finished universal market. Read it as a map of job requests, feedback events, result events and payment possibilities that still need narrower product design.
Then compare the idea with real tasks. A transcription market, a translation market, an event-indexing market and an agent-work market need different UX, privacy rules and reputation. If a product page describes all of them with one vague claim, it is not ready for you.
Finally, connect this page to Privacy and Wallets. A data job can spend money and expose data at the same time. The safe product explains both boundaries before the user submits the task.
Sources worth opening
These are the primary trails used for this article. Open them when you want the protocol text, repository context or project surface behind the explanation.
