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/ -

ContextVM Documentation

ContextVM

The intersection of Nostr and MCP

Sorry for the inconvenience. CVM servers are still running, and clients can still connect using any relay, there’s no disruption there 🦾

Nostr == WS == CVM. Connecting to servers, calling tools, etc, everything has worked over WebSockets since day one with ContextVM 🚀 View quoted note →

A new issue of our biweekly newsletter is out! 🚀 "Ephemeral Is Better — The ContextVM World #3" Available in nostr and substack:

Ephemeral Is Better — The ContextVM World #3 🌍

GM people, and welcome to the third issue of “The ContextVM World”, your biweekly appointment to discover everything you need to know about Con...

View article →

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.

GitHub

NIP-XX: ContextVM, MCP JSON-RPC over Nostr by ContextVM-org · Pull Request #2246 · nostr-protocol/nips

I wrote this NIP to describe ContextVM (CVM): a minimal convention for transporting Model Context Protocol (MCP) JSON-RPC messages over Nostr. The ...

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

GitHub

NIP-59: Add ephemeral gift wrap event kind (21059) by ContextVM-org · Pull Request #2245 · nostr-protocol/nips

Adds support for ephemeral gift wraps (kind:21059) following the same semantics as regular gift wraps (kind:1059) but with ephemeral event semantic...

View quoted note →

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 🥷🏼 View quoted note →

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.

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! 🚀

Show HN: ContextVM – Running MCP over Nostr | Hacker News

Now that payments are in place, we are going to work on: - CEP-19 for ephemeral gift wraps:

GitHub

Issues · ContextVM/contextvm-docs

ContextVM documentation and specification. Alternative link: https://contextvm.github.io/contextvm-docs/ - Issues · ContextVM/contextvm-docs

and - CEP-17 for servers relay list:

GitHub

Issues · ContextVM/contextvm-docs

ContextVM documentation and specification. Alternative link: https://contextvm.github.io/contextvm-docs/ - Issues · ContextVM/contextvm-docs

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

GitHub

[CEP-15] Common Tool Schemas · Issue #15 · ContextVM/contextvm-docs

Preamble Title: Common Tool Schemas Authors: ContextVM-org Status: Draft Abstract This CEP establishes a standard for defining and discovering comm...

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

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 :) Docs:

ContextVM Documentation

Payments (CEP-8)

Learn how to add payment handling to your ContextVM servers and clients using CEP-8

Skills: npx cvmi add --skill payments, or npx skills add contextvm/cvmi --skill payments

Get it fresh in your inbox every two weeks! View quoted note →

GM Nostr! Our newsletter, The ContextVM World 🌍, is now live on Substack:

The ContextVM World 🌍 | Substack

Your biweekly appointment with ContextVM, MCP, and Nostr. Click to read The ContextVM World 🌍, a Substack publication. Launched 3 months ago.

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!

The second issue of "The ContextVM World" is out! Hope you enjoy it 💛 View article →

Thanks so much to openSats for this opportunity! We'll keep pushing the boundaries of this new paradigm 💛 View quoted note →

Protocols over Platforms is the mantra at the core of CVM

Use Protocols, Not Services

The Internet is almost anonymous and privacy-preserving by design. I mean, unless some administrator actively tries to track you, there is no built...

https://lemonade.contextvm.org View quoted note →

These are badges are real, you can check them here as well: https://nostrsigil.com/badges/naddr1qvzqqqr48ypzpl0zzdglhjrqfsnaelea2plcaxc4gw8nh5zqj09rl4tu66ekckxsqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsqyrvv4kk7mnpv3jj6mr9vajkuernaqgdnx View quoted note →

🍋 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 View article →

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⚡⚡️ 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!⚡️⚡️⚡️