dataMachine
dataMachine is interesting because it sits where AI chat, Nostr search, DVM jobs and Lightning payments meet. It is also a case where the first practical question is availability: verify the service before you add funds or depend on it.
What dataMachine really is
dataMachine is best understood as a Nostr-adjacent AI playground, not as a normal social client, not as a wallet and not as a finished Nostr protocol standard. It came from Unleashed.chat, a chat interface for AI models that later moved toward a broader identity: multiple models, Nostr live search, uploaded data, code analysis, DVM compatibility, MCP compatibility and Lightning-paid usage.
That makes it useful to readers because it shows a direction many Nostr builders care about: AI services that can use public Nostr data, be paid with sats, connect to a user's wallet through NWC and eventually publish or fulfill DVM jobs. It is not just another chatbot name in an app list. It sits at the boundary between AI search, paid compute and Nostr's marketplace ideas.
The caution is equally important. As of the June 13, 2026 check, the normal live domain `datamachine.ai` redirected to Coinkite, `unleashed.chat` redirected through dataMachine and then Coinkite, and `rundvm.com` did not resolve. That does not erase the project's history, but it changes the practical advice. You should verify the live service before treating any old directory card, screenshot or podcast note as current.
The status check is part of the product
With some Nostr projects, the article can begin inside the codebase. dataMachine is different. No public official repository was found during the check, and the official domain did not present the expected AI interface from a normal HTTP request. That makes availability itself one of the main facts. A reader who wants to use the service should not begin by connecting a wallet. They should begin by checking whether the app actually loads.
The redirect also creates a brand-verification problem. Coinkite is a real Bitcoin company associated with NVK, but a redirect from an AI product domain to a hardware-company homepage is not a working AI service. It might be temporary, intentional, retired, parked or operationally broken. The public page does not explain the state in a way a new user can rely on.
That is why this profile treats dataMachine as a project record rather than a green-light recommendation. The interesting parts are still worth documenting: Unleashed.chat, the rebrand, the NWC integration, the claimed AI playground features, the DVM direction and RunDVM. But the first user action is verification, not signup.
From Unleashed.chat to dataMachine
Bitcoin.Review episode 92 covered an Unleashed.Chat update on February 11, 2025. The show notes said users could access the DeepSeek R1 32B model, with data remaining stored locally in the user's browser. The same note said future updates aimed to integrate DVM, API, Nostr search and web search while improving speed. That is the clearest public snapshot of the earlier Unleashed.chat direction.
A month later, Bitcoin.Review episode 93 recorded the rebrand: Unleashed.chat became dataMachine and enabled Nostr Wallet Connect. NoBSBitcoin's Good Morning Bitcoin entry from February 27, 2025 described the same change as a move toward a full AI playground rather than just a chatbot. Those sources agree on the direction even if they do not expose the underlying implementation.
The name change matters. Unleashed.chat sounds like a chat product. dataMachine points at work: models, files, search, DVM tasks, API access and paid computation. It suggests a tool that should help you ask questions over live Nostr content, uploaded material or code, then potentially pay for the work using Lightning.
The public feature claim
The indexed dataMachine social profile describes the service as an AI playground where users own their data, with privacy, speed, DVM and MCP compatibility, Nostr live search, uploaded data, Git-pulled code analysis and multiple models. That is a strong claim set. It mixes user-facing AI chat, developer workflow, Nostr search and protocol-level compute marketplace language.
A reader should separate those claims into testable parts. Multiple models can be checked by the model selector. Local data storage can be checked by documentation, browser storage behavior and account recovery behavior. Nostr live search can be checked by searching for a recent note and comparing relay results. NWC support can be checked by creating a tiny app connection. DVM support can be checked by looking for real NIP-90 job events or a DVM endpoint.
Without a working public app and documentation, each claim remains partly historical. That does not make the project fake. It means the burden shifts to current verification. In a payment-enabled AI product, old feature lists are not enough.
Nostr live search is the useful hook
The most Nostr-specific user feature is live search. A generic AI assistant can answer from training data or web search. A Nostr-aware assistant should be able to pull recent notes, posts, npubs, events or relay-discovered material into the prompt context. That is useful for finding what people are saying now, summarizing a thread, checking a project announcement or comparing different Nostr clients' relay views.
The hard part is that Nostr search is not a single database. Events live across relays, clients use different outbox and search strategies, some relays are paid or filtered, and deletion or edit semantics are limited by relay behavior. An AI app that says it has Nostr live search should tell you which relays it queries, whether it uses a search index, whether it respects mute or web-of-trust choices, and whether it shows source event links.
For dataMachine, this is one of the places to test first if the service returns. Ask about a recent event you can verify in another client. Check whether it cites Nostr event IDs, relay hints or links. If it gives a polished answer without source events, treat it as an AI summary, not as a reliable Nostr archive.
DVM is the bigger protocol story
DVM means Data Vending Machine. NIP-90 defines an interaction where customers publish job requests, service providers process data and results come back as Nostr events. The NIP reserves kind ranges for job requests, job results and job feedback. It also describes payments through amount tags, BOLT-11 invoices and zaps. The phrase in the spec is blunt: money in, data out.
dataMachine's name fits that world. An AI system can be a DVM provider by taking a prompt, file, URL or event as input and returning a summary, answer, transcript, classification or generated artifact as a paid result. It can also be a DVM client by discovering service providers and paying them. If dataMachine wanted to be more than a chatbot, DVM is the natural Nostr-native path.
The practical state is more limited. No current live DVM endpoint was verified during this check, and `runDVM.com` did not resolve. NoBSBitcoin reported in March 2025 that RunDVM.com was a playground for testing Nostr DVMs by Datamachine.ai, but the domain was not reachable in the June 2026 check. Treat DVM support as historical or unverified until real events, docs or a live playground are visible.
RunDVM shows the experiment
RunDVM is important because it points to developer testing rather than only end-user chat. A DVM playground would let people create, inspect or run NIP-90 jobs, see job feedback events, test payment-required behavior and watch result events. That kind of surface is valuable because DVMs are hard to understand from a whitepaper alone.
The NoBSBitcoin item from March 2025 said RunDVM.com provided a playground for testing Nostr DVMs by Datamachine.ai. That is a concrete clue about the team's intended direction. It also ties the project to NIP-90 more directly than a vague AI description would.
The missing live DNS result changes the advice. If RunDVM returns, test it as a protocol workbench. Check whether it publishes job requests in the 5000-5999 range, whether results come back in the 6000-6999 range, whether status events use kind 7000, whether payment requests are explicit and whether failed jobs leave clear traces.
NWC made the payment path real
Bitcoin.Review episode 93 says the rebrand to dataMachine also enabled Nostr Wallet Connect. The NWC account's Nostr post about the ecosystem map likewise described Unleashed.chat as an AI-category app that lets users connect a wallet of their choice and pay per usage within the app. That places dataMachine in the NWC payment ecosystem rather than only in the AI-app ecosystem.
NWC matters because it lets an app request Lightning wallet actions without becoming the wallet custodian. The app receives a connection string or app connection, then wallet-side permissions and budgets decide what can happen. For an AI service, that is a natural way to pay for model calls, DVM jobs, search, file analysis or API usage without credit cards.
It also creates obvious risk. A user may connect a wallet because the app feels like chat, then forget that a payment credential is involved. If dataMachine returns, the safe setup is the same as with other NWC apps: create a dedicated app connection, set a tight budget, use the minimum permissions and revoke it when testing ends.
NWC and DVM are not the same thing
It is easy to blur NWC and DVM because both involve Nostr and Lightning. They solve different problems. NWC is an app-to-wallet protocol. It lets an application ask a wallet to create or pay invoices and receive wallet information according to permission. DVM is a compute marketplace pattern. It lets a customer request processing and a service provider return data.
dataMachine appears to have touched both worlds. NWC paid for usage inside the app. DVM described the intended market shape for AI jobs. A mature version could use NWC to charge a user's connected wallet while also publishing DVM jobs or results over Nostr. But those are separate flows that should be visible separately to the user.
That separation matters for auditing. If you pay for a model call inside a web app, where is the invoice, who receives it, and is there a NIP-90 job event? If you request a DVM job, which event is the request, which service provider answered, and what payment proof exists? A good app can hide complexity from casual use, but it should not hide it from verification.
The local-data claim deserves proof
The February 2025 Bitcoin.Review note said Unleashed.chat users could access DeepSeek R1 32B while all data remained stored locally in the user's browser. That is an attractive privacy claim for AI chat. If true and implemented carefully, it means conversation state, uploaded files or account context may not be stored on the server in the usual SaaS way.
But local browser storage is not the same as end-to-end privacy. The model provider may still receive prompts. Search requests may still go to remote services. Uploaded files may still be sent for analysis. Browser storage can be cleared, synced, inspected by local malware or lost when a device changes. The exact flow matters more than the slogan.
If dataMachine becomes reachable again, test privacy claims with developer tools and documentation. Check whether prompts leave the browser, which model endpoint is called, whether file content is uploaded, whether Nostr search queries are logged, and whether account balances or wallet connections are tied to an external identity. Local storage is useful, but it needs a clear threat model.
MCP compatibility needs evidence
The indexed profile description says dataMachine is MCP compatible. Model Context Protocol is a standard for exposing tools and context to LLM clients. In the Nostr world, MCP becomes interesting when an AI client can discover paid tools, call remote services or bridge into DVM-like jobs. The idea is strong: tools should be callable, paid and discoverable without central registries.
The public evidence for dataMachine's MCP compatibility was not enough to verify an implementation during this check. No MCP endpoint, package, repository or tool manifest was found. That does not mean none existed, but a reader should not assume MCP functionality until a client can connect, list tools and call them.
This is the same standard used for Alby MCP Server, where the source code registers concrete tools and the README documents transports. For dataMachine, the article can explain the claim and why it matters, but it cannot treat MCP support as proven current behavior without a working endpoint.
Payment balances are a special risk
AI services often use credits. Lightning and NWC can make those credits easier to buy, but easier payment does not remove custody and refund questions. A Stacker News discussion from July 2025 asked whether dataMachine was down and complained about account-based LLM credits that could not be withdrawn. That is a community report rather than a definitive audit, but it points to the right question.
If a service lets you prepay for model usage, the user needs to know whether the balance is custodial credit, direct wallet spending, non-refundable prepaid compute or a withdrawable balance. NWC can reduce custody if each usage is paid directly from the user's wallet. Account credits introduce a different trust model because the service owes future compute or a refund.
Before funding dataMachine or any similar app, test with the smallest amount possible. Look for terms, invoices, usage history, remaining balance, refund policy, operator identity and support channel. If a service is unavailable, do not assume an old Lightning payment can be recovered.
Name collisions are real
There is another live `datamachine` brand at `datamachine.io`, but it is a different AI knowledge-platform product. It should not be confused with `datamachine.ai`, Unleashed.chat, Nostr DVMs or NWC. This matters because search results can mix unrelated AI products under the same phrase.
The correct project in the Nostr Apps Hub is the `datamachine.ai` project formerly known as Unleashed.chat. It is associated with AI playground claims, Nostr live search, DVM direction and NWC payments. When researching it, use the exact domain, the old `unleashed.chat` name and Nostr/Bitcoin sources. Do not import features from the unrelated enterprise knowledge product.
The current redirect to Coinkite adds another layer of confusion. Coinkite is not a dataMachine product page. If you land on Coinkite from a dataMachine URL, you have not found the working AI app. You have found the current domain behavior that needs explanation before use.
How to test it if it returns
Start without money. Load the app, check the domain, verify HTTPS, inspect the page title, and look for current documentation. Confirm whether login requires Nostr, email, a local browser profile or a service account. Ask a harmless question and see whether the answer cites model, source or Nostr event references.
Then test Nostr search. Search for a recent note you can find in another client. Check whether dataMachine returns the right author, date and event. Look for relay hints or links. Compare results with a normal Nostr search service. If the answer is not traceable, do not use it as a factual search engine.
Only then test payments. Create a fresh NWC connection with a tiny budget. Do not use your main wallet connection. Pay for a tiny task, then inspect wallet history, app balance, invoice memo and refund or support flow. Revoke the connection after the test. If any step is unclear, stop there.
What would make dataMachine strong
A strong dataMachine comeback would publish clear docs, show current operator status, expose exact NWC permissions, document credit handling, and show whether DVM jobs are real NIP-90 events. It would cite Nostr sources inside search answers, explain which relays or indexes are used, and let users export or delete local data.
For DVM work, the strongest signal would be transparent event flow. A user should be able to see the job request, feedback, payment request and result event. A developer should be able to reproduce a job with another NIP-90 tool. A service provider should know how to advertise capabilities through NIP-89 or a related discovery path.
For MCP work, the strongest signal would be a public endpoint or local package that lists tools, versions, permissions and transport. The claim does not need to be flashy. It needs to be inspectable.
Who it fits
If available and documented, dataMachine would fit Nostr users who want AI search over live Nostr content, builders who want to understand DVM workflows, and Bitcoin users who want to pay for AI usage with sats rather than credit cards. It would also fit researchers who want to compare how AI apps handle Nostr events as source material.
It does not fit a user who needs dependable production access today unless the live service has been rechecked and found working. It does not fit a user who wants to deposit a meaningful prepaid balance without clear withdrawal or refund terms. It does not fit a privacy-sensitive user until the local-data claim and model-provider path are verified.
The right first posture is curiosity with a test wallet. dataMachine is conceptually important because it shows where Nostr, AI and Lightning can meet. But conceptually important is not the same as operationally reliable.
Closeout
dataMachine is one of the more interesting AI names in the Nostr map because it points beyond chat. It hints at a stack where live Nostr search, open-source models, uploaded files, code analysis, NWC payments, DVM jobs and maybe MCP tools can share one workbench. That is the right kind of ambition for a network built around portable identity and small payments.
The current state keeps that ambition grounded. The domain behavior, unreachable RunDVM domain and lack of a public codebase make dataMachine a verify-first project. Readers should not connect wallets or add credits on the strength of old ecosystem mentions. They should check the live app, payment path, DVM evidence and support channel from scratch.
If the service comes back with clear docs and working Nostr/DVM flows, it deserves another close look. Until then, the useful lesson is the shape of the idea and the checklist it forces: AI output needs sources, paid compute needs invoices, wallet connections need limits, and Nostr-native services need observable events.
Sources worth opening
Open the current domain first and verify what it does today, then read Bitcoin.Review episode 92 and 93, NoBSBitcoin's rebrand and RunDVM notes, the NWC profile note that described Unleashed.chat as an AI-category NWC app, and the NIP-90/NIP-47/NIP-89 specs. The useful question is not only what dataMachine wanted to become. It is whether the live endpoint, NWC payment path, DVM path, data-retention promise and account-balance model are currently working.
- dataMachine live domain
- Unleashed.chat old domain
- dataMachine X profile
- Bitcoin.Review episode 92
- Bitcoin.Review episode 93
- NoBSBitcoin Good Morning Bitcoin February 27, 2025
- NoBSBitcoin Block 886042
- NoBSBitcoin Block 889101
- NWC Nostr profile and ecosystem notes
- Stacker News availability discussion
- getAlby awesome-nwc list
- NWC official website
- NWC developer docs
- NIP-47 Nostr Wallet Connect
- NIP-90 Data Vending Machine
- NIP-89 Recommended Application Handlers
- NIP-57 Lightning Zaps
- NIP-96 HTTP File Storage Integration
- Nostr Data Vending Machines repository
- data-vending-machines.org current domain check
- NostrDVM framework
- nostr-dvm on PyPI
- DVMCP repository
- n8n AI Agent for DVM MCP
- Model Context Protocol documentation
- MCP transports documentation
- Alby MCP Server
- Alby PaidMCP repository
- Nostr.com DVM explainer note
- NIP-90 encryption discussion
- NIP-90 job result discussion
- NIP-90 version 2.0 discussion
- Different product: datamachine.io
