ContextVM

ContextVM is a decentralized protocol that enables Model Context Protocol (MCP) servers and clients to communicate over the Nostr network. It uses Nostr as a secure, distributed transport layer—leveraging cryptographic keys for identity, decentralized discovery, and Bitcoin-powered micropayments.

Rather than relying on centralized infrastructure like domains, OAuth, or cloud hosting, ContextVM allows anyone to run or access services using only Nostr and a internet-connected device. It transforms any computational service into a discoverable, accessible, and monetizable resource—while preserving privacy, security, and user sovereignty.

Public Key

npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm

NIP-05 Address

contextvm.org

Profile Code

nprofile1qqsxkduqau5h9eeaxu9cfgl9rea2nt35haqjjwxul0vuta3myg2pdjqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsvynql7

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm

Show more details

Last Notes

2026-03-26 16:04:18 UTC

Setting up an MCP server to be used by AI agents requires a lot of skills, managing domains, OAuth, port forwarding.
ContextVM changes the game, reducing the burden for running a remote MCP server!

2026-03-25 16:52:10 UTC

Just released a new version of our TS SDK (0.7.6).
This update adds support for dynamic authorization on the server through two new optional callbacks: `isPubkeyAllowed` for runtime pubkey validation and `isCapabilityExcluded` for dynamic capability exclusion from the allowed pubkeys check. These async callbacks complement the existing static allowlist and exclusion configurations, enabling more flexible authorization policies. We have also renamed the `isPublicServer` option to `isAnnouncedServer` to better reflect its purpose of publishing public announcement events on Nostr for relay‑based discovery. The old option is deprecated but still supported for backward compatibility.
Docs and skills updated! Happy building! 🦾

2026-03-25 15:58:47 UTC

GM!
As you know, we are trying to get the word out on ContextVM to the broader internet by launching our Substack!
If you are already on the platform feel free to subscribe! We want the project to grow outside of our niche and we need your help to bootstrap the publication!
Here is the link: https://contextvm.substack.com/

2026-03-24 21:15:48 UTC

Just another quick demo. Same thing, but this time, instead of using the CVMI `call` command to access the server, we are connecting to the server as if it were a locally running MCP. This is possible thanks to the CVMI `use` command, which allows you to use CVM servers anywhere you can configure MCP servers.
https://mibo.eu.nostria.app/3207606b2502451db13fcc29fe75558194de812bfc33fe1034a04b43961fbabe.mp4
#nevent1q…wfsk

2026-03-24 20:09:22 UTC

Just a little but powerful update to our site. Since we merged CEP‑17 for server‑relay announcements, we have updated our site to accept npubs and nprofiles for servers. You can now use these identifiers in the URL or in the search bar.
It will resolve relays for the server in this order:
1. Relay hints when the identifiers are nprofiles
2. Server relays (from 10 002 events)
3. Hard‑coded relays, if none of the previous ones exist
This really improves discoverability and strengthens decentralization capabilities.
We also added an extra goodie: NIP‑05 resolution, so if your server pubkey is associated with a NIP-05 address the site will resolve it. For example, you can use
https://contextvm.org/s/relatr@contextvm.org
or, since the host domain matches the NIP‑05 domain, you can even omit the domain part:
https://contextvm.org/s/relatr
Cool right? 😎

2026-03-23 21:40:56 UTC

Just testing this new 'Am I Exposed?' public server someone made online 👀 This is a Bitcoin on‑chain privacy scanner. We wanted to test it to see how it works. This is a short demo of using it together with the CVMI call command. It’s quite straightforward; we didn’t need to touch any other configuration files, just add an alias. The complete process and demo are in this video.
https://mibo.eu.nostria.app/e99accc3ff571f264dcdd73620ddf46ef94f55e018762c470d3e7b270a274a9a.mp4
#nevent1q…84y4

2026-03-22 11:06:57 UTC

- reply

There is loads of garbage, that's why we hardened the writing policies, also connections openning too many reqs concurrently. It is working great so far

2026-03-22 10:28:48 UTC

- reply

Basically we replaced the relay we were using with Strfry and hardened some writing rules. Strfry also has some sane abuse protection out of the box.

2026-03-21 19:39:48 UTC

Lazy yet productive Saturday. Stabilized relays from the spam attack and forked Strfry during the process. Contributed to https://ants.sh by @npub1der…xzpc to add relatr for search capabilities. Touched grass

2026-03-21 16:33:08 UTC

🚀
#nevent1q…3u3s

2026-03-21 11:55:07 UTC

This should be fixed now 🫡 As a side effect, we forked Strfry to add a convenient way to deploy a relay and some write policies to harden it for CVM usage. https://github.com/ContextVM-org/strfry-cvm
#nevent1q…0mym

2026-03-20 12:31:44 UTC

Spam attack in our relays. Fixing now

2026-03-19 11:07:15 UTC

A simple, but powerful concept
#naddr1qv…eanj

2026-03-18 17:37:39 UTC

- reply

Hmm, what is your Node version? Some older versions might not have ws defined globally. In any case, we just pushed a new version of cvmi that polyfills this. Please test 0.2.6 and let us know, your feedback will be greatly appreciated 🙏

2026-03-18 15:24:48 UTC

Use it from contextvm.org or through the CVMI CLI.
1. Configure an alias for easy calling:
`npx cvmi config add ots @nprofile…5kv0`
2. OTS an event:
`npx cvmi call ots ots_event target=<event-id‑nevent‑naddr>`
3. Verify the attestation and get its state:
`npx cvmi call ots verify_ots target=<event-id‑nevent‑naddr>`
If you want, you can configure it as an MCP in your preferred agentic framework; just set `npx cvmi use @nprofile…5kv0` in your MCP configuration.
#nevent1q…6c2m

2026-03-18 14:58:30 UTC

🕰 New public server available! 🕰
This is an OTS client that lets you easily Open Time Stamp any Nostr event. The usage is straightforward: two tools, 'ots_event' to create an attestation for an event, and 'verify_ots', which lets you verify the OTS attestation and its state in the time chain.
With this server, you or your agents can easily OTS any Nostr event. Here’s a brief demo:
https://video.nostr.build/74e0a7eaebda78e3ae27c48b53adfbdac71efa2da606fcb665fa496460aa8cfb.webm
The project’s code is open source, and you can run your own instance if you wish. By default it uses public Bitcoin nodes to verify the attestations, so you don’t need to run your own node.
https://github.com/ContextVM-org/ots-cvm
Server page: https://www.contextvm.org/s/e1c1c32729cbd542c9b9ce7ee6e421c434e07835228020c4f57140782f02496a
You can use this service for free, but public OTS servers need to cover operating costs. If you’d like to donate, please refer to opentimestamps.org.

2026-03-17 15:15:50 UTC

🌍 New issue of the ContextVM world newsletter 🌍
In today’s update we cover CEP‑17, the latest specification change to the CVM protocol. This change allows MCP servers to announce the relays for establishing connections, making it easier for clients to discover them. We also discuss new CVMI capabilities and other news from the ecosystem, plus demos and a new Rust SDK that is currently being built. Hope you enjoy it!
Don’t miss any issue, subscribe to our Substack.
https://contextvm.substack.com/
#naddr1qv…z2d5

2026-03-16 18:49:42 UTC

Make your MCPs over Nostr, composable, token efficient, easy 🚀
#naddr1qv…eanj
#mcp

2026-03-11 23:07:19 UTC

- reply

LG! 🚀

2026-03-11 22:49:55 UTC

- reply

We'll write a spec draft soon so we can move forward with that :)

2026-03-11 21:55:39 UTC

- reply

https://image.nostr.build/19f28ef0527a534876244ffd331799af566c0a965f04e07f1af7ae321cc958b5.png

2026-03-11 17:34:58 UTC

The cool part about the demo, ahead of the reduction in token usage compared to building this with the MCP interface, is the progressive disclosure. The LLM didn’t know anything about Earthly, Wolfram, or Relatr, and it discovered tools and usage as needed. No extra tool schemas were loaded unnecessarily, no bloated context window, just organic discovery and usage.
#nevent1q…4f6s

2026-03-11 17:15:08 UTC

- reply

@npub182j…m4rf @npub1jss…fmzy

2026-03-11 17:12:08 UTC

We’re thrilled to roll out CVMI CLI 0.2.x, adding two powerful commands: `call` and `discover`.
`call` lets you invoke CVM servers straight from the command line, perfect for debugging or plugging into agents. No MCP config or schema loading needed; responses are cleaned to save tokens. Save servers with aliases and run them like `npx cvmi call relatr`.
`discover` query relay announcements to list available tools, just run `npx cvmi discover`.
Demo: query Earthly and Wolfram for the Eiffel Tower’s address and height
https://video.nostr.build/14f2338be8a83b3e489233fbfcc359956eabb45d2ffee88417c72e1a0aaf7b4f.webm
Get Sovereign Engineering pubkey using Relatr.
https://video.nostr.build/e6560296c095847b5e5c20ea0d053f3c74bde4145f0ebe1f2bfd0a30721f85cf.webm
These upgrades make CVM servers far easier to use and compose, cut token costs versus MCP, and give developers a simple way to debug, script, or integrate CVM services from the command line.
Some screenshots of this new capabilities:
https://image.nostr.build/9229de75630bcec299836fd1b77dded7809b3c31ba3784f7f7d4b1b434a7203d.png
https://image.nostr.build/afae05aeb9be14f2872f11142f957530dff904f14e8697fd136b3de994236079.png
https://image.nostr.build/afae05aeb9be14f2872f11142f957530dff904f14e8697fd136b3de994236079.png

2026-03-10 15:51:32 UTC

- reply

Just wow! This is seriously cool. I think you did the first integration of chat with CVM tools on the web to date. Really awesome!

2026-03-10 12:22:18 UTC

🚀 CEP-17 is now merged into ContextVM, and it is available in the ts SDK from v0.7.x.
https://docs.contextvm.org/spec/ceps/cep-17/
This is a meaningful step forward for resilience. With CEP-17, servers can publish the relay list they use following NIP-65, and clients can resolve connection paths more intelligently: first from explicit configuration, then from relay hints embedded in `nprofile`, and then if nothing is define from relay list discovery. That makes connectivity more robust by default, reduces dependence on central points of failure, and avoids hardcoded relays in normal client setup.
It also makes client configuration simpler. In many cases, you can now just pass an `nprofile` string and clients will use its relay hints directly; if those are not available, it can fall back to CEP-17 discovery through NIP-65 relay-list metadata.
The reference implementation is already in the SDK, the docs and skills have been updated, and contextvm.org now surfaces these new `nprofile` identifiers as well. Small change in surface, big improvement in how reliably clients can find and reach servers across a more sovereign network 🚀

2026-03-09 08:22:00 UTC

We’re so back. DNS problems have been resolved, sites and relays are reachable again 🚀
#nevent1q…my5u

2026-03-07 16:54:26 UTC

We've been having problems with DNS and registrars, which is why our ContextVM websites are down. We have a pending transfer that should be resolved soon. In the meantime, we’ve deployed the main site and documentation on GitHub Pages as a backup alternative. The links are:
- https://contextvm.github.io/contextvm-site/
- https://contextvm.github.io/contextvm-docs/
Sorry for the inconvenience. CVM servers are still running, and clients can still connect using any relay, there’s no disruption there 🦾

2026-03-05 09:28:38 UTC

Nostr == WS == CVM.
Connecting to servers, calling tools, etc, everything has worked over WebSockets since day one with ContextVM 🚀
#nevent1q…xla3

2026-03-03 15:49:58 UTC

A new issue of our biweekly newsletter is out! 🚀
"Ephemeral Is Better — The ContextVM World #3"
Available in nostr and substack:
https://contextvm.substack.com/p/ephemeral-is-better-the-contextvm
#naddr1qv…8e0w

2026-02-27 15:20:07 UTC

Continuing with NIPs, we have just added a pr for CVM to the NIPs repository. We wrote this NIP to describe the conventions for transporting Model Context Protocol (MCP) messages over Nostr. We deliberately kept the NIP thin on details that already live in the full CVM spec; it exists to make CVM discoverable in the Nostr ecosystem and to show that CVM is just Nostr, using the same primitives any Nostr app uses.
https://github.com/nostr-protocol/nips/pull/2246

2026-02-27 12:18:56 UTC

We just opened a PR in the NIPs repo that includes this convention for ephemeral gift wraps. Perhaps other developers will find it a valuable building block
https://github.com/nostr-protocol/nips/pull/2245
#nevent1q…c6mq

2026-02-26 11:41:25 UTC

Ephemeral giftwraps improve your privacy and hygiene on relays, as nothing is persisted there. CVM messages use ephemeral events when the traffic is not encrypted, but when encrypted, they wrap the ephemeral events in a gift wrap which uses a regular kind. So even if the wrapped event is ephemeral, its envelope isn't. Ephemeral gift wraps solve this; everything is encrypted end-to-end, relays just route blindly, nothing is persisted, no collect now, decrypt later 🥷🏼
#nevent1q…e26y

2026-02-25 16:30:26 UTC

CEP-19 is live with ephemeral gift wraps 🚀
In plain terms, you can now send end-to-end encrypted MCP messages that do not have to be stored on relays. This is a significant upgrade for privacy, as your messages can travel through public infrastructure without becoming permanent data. The kind used by CVM is ephemeral (25910), and when you use encryption, this ephemeral kind is gift-wrapped (NIP-59) in a regular event kind that is persistent on relays (1059). With this update, servers and clients can use a new kind for ephemeral gift wraps (21059). It is exactly the same as the regular kind (1059) but is ephemeral, so it is not stored on relays. This also improves metadata hygiene: relays can forward messages without needing to retain payloads.
How it works:
CEP-19 introduces an ephemeral gift-wrap kind alongside the existing persistent kind. Both sides advertise their support, and when both do, the transport prefers ephemeral wrapping while maintaining backward compatibility with older clients.
Configuration in the SDK:
This feature is available from version v0.6.0. Just set the transport’s `GiftWrapMode` option to `EPHEMERAL` to always use ephemeral gift wraps, `PERSISTENT` to force legacy behavior, or `OPTIONAL` to negotiate ephemeral wrapping when supported. The default remains compatible with existing relays and clients, making this an opt-in privacy upgrade without being a breaking change.

2026-02-25 13:52:19 UTC

Hey Nostr! We're excited to share that we're working on getting more eyes on ContextVM and its development. We just published our first post on Hacker News. If you're on the platform, we'd love for you to check it out, share your thoughts, or help spread the word. Every bit helps, so please join us in growing ContextVM! 🚀
https://news.ycombinator.com/item?id=47151294

2026-02-25 08:37:29 UTC

- reply

Looks dope!

2026-02-24 10:30:38 UTC

Now that payments are in place, we are going to work on:
- CEP-19 for ephemeral gift wraps: https://github.com/ContextVM/contextvm-docs/issues/19, and
- CEP-17 for servers relay list: https://github.com/ContextVM/contextvm-docs/issues/17.
Both CEPs are quite minimal but yet beneficial for the ecosystem. CEP-19 provides better privacy guarantees, as servers and clients will be able to use ephemeral gift wraps for encrypted communications. Currently, they use regular gift wraps, which are regular events, and even if the events inside are ephemeral, they are wrapped in a regular envelope. CEP-17 defines how servers can announce relay lists (NIP-65) to improve discoverability.
Simple but powerful! LG!🚀
After this iteration we will come back to CEP-15 introducing common tool schemas, which is a bigger one
https://github.com/ContextVM/contextvm-docs/issues/15

2026-02-23 22:13:35 UTC

We've just released a new version of our SDK, now CEP-8 implementation is now complete, end to end, we’ve added the missing piece for LLM aware spending
CEP-8 gives us the wire protocol for paid MCP capabilities, servers request payment, clients settle, both sides get explicit confirmation. What was missing was a clean way to make consent programmable. This release adds a single paymentPolicy hook at the client boundary, a little yet powerful new addition. Your host environment decides whether a charge proceeds: a deterministic budget, a per-tool allowlist, a terminal prompt, or a full LLM-based policy engine. One hook, any pattern.
Google's AP2 addresses a similar problem, but it's an ambitious multi-actor framework involving Shopping Agents, Credential Providers, and cryptographic Mandates passed across multiple parties, quite complex. Our take is different, CEP-8 provides the payment rails, Nostr anchors every request to a cryptographic identity at the transport level, and consent is a composable local primitive. Simpler to integrate, and versatile enough to fit whatever your host needs to do.
This our take on agentic payments, simple, versatile, composable, no vendor lock ins

2026-02-22 10:19:22 UTC

- reply

Yes!

2026-02-19 22:10:21 UTC

After a few days experimenting and receiving feedback around CEP‑8 payments, we enhanced their SDK implementation, making payments more reliable and consistent. We’ve just released a new feature that supports additional use cases, such as servers with prepaid balances, top‑up accounts, or separate payment management. This feature lets you waive a payment via the server’s resolve price callback. With this update, payment processing is far more powerful 🚀
Docs and skills have been updated accordingly. Happy building :)
https://image.nostr.build/fbd347f5e537efc79947c1d91acb930cc32ba229624ec17b3380e8be5cf6469b.png
Docs: https://docs.contextvm.org/ts-sdk/payments/overview/#waiving-payment-prepaid--subscription-models
Skills: npx cvmi add --skill payments, or npx skills add contextvm/cvmi --skill payments

2026-02-19 12:09:42 UTC

Get it fresh in your inbox every two weeks!
#nevent1q…c4ug

2026-02-18 13:00:33 UTC

GM Nostr!
Our newsletter, The ContextVM World 🌍, is now live on Substack:
https://contextvm.substack.com/
While ContextVM is built on Nostr and will continue to publish natively on Nostr, our goal is to reach a larger audience outside of Nostr to have more builders leveraging our protocol!
Feel free to subscribe to our Substack and to share our newsletter with the world!

2026-02-17 15:52:27 UTC

The second issue of "The ContextVM World" is out! Hope you enjoy it 💛
#naddr1qv…vpzd

2026-02-17 14:59:11 UTC

- reply

Let's keep building! 🚀

2026-02-17 14:58:48 UTC

- reply

Thanks Tim! appreciate your words 💛

2026-02-17 14:46:26 UTC

Thanks so much to openSats for this opportunity! We'll keep pushing the boundaries of this new paradigm 💛
#nevent1q…hxrk

2026-02-17 11:04:06 UTC

Protocols over Platforms is the mantra at the core of CVM
https://notnotp.com/notes/use-protocols-not-services/

2026-02-17 10:50:42 UTC

https://lemonade.contextvm.org
#nevent1q…rf53

2026-02-16 17:21:25 UTC

These are badges are real, you can check them here as well: https://nostrsigil.com/badges/naddr1qvzqqqr48ypzpl0zzdglhjrqfsnaelea2plcaxc4gw8nh5zqj09rl4tu66ekckxsqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsqyrvv4kk7mnpv3jj6mr9vajkuernaqgdnx
#nevent1q…y4t3

2026-02-16 17:13:29 UTC

🍋 Introducing Lemonade Legends, our newest teaching project that demonstrate how to use CEP-8 in a tangible and fun way!
Do you want your lemonade legend badge? https://lemonade.contextvm.org
This is a server that mints nostr badges with dynamic pricing: 21 sats on day 0, +21 sats each day after. A live experiment in paid capabilities, SQLite accountability, and dual APIs (humans via UI, agents via MCP). The idea behind this project was to create a new and fun educational resource for the CVM ecosystem. You can read our blog post here: https://contextvm.org/blog/lemonade-legends or in nostr.
What we did for this project:
✨ Server + Svelte app, both open source
✨ Step-by-step blog post walking through the code
✨ Copy-paste ready patterns for your own paid tools
Dive in → https://contextvm.org/blog/lemonade-legends
Server → github.com/ContextVM/lemonade-legends
Site → github.com/ContextVM/lemonade-legends-site
What will you build with CEP-8? 💛
#lemonadelegends #contextvm #cep8 #nostr #bitcoin #lightning #opensource
#naddr1qv…t8dw

2026-02-14 15:08:31 UTC

Just pushed a new payment processor for our SDK based on ZAPS!⚡️ It only requires an LN address to be used, it couldn't be easier⚡⚡️
https://image.nostr.build/986e254f2b9a960f1d6080be6b74b027bafe22e6619e302fc6837bfc3c84d22c.png
With this new payment processor, our SDK now supports three payment processors based on Lightning BOLT11: NWC, LNbits, and now ZAPS⚡ To use it, simply update to the latest contextvm SDK.
The only consideration regarding this payment method is that ZAPS can be faked by the provider of your LN address. If you trust the provider of the configured Lightning address, there is no problem, it could even be your own node. However, if you don’t trust the provider, the ZAP receipt alone is not sufficient to prove settlement. This is not a new issue; it has been discussed and is already covered in an appendix in nip-57
Hope you enjoy!⚡️⚡️⚡️

2026-02-13 08:32:03 UTC

- reply

LFG! 🔥

2026-02-12 22:17:33 UTC

- reply

Totally agree. This is why CVM 💛
#nevent1q…myde

2026-02-12 22:15:59 UTC

This is why CVM.
In an agent-mediated world, the shipped feature set matters less than what an agent can discover and compose at runtime. Your real product becomes your callable surface area: reliability, clear schemas, predictable behavior, and the ability to snap into workflows you didn’t design.
That shift makes distribution the new battleground. If discovery collapses into a handful of registries and default tool lists, the ecosystem recentralizes fast, no matter how open the API spec looks.
You can already see the gravity well: MCP’s mainstream path tends to reintroduce old control points, registries anchored to domains, OAuth-based access, and platform-shaped “approved” directories. They’re convenient, but they harden into gatekeeping, and single points of failure.
ContextVM is built to route around that. It runs MCP over Nostr so services are addressed by public keys, routed over relays, and announced publicly without permission. Discovery becomes a network primitive instead of a platform feature. Relays act as decentralized repositories, and curation becomes competitive and plural rather than owned.
We’ve just added payments in a way that composes cleanly with autonomous, per-call usage. If agents can swap tools mid-workflow, pricing has to be as modular as the capabilities themselves, without dragging builders back into accounts, gatekeepers, and permissioned land.
ContextVM’s wager is simple: if agents are going to assemble the future on the fly, the underlying rails for identity, discovery, and payment must be open, permissionless, and censorship-resistant by default.
#nevent1q…cyqu

2026-02-12 20:49:41 UTC

It takes you ~20 LOC to enable payments in your server. NWC + CVM = 🤯
https://image.nostr.build/808074d08ff8c4f5cb0f345ffc2cc89d10a22e156fd9248dd1915600ef32e4e3.png
The code: https://github.com/ContextVM/dummy-paid-server/blob/main/index.ts
#nevent1q…8du5

2026-02-12 20:38:42 UTC

Pro tip: get the CVM skills for payments `npx cvmi add --skill payments -y` Ask your agent to build something profitable, use an NWC connect string, and start monetizing. Quite easy.
Additionally, there is an LNBits backend available in the SDK, and the skills come with documentation on how to build your custom payment rails if you need.
Let's build! 🚀
#nevent1q…ad8v

2026-02-12 15:23:30 UTC

Payments Have Arrived! 🚀
ContextVM now supports payments with CEP-8! Your servers can finally become digital lemonade stands, paid, permissionless services that anyone can run and consume without asking for permission.
This release packs everything you need. The new version of the SDK have everything you need, even ships with Lightning BOLT11 integrations (NWC and LNbits), the ContextVM site now supports payment discovery, cvmi and skills has been updated, and the docs cover the full flow. Want to see it in action? The dummy demo server (https://github.com/ContextVM/dummy-paid-server) shows you exactly how to price and monetize a capability.
https://video.nostr.build/aaa0ef0bb44b55da525e2047b681b4fbd7aa4e5c603bb4fbbd682c5603b21ceb.mp4
Looking forward to hear your thoughts and see what you are building!
Read the docs: https://docs.contextvm.org/spec/ceps/cep-8/
Build a stand. Price a capability. Let value flow.
If you have any question just ask
#naddr1qv…qt6c

2026-02-11 22:02:49 UTC

Payments are coming imminently 🚀

2026-02-10 15:31:34 UTC

Just shipped some clarity improvements to CEP-8 🎯
We are pretty close to getting this done; we just shipped some clarification to the payments spec so some concepts are less ambiguous. The spec now has well-defined PMI (payment method identifier) boundaries, clarifiying what goes in `pay_req`. We've added a recommended PMI registry with precise payload semantics, plus naming conventions to keep things unambiguous as the ecosystem grows.
Also new: optional direct payments for bearer assets. When both parties support it, you can skip the roundtrip, just attach `["direct_payment", "<pmi>", "<payload>"]` to your request and you're done. Good for cashu 🥜
The ongoing implementation remains unchanged, this is all documentation and specification hardening.
Current spec: https://github.com/ContextVM/contextvm-docs/blob/ed71abec7bd93ba1082e67dfc92f0b0bcf618a72/src/content/docs/spec/ceps/cep-8.md
SDK progress: github.com/ContextVM/sdk/pull/24
Feedback welcome!
#nevent1q…ppc5

2026-02-10 11:16:02 UTC

📡 New relay live! wss://relay2.contextvm.org 📡
We were running a public relay at wss://relay.contextvm.org and have now added a new relay to increase redundancy. This new relay is hosted by a different provider in a different location, ensuring that if one provider experiences an outage, the other will remain available. Additionally, there is a third relay operated by @npub1jss…fmzy at wss://cvm.otherstuff.ai
Note: You can use any public relay for CVM stufff, but these three are more optimized as they reject other events not related with CVM and do not store events, they are ephemeral.
We have also added a new section to our awesome repo to make it easy to find these relays: https://github.com/ContextVM/awesome#public-cvm-relays

2026-02-09 16:51:56 UTC

- reply

Great! can you open a pr?

2026-02-09 16:19:32 UTC

- reply

Well, there is no need to add methods for topping up the wallet/nutstash. We should assume the wallet is already plugged in and has funds. If you read CEP-8, the responsibilities of servers and clients are clarified there. tldr; Servers act as payment processors, emitting payment requests and then validating that the payment was done. Clients act as payment handlers, being responsible for paying the requests emitted by the server. The funds that the wallet has available are a separate matter and are better kept out of scope, so there is no need for deposit or withdraw methods.
A way this could work is as follows: the server (payment processor) receives a request for a paid capability. It then goes to the mint it has configured, gets a quote, obtains the BOLT11 invoice from it, and sends the payment request. The client (payment handler) takes the BOLT11 invoice, gets a melt quote for it, and the mint handles the payment. At that point, the server can check its quote status and verify if it's fulfilled. Then the lifecycle is completed. Extra steps could include redeeming the tokens from the quote and storing them either locally or in the NIP-60 wallet.
What do you think?
If there are some concepts that are not clear, we have written a couple of guides and resources to understand how payments work in CVM:
Payments, Paid Servers, and Clients https://github.com/ContextVM/sdk/blob/e2096b7c94658e1f7b5a3f06ad53738d1e3eacea/docs/payments-paid-servers-and-clients.md
Payments Architecture https://github.com/ContextVM/sdk/blob/e2096b7c94658e1f7b5a3f06ad53738d1e3eacea/docs/payments-architecture.md
There is also the spec CEP-8: https://github.com/ContextVM/contextvm-docs/blob/8d0dbfc95a929ac6dd49cab556b18874df758b73/src/content/docs/spec/ceps/cep-8.md
Happy to solve any doubts if you have any!

2026-02-09 15:31:21 UTC

- reply

I haven't checked the dependency tree to be honest. But if you feel comfortable with nostr-tools and there is no need for other new deps, it is preferable. If not, maybe the best option is to create a separate repo for extra payment processors and handlers.

2026-02-09 15:23:44 UTC

- reply

Exactly https://applesauce.build/money/wallet/package.html https://applesauce.build/examples/#/example/wallet/wallet

2026-02-09 15:12:32 UTC

- reply

Amazing! we have nostr-tools as dependency as well. Thanks 🚀💛

2026-02-09 12:52:14 UTC

- reply

Sounds good! Do you feel proficient enough in TypeScript to contribute with a PR? Ideally without introducing more deps, we already have applesauce which it have nip-60 utils as well, If not, we can add it in a future iteration once our PR is finished.
Ongoing PR: https://github.com/ContextVM/sdk/pull/24
Reference from the PR we just merged with the LNbits backend: https://github.com/ContextVM/sdk/pull/25

2026-02-09 12:25:12 UTC

The PR is not even merged yet, and we already have @npub19a8…2ckt contributing an LNbits payment processor and handler 🚀 Thanks so much for the contribution 💛
The PR will ship two payment processors and handlers: NWC for making it work with any wallet supporting NWC, super easy to configure and use. And LNbits, which will allow the use of an LNbits backend as a payment processor and handler.
More built-in payment methods can be added in future iterations. Anyone will be able to create their custom ones as well
#nevent1q…ppc5

2026-02-09 09:34:18 UTC

Very excited for this 🔥 CEP-8 payments are coming to ContextVM, with a reference implementation in our TypeScript SDK. It is shaping up nicely, with a clean design and implementation. The cool part is that nothing changes for operators; the transports will still work in the same way they do today, with no breaking changes. Payments are enabled through middlewares, so the inclusion of payments will not affect current consumers of the SDK in any way. There will be no performance degradation, no API-breaking changes, and maximum flexibility.
Soon, we will release the new version including the new features, along with some guides on how to start monetizing your services. Stay tuned.
In the meantime, you can read the specification at https://github.com/ContextVM/contextvm-docs/pull/9 and follow the progress of the implementation in the SDK at https://github.com/ContextVM/sdk/pull/24 .
Feel free to give us some feedback or ask any questions!

2026-02-05 16:38:36 UTC

CVMI 0.1.9 is out. It includes two minor but necessary features: normalizing quoted command strings so you can pass commands to serve any MCP server inside quotes (e.g., `cvmi serve "npx -y …"`), and adding environment‑variable support to the spawned MCP server using flags such as `cvmi serve -e LOG_LEVEL=debug …`. They aren’t the flashiest features, but they are essential for real world scenarios. Thanks, @npub1ye5…knpr, for pointing them out 🚀

2026-02-05 14:53:40 UTC

CEP-8 payments is becoming a reality. Quite soon, anyone, humans or machines, will be able to monetize their services and computation over Nostr. Permissionless, unstoppable, robust, decentralized services, this is how we win. Little by little, all the pieces are coming together 🚀
If you are interested in the discussion, dig in: https://github.com/ContextVM/contextvm-docs/pull/9
If you are interested in the development of it: https://github.com/ContextVM/sdk/pull/24

2026-02-05 09:20:07 UTC

- reply

Hey, yes, these servers are offline. We are not running them, is the operator, probably @npub1ye5…knpr Sorry for the inconvenience. We should add a function to dummy ping servers so they can display an 'offline' badge. I'm happy to assist further if you need help

2026-02-03 17:20:25 UTC

🗞 Proudly announcing the first issue of our new bi‑weekly newsletter! 🗞
In it we will explore everything related to ContextVM, its ecosystem, MCP news, projects, and everything in between. This inaugural issue was written by @npub1jeq…nmal , who will help us with communication and news. Tuma is not an LLM or a bot, he is a person, and he already writes for other open‑source projects such as Bitcoin Optech, BTC++ Insider Edition, and more. We’re glad to have him on board and happy to welcome more contributors 💛
Hope you enjoy it, we welcome any feedback, now, Let's keep building!🚀
#naddr1qv…zmfy

2026-02-03 12:29:45 UTC

A brief demo of the power of these new commands 👀
https://video.nostr.build/6b13b147fffa320ce95bc61c291cc4922a6d40b726edfc83c1e5c43d817ab4f9.mp4
#nevent1q…gw65

2026-02-03 10:57:33 UTC

And this is not the only news we have for today 👀 more about this later, wait for it 🔥
#nevent1q…x2hg

2026-02-03 10:50:06 UTC

🚀 Serve and Use: two new commands, one CLI, zero hassle
https://image.nostr.build/04fc33ed93083179db6cd6f751d40f06c801ac978f8e38b024c0751fb2d4a9f7.png
We merged our standalone gateway‑cli and proxy‑cli tools directly into cvmi. What used to require separate installations and configuration now lives under one unified CLI, and it couldn’t be simpler.
Serve any MCP server over Nostr:
- For example, the NostrBook: npx cvmi serve npx -y @nostrbook/mcp@latest
- Or even expose a remote HTTP server through Nostr👀👀: npx cvmi serve https://mcp.applesauce.build/mcp
This is a very new feature and led us to bump our SDK version to 0.3.x. More info is available in the CHANGELOG (https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md) and the gateway overview (https://docs.contextvm.org/ts-sdk/gateway/overview/).
Use a remote server and access it locally via stdio: npx cvmi use 7506...5fa3
Both new commands work out of the box with ephemeral keys and default relays. Override relays, keys, or other settings via flags, config files, or environment variables when you need more control. To see all available options, just use --help with any command.
For builders who want to ship, and for users who want to connect to their services easily, the toolkit is shaping well: skills, servers, and connectivity in one place. Run npx cvmi and explore. Soon we’ll add new features to complement these and give you everything you need to learn, build, debug, and interact with the CVM ecosystem. Stay tuned.
https://github.com/contextvm/cvmi
#ContextVM #Nostr #MCP #decentralized

2026-01-29 14:46:34 UTC

- reply

Hahaha ok, thought it was something new.
We think that as enshittification continues extending its shadow through the internet and digital world, it is going to be more and more valuable for individuals to be able to fully, self organize, associate, collaborate and share their resources. We feel that the infrastructure as a service model that we are seeing more and more is going to be a huge bottleneck and more discriminatory since the heavy computations they offer will struggle with a more democratized demand for the resources. So, the more people, the worse that model scales without sacrificing a competitive environment and becoming a monopoly. At the same time, things are going to get cheaper to run at low scale and people will be able to share the resources they have to satisfy demand at their scale. This vision can be true or not in the future, but it is one of the fundamental whys behind CVM, high bandwidth collaboration between individuals.
If you feel curious about our point of view and ethics you can check our blog, we have some nice articles like https://contextvm.org/blog/forging-a-new-frontier

2026-01-29 12:46:57 UTC

- reply

Thanks! Yes, Nostr is a whole paradigm shift, and CVM is another building block of Nostr that leverages as many of its inherent features as possible. Very powerful.
We would love to know more about that concept of cognitive computing resources you mentioned. Would you mind explaining what it means?

2026-01-29 11:51:32 UTC

- reply

Thanks for your words! We are glad that more people are aware of CVM and the possibilities it brings. If you ever need to clear any doubt please just ping us, we are more than happy to assist. CVM is fully open source and community driven, we all build this together 💛

2026-01-29 08:21:50 UTC

Thanks @npub1jss…fmzy and @npub1wtx…0rjx you are building awesome stuff 🔥
#nevent1q…yv0w

2026-01-28 21:41:48 UTC

- reply

We should be able to do it fairly easily, just using git stuff, ngit, as it is a natural fit for the current skill distribution conventions

2026-01-28 21:24:50 UTC

Add skills just like this `npx cvmi add` pick the one that better suits you, then 🚀
https://image.nostr.build/dc918411aa89484700d9b170057b9af7ae34bc0bf6b6dc902781c335b34cd091.jpg
#nevent1q…zuzg

2026-01-28 20:44:23 UTC

🎇Meet CVMI: the Army knife we are building for ContextVM development🧑‍💻
https://image.nostr.build/c0c7c982104c053e185bcd9522c578233e818e4c2c3ad8668fc395c090e27926.png
If you are building/vibing on Nostr, this is for you. We are shipping CVMI alongside a complete skill set that makes ContextVM development delightful.
The skills cover the entire stack: protocol fundamentals, architecture concepts, client and server development, troubleshooting, SDK internals, and production deployment. Each skill includes working templates, reference documentation, and patterns distilled from real Nostr development. Everything you need to do is `npx cvmi`.
Or grab the skills through CVMI with `npx cvmi add`, or through the skills CLI with `npx skills add contextvm/cvmi`.
These commands will show you the list of available skills and guide you through their installation for any coding platform. Cool, right?
You can also pick exactly what you need `npx cvmi add --skill overview`
CVMI starts as a skills manager, but we are building toward the unified toolkit that ContextVM deserves. One CLI for skills, server interaction, dev tools, the works.
For builders who want to ship. The skills are here now.
https://github.com/contextvm/cvmi
If you don't know what skills are: https://agentskills.io/home
#ContextVM #Nostr #MCP #buildinpublic

2026-01-27 11:31:50 UTC

🧑‍💻 We've just released a new version of the CVM SDK (0.2.6). This time, it is an update focusing on ergonomics and coding style guidelines. The main refactor is that when creating a transport for a client or a server, you no longer need to create a relay handler. You can simply pass an array of relays, and it will create the handler for you using the Applesauce relay handler, which is our recommended, robust, and better tested relay handler.
Now:
```typescript
const transport = new NostrClientTransport({
signer,
relayHandler: ["wss://relay.contextvm.org", "wss://cvm.otherstuff.ai/"],
});
```
Before:
```typescript
const relayHandler = new ApplesauceRelayPool([
"wss://relay.contextvm.org",
"wss://cvm.otherstuff.ai/",
]);
const transport = new NostrClientTransport({
signer,
relayHandler,
});
```
Additionally, we updated some of the agentic conventions, code style, and guidelines. We switched to 'AGENTS.md' and created a 'CLAUDE.md' that simply redirects to 'AGENTS.md'."

2026-01-26 07:52:58 UTC

- reply

As based as super 🔥

2026-01-25 20:53:16 UTC

Are you ready for what is comming? 👀
#nevent1q…xn88

2026-01-24 11:53:39 UTC

This is a quite necessary project. The fact that it is fully based on permissionless technology that you can consume, run, and self-host makes it even more powerful 🚀
#nevent1q…2cqs

2026-01-21 18:22:20 UTC

We're cooking up some very cool new features for Relatr and decided it's better to channel all communication and news through its pubkey (the same one used to address the server). One key, countless possibilities. Stay tuned, amazing news incoming 🍳
#nevent1q…72h5

2026-01-21 13:07:07 UTC

🚀 We're excited to announce the 0.2.x release series of the ContextVM SDK, a significant milestone focused on reliability, code quality, and architectural maturity. This release transforms ContextVM from a functional prototype into a hardened foundation ready for long-running servers. As well this release maintains backward compatibility while setting the stage for future enhancements.
- What This Release Means for You and Key Improvements
If you're running ContextVM servers that need to stay always up handling continuous client connections, this release is essential. We've eliminated critical failure modes, plugged memory leaks, and restructured the codebase to support future growth without accumulating technical debt.
🛡 Half-Open Connection Hardening (Applesauce Relay Handler)
One of the most significant reliability improvement addresses how we handle half-open connections, those frustrating scenarios where a relay appears connected but silently stops responding.
What we fixed:
- Implemented proactive liveness checks that detect unresponsive relays before they impact clients
- Added automatic relay pool rebuilding with subscription replay, so clients don't even notice when a relay hiccups
- Enhanced error handling ensures cleanup happens correctly even when relays misbehave
Why it matters: Previously, a relay could appear healthy while silently dropping messages, leading to client timeouts. Now, ContextVM detects these conditions and automatically recovers.
🧹 Memory Leak Elimination
Through careful analysis, we identified and eliminated several memory leaks that could affect long-running servers, the result: Servers can now run indefinitely without requiring restarts to reclaim memory.
🏗 Transport Modularization
We've completely restructured the Nostr transport layer from a monolithic design into focused, composable modules
Why this matters: This modularization achieves several goals simultaneously:
- Code clarity: Each module has a single, well-defined responsibility
- Testability: Modules can be tested in isolation with clear boundaries
- Extensibility: New features can be added without touching unrelated code
- Performance: O(N) operations reduced to O(1) where it counts
This architecture will let us add the new features that are coming without cluttering the core logic.
📦 Simple Pool Deprecation Notice
We're officially deprecating the `SimpleRelayPool` implementation. The `ApplesauceRelayPool` is now our recommended and fully-supported relay pool. If you're still using `SimpleRelayPool`, we recommend migrating to `ApplesauceRelayPool` for production deployments.
🔧 Additional Reliability Improvements
- Graceful shutdown: Task queue now waits for running tasks to complete with configurable timeout
- Timeout handling: Added timeout wrappers to prevent hanging network operations
- Error handling: Enhanced error context logging with stack traces and relevant identifiers
- Session eviction protection: Prevent edge cases under heavy load removing sessions with active routes, eliminating data loss during in-flight requests
- Dependency updates: Updated to latest stable versions of key dependencies
🧑‍💻 For Developers
This release maintains backward compatibility while setting the stage for future enhancements. The modular architecture means you can expect:
- Easier debugging: Clear separation makes issues easier to isolate
- Faster iteration: New features can be developed without touching existing code
- Better testing: Comprehensive test coverage for each module
- Stable APIs: Internal refactoring won't break your integrations
🔭 Looking Ahead
The 0.2.x series establishes the foundation for upcoming features that are already in our pipeline:
- [CEP-15] Common Tool Schemas
- [CEP-8] Capability Pricing And Payment Flow
- CEP-XX Server reviews
- CEP-XX Server profile metadata and socials
- CEP-XX Ephemeral gift wraps
With this hardened foundation, we can add these capabilities without coupling or cluttering the codebase.
- Upgrade Recommendation
All production deployments should upgrade to 0.2.x. The reliability improvements, especially around relay handling and memory management, are critical for long-running servers. The modular architecture also makes future upgrades smoother.
As always, we welcome your feedback and contributions. The ContextVM project thrives on community input, and this release reflects many lessons learned from real-world usage.
Happy building! 🚀

2026-01-16 11:08:10 UTC

- reply

Yes, the tricky part is replay attacks. But maybe you can mitigate them using something like NWT https://github.com/pippellia-btc/nostr-web-tokens

2026-01-13 11:01:49 UTC

We think we found a good candidate for our Relatr plugin validation system 👀 https://elo-lang.org/ It would probably allow us to create a very portable, shareable, and customizable plugin design, so people can create them and share them, just plug them into their Relatr instances, and customize their algorithms as they prefer. More to come in the next releases, stay tuned 🚀

2026-01-13 10:02:18 UTC

- reply

Right, that's a good question. There are different factors at play to mitigate that issue. First, we implemented a preserve stale cache policy in case of failure when requesting a rank. This ensures that users who previously had their rank computed successfully maintain their rank, avoiding transient issues due to spam conditions.
This is not a perfect solution, and we still have some edge cases to cover. However, addressing these will require, as you mentioned, some kind of prioritization, which is a more complex task. For now, the more harmful edge cases are covered, and we will continue to think about this to potentially find a better solution.

2026-01-13 09:51:30 UTC

- reply

Hey! Thanks for sharing. Yes, it's an interesting approach, but I have some questions about how Privacy Pass tokens have value or are accepted by different relays. There should be some notion of consensus around the entity emitting these tokens, right? Like bonds, in the case where the issues or the Privacy Pass tokens vouch with its reputation, and that's what makes the PP tokens be accepted. So relay operators should recognize that reputation and allow these tokens to be accepted. How do you imagine this relationship to work? I'm a PP token issuer, and my mission is to grow reputation among relay operators so they accept my PP tokens?
On the other hand, I think that Cashu might be the best fit for this use case since it already can handle some spending conditions like time locks, pay-to-PK, refund paths, and as far as I know, there are some people working to bring zk-proofs to create arbitrary spending conditions. Do you imagine mints and PP token issuers being the same entity, or two separate things, like the mint is used as a 'third party' issuer of Cashu tokens, enforcing spending conditions, and the PP token issuer just issuing PP tokens based on the Cashu tokens you present? I think that other people who might be interested in this conversation are @npub12rv…85vg and @npub1klk…x3vt

2026-01-12 17:40:42 UTC

- reply

Yes, I think it is correct to say that, anyone can write if the bucket assigned to their pubkey is large enough. The publishing capability changes depending on the rank, users with high ranks get more events to publish per day. On the other hand, new npubs can only write one event per day, which must be of kind 1 and without urls in the content. If the reply guy spins new npubs each time, the relay will likely consume them. However, the key point is that this is the current policy we have on the wotr.relayr.xyz instance. You can run your own and tweak it to configure different thresholds and also to enable or disable publishing for users with no rank. You could also disallow anyone from writing below a certain threshold. Together with the ability to self-host your own relayr instance, makes it very customizable to each person's needs and communities. Also, remember that this is an experiment we are running, and so far, it is working great

2026-01-12 10:05:43 UTC

With this release, Relatr can now function as a TA provider, publishing ranks directly to relays. If you enable a Relatr server to be in your trusted list of providers, it will display ranks in compatible clients like Amethyst. To do this, simply go to https://relatr.xyz/ta and add a server to your list. Once added, you can enable the server to keep your rank up to date. The process is quite simple and straightforward. I would love to receive any feedback you might have 👍
#nevent1q…7gpx

2026-01-12 09:01:39 UTC

- reply

Hey, that's very interesting. I'm curious to hear more about your approach. Are you basing your solution on something like Cashu, or just LN with hold invoices?
In our case, the solution is much simpler. We use rate limiting to control the load between the relay and the upstream rank provider (Relatr), basically to avoid possible DDoS and load attacks. Initially, we based this rate limiting on IPs, but we noticed that it was penalizing legit users behind VPNs or IP groups. So now, we base the rate limiting on the number of requests per second that the relay can send to the rank provider. It's simpler, more effective, and users are not penalized for being behind an IP group

2026-01-12 08:53:11 UTC

- reply

Roughly 16 users, we are observing common relays to determine how many people have added wss://wotr.relatr.xyz to their relays list. To do this we are using nak with the following command, you can check it on your end as well.
'''
nak req -t r=wss://wotr.relatr.xyz -k 10002 wss://relay.damus.io wss://nos.lol wss://relay.primal.net wss://bitcoiner.social wss://search.nos.today/ wss://nostr.mom/ wss://relay.snort.social/ wss://discovery.eu.nostria.app/ wss://nostr.wine wss://eden.nostr.land | wc -l
'''

2026-01-11 20:38:15 UTC

- reply

Well, the relay is not actively fetching posts from other relays. However, since the relay is open, anyone can broadcast events to it. Some clients will do this when users who have the relay in their list interact with someone else. Therefore, by simply having the relay configured in your list, some clients will rebroadcast certain events. In the end, events can arrive through different means, but there is no active fetching involved

2026-01-11 19:57:03 UTC

- reply

In today's release of wotrlay, we included special treatment for these kinds plus 0, 3, and 10002s. This allows them to be accepted without rate limits, also, the current version of relatr already enables you to set extra relays for publishing the TA events it generates, which are 30382s. We have already configured our public instance to publish to your relay and the wotrlay instance we are running as well 🦾 plus user outboxes ofc

2026-01-11 16:04:04 UTC

🚀 wotrlay v0.2.x is here
As wotrlay matures, we've identified and addressed edge cases where transient issues could temporarily affect user buckets. Timeouts, rate limits, and network conditions sometimes caused the relay to handle cache refreshes less gracefully than intended, which could result in users being downgraded when they shouldn't have been.
v0.2.x resolves this. The relay now preserves cached rank data when encountering these edge cases, ensuring users can continue publishing without issues. We've also replaced IP-based rate limiting for rank lookups with an approach that no longer penalizes users behind VPNs, and improved response handling to be more robust under real-world conditions.
We've also added a special condition for event kinds 0, 3, 10002, 10040, and 30382, which are now always accepted and are not affected by the rate limiting of the bucket algorithm.
For operators: just upgrade.
For users: your posting ability now stays consistent regardless of previously unhandled edge cases.
Docker builds are leaner and faster too.
Building reliable WoT infrastructure means continuously observing, fixing, and improving. v0.2.x represents that ongoing commitment 🫂
#nostr #wotrlay #wot

2026-01-11 10:57:32 UTC

- reply

Valid nip 05 addresses like _@domain.tls