What if APIs required no registration, only required sats or ecash, and offered verifiable reputation? What if discovering computational services was as simple as querying a relay, and market forces naturally drove compatibility without centralized control?
This isn't a hypothetical—it's exactly what Data Vending Machines (DVMs) deliver today on the Nostr network.
The API Problem
Traditional APIs have served us well, but they come with fundamental limitations that become more apparent as we build increasingly decentralized systems:
Authentication Friction: Almost every API requires registration, email verification, and API key management. Users must create accounts with personal information before accessing any service.
Timeout Constraints: Most APIs enforce short timeouts because long-running requests exhaust server thread pools, connection limits, load balancer timeouts, or CDN restrictions. This makes them poorly suited for long-running computations like AI inference, video processing, or complex analysis.
Reputation Opacity: API reliability depends on domain name reputation and corporate promises. Moreover, DNS itself operates under centralized gatekeepers like ICANN, creating single points of control where domains can be seized, censored, or deregistered by authorities. There's no cryptographic way to verify which entity actually performed a computation or to build trust incrementally over time.
Discovery Silos: Each API exists in isolation. Finding computational services requires platform marketplaces like RapidAPI, vendor documentation sites, manual research, and often paying just to test compatibility.
Payment Friction: While traditional APIs could theoretically accept Bitcoin via protocols like L402 (
) or ecash tokens (e.g. ), they typically require KYC-based payment processors that demand excessive personal information and complex integration.Enter Data Vending Machines
Data Vending Machines solve each of these problems elegantly by rethinking API communication— using Nostr events as the transport protocol instead of HTTP, and cryptographic identities instead of domain-based endpoints.
Zero-Friction Authentication
DVMs use Nostr's built-in cryptographic identity system. Every request is a signed event, providing automatic authentication without registration. Users can start using any DVM immediately with just their Nostr keypair—no email, no API keys, no terms of service.
The signature proves the request came from that specific user, while maintaining privacy—the DVM learns nothing about the user beyond their public key. The only accessible information about that user is whatever they have already published publicly with that same npub.
Truly Asynchronous Design
Most APIs enforce short timeouts because long-running requests exhaust server thread pools and tie up expensive resources, making it impossible to serve other requests efficiently. DVMs solve this elegantly because they're genuinely asynchronous - no threads are held waiting for responses. The relay infrastructure handles the message passing, so providers can take as long as they need without tying up any connection resources. Some of the many use cases one could imagine:
- AI model inference: 30-second image generation that doesn't timeout
- Video processing: Hour-long transcoding jobs work seamlessly
- Data analysis: Complex computations can take as long as needed
- Batch processing: Large datasets can be processed without connection limits
Users submit a request and receive responses whenever the computation completes, whether that's seconds, hours, or even days later.
Verifiable Reputation
Every DVM response is cryptographically signed by the provider's private key. This creates a verifiable track record that users can evaluate:
Users can verify that Provider X actually performed computation Y with result Z. Over time, this builds cryptographically-verifiable reputation that can't be faked or transferred.
Effortless Discovery
DVMs announce themselves via Nostr events (originally using NIP-89 kind 31990 events, but current devs are encouraging a switch to kind 31999; you can read more here: github.com/nostr-protocol/nips/pull/1941 and github.com/nostr-protocol/nips/pull/1942), making discovery as simple as querying relays. For example:
{"kinds": [31990],
"#k": ["5300"],
}
Where 31990 is the current DVM announcement kind used from NIP-89, new DVMs are encouraged to use 31999. 5300 is the kind number for algorithmic feeds.
This query returns all algorithmic feed services currently available. No web searching, no API directories, no manual research—just query for the computation type you need.
Seamless Payment Integration
DVMs leverage a unique advantage: they can receive nutzaps (P2PK-locked cashu tokens) without any payment integration setup, since anyone can send payments directly to their Nostr cryptographic identity. Users publish their payment preferences (trusted mints, preferred payment methods) in their Nostr profiles via kind:10019 events, creating native payment discoverability. Since users already have these payment methods configured in their Nostr clients, there's minimal friction for either side—no separate merchant accounts, no payment processor onboarding, and no personal information sharing required. DVMs support all the same payment options as traditional API services, but they also gain access to the entire ecosystem of Nostr identity-derived payments that APIs simply can't access.
Market Dynamics Drive Innovation
Because DVMs are easy to discover and use, powerful market dynamics emerge:
Standardization Through Competition: When multiple providers serve the same job type, they naturally converge on compatible input/output formats. Providers who deviate risk reduced adoption, creating incentives for interoperability without central control.
Quality Through Reputation: Cryptographic signatures create permanent track records. Poor providers can't hide behind rebranded domains—their reputation follows their cryptographic identity.
Innovation Through Low Barriers: Creating a new DVM requires only implementing the Nostr event protocol. No app store approval, no platform partnerships, no minimum volumes. This dramatically lowers barriers to innovation.
Price Discovery: Open bidding reveals true market prices for computational services. Users benefit from competition while providers can charge premium prices for superior quality or unique capabilities.
Competitive Marketplace in Action
Perhaps most powerfully, users can submit "open requests" without specifying a provider, letting multiple DVMs compete with offers on price, speed, and quality. Want your podcast transcribed? Post the job and watch providers bid:
// Your request: "Transcribe this 2-hour podcast"
// DVM A responds: "50 sats, 30 minutes, 99% accuracy"
// DVM B responds: "40 sats, 45 minutes, includes speaker identification"
// DVM C responds: "Free, 2 hours, learning model needs training data"
When DVMs Aren't the Answer
While DVMs offer compelling advantages for many use cases, they're not a universal replacement for traditional APIs. The event-based communication model introduces inherent trade-offs:
Immediate Response Applications: Most traditional APIs provide instant responses over HTTP. DVMs communicate via Nostr events that must propagate through relays, introducing latency and are subject to relay rate limiting.
High-Frequency Operations: Applications that make thousands of rapid API calls per second (like algorithmic trading, real-time monitoring, or live search suggestions) benefit from HTTP's direct connection model rather than event propagation through relay networks.
Real-Time Data Systems: This is where APIs and DVMs are more similar than different. For applications requiring live data streams (trading platforms, live chat, collaborative editing), traditional APIs are typically used to authenticate and coordinate WebSocket connections—where the actual real-time communication happens. In the same way, DVMs could coordinate WebSocket setup equally well, and they may reduce authentication requirements because requests are already signed by users as part of the Nostr event format.
Looking Forward
DVMs represent a fundamental shift from platform-dependent APIs to protocol-native computation. This enables possibilities that centralized systems struggle with:
Permissionless Innovation: No gatekeepers, no approval processes, no asking for access. If you can build it, you can offer it. The traditional barrier between consuming services and providing them simply disappears.
Infrastructure as Protocol: Computing services become as accessible and unstoppable as email—a public good that no single entity can control or shut down.
The DVM Protocol is Shifting
We've been hard at work debating about how to best improve the DVM protocol. Today's DVM ecosystem is still largely similar to how it was when @pablo originally conceived of the idea more than 2 years ago. And there are a number of DVM protocol upgrades coming soon, as well as new recommendations for how to build DVMs to play nicely with clients and relays. For now, check out these projects where you can browse existing DVMs: stats.dvmdash.live/kind-stats, nostrhub.io/dvm, noogle.lol
🙏 If you're a Nostr dev, can you spare 5 minutes to take the Nostr Developer Survey? It's at
plus the following appended to it...
1qvzqqqr4mqpzpzstdnhjclj25jdmd0xf3uqsa7cv37lcey3p97j0cxwj0re865k3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qqx2e6k66j6tgd6396x
sorry, formstr links don't show well in clients yet, best I can do