quoting
naddr1qv…vpzdGM people, and welcome to the second issue of "The ContextVM World", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!
In today's update we are going to discuss payments on CVM, enabled by CEP-8 specifications. The latest releases of CVM SDK and CVMI have been updated to support this huge milestone.
We will also cover the latest features currently being implemented. In particular, we will take a look at CEP-17, which deals with relay lists, and CEP-19, which aims to improve privacy for encrypted communications.
We will also present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.
Finally, we will bring the latest news from the MCP ecosystem, including specification changes and new protocol additions. CVM is built on MCP, which means that we care about providing you up-to-date information from its thriving ecosystem.
Let's start!
News from ContextVM 📰
A list of updates, releases and new cool features.
ContextVM has received support from OpenSats: OpenSats announced its fifteenth wave of grants from the Nostr Fund. ContextVM is one of the new projects to receive the grant, which will support core protocol development, SDK expansion, and improvements to the reliability of shared infrastructure. It will also allow the team to work on new SDK implementations, create and manage one-click deployment packages, provide comprehensive documentation and tutorials, and integrate CVM with open-source developer tools.
Payments are finally live on CVM: With the recent merging of CEP-8 specification, anyone running a MCP server can finally monetize its capabilities, allowing for a decentralized and permissionless marketplace of services and tools. Most importantly, it does so without imposing a single (or a set of) payment method(s), but by standardizing the way users ask for payments.
CEP-8 introduces a language called Payment Method Identifier (PMI), based on the homonymous W3C standard, that allows to define the specific payment method to be used during the interaction. In other words, PMI is the type-tag for the payment request payload, analogous to content-type in HTTP. For example, a BOLT11 lightning payment will be identified by the string
bitcoin-lightning-bolt11. Notably, CEP-21 has been added to provide recommended naming conventions for new PMIs.CVMI latest release: v1.10.0 for CVMI, the cli tool for CVM, has been recently released. The latest version introduces comprehensive documentation for implementing payments through CEP-8. It also adds support for environment variables to spawned MCP servers and normalizes quoted command strings to serve any MCP server.
CVM SDK release family 0.4.x: Starting from v0.4.0, the ContextVM SDK added support for payments through CEP-8. Other patch versions has been released to fix minor issues or include small features, such as payment export and logging and preventing zombie publishing loops. Notably, v0.4.5 added support for payments through NIP-57 Lightning Zaps. This is the third payment processor to be supported in CVM, following NWC and LNBits implementations.
The release v0.4.6, adds notifications for payment verification based on NIP-47 NWC. Since this feature is not supported by all NWC providers, the payment processor will determine compatibility and only enable notifications if the provider supports it. Before publishing v0.4.6, we have released a series of patches which add deduplication capabilities for multi-relay deployments, making the transports more efficient and increasing performances when connected to multiple relays.
News from the ContextVM Ecosystem 🗞️
Find all the projects leveraging ContextVM on ContextVM/awesome.
Agents are starting to realize ContextVM exists and are looking for ways to integrate it into their operations. Clawstr and The Colony are two examples of platforms where agents are discussing about the benefits of ContextVM.
What’s Next for ContextVM? ⏭️
Let’s take a look at the features currently being implemented!
CEP-15: This enhancement proposal implements a standard for defining and discovering common tool schema. This aims to enable interoperability between multiple servers, standardizing tool interfaces that clients can recognize and use consistently. It leverages MCP's
_metafield, RFC 8785 for deterministic hashing, and CEP-6 announcements for discovery, creating a marketplace where users can choose between multiple providers implementing the same standard tool interface.CEP-17: This enhancement proposal defines a relay list mechanism based on NIP-65 conventions. Servers can publish the list of relays they are connected to using kind
10002events, allowing clients to discover the appropriate relays for establishing connections. This solves the current limitation where users must know both a server's public key and its relay URLs to connect.CEP-19: This enhancement proposal introduces an optional convention for CVM servers and clients to exchange encrypted messages using an ephemeral gift wrap kind. This CEP aims to improve privacy for encrypted communications by establishing a new kind
21059, similar to kind1059, which will not be stored by a relay.Who is Talking about ContextVM? 📢
A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.
Our naddr1qv…t8dw">blog post providing a simple and fun tutorial to illustrate how the CEP-8 payment flow works. Get your Nostr badge now!
Our naddr1qv…qt6c">blog post on CEP-8 and Digital Lemonade Stands.
A nevent1q…zl4z">note on our official Nostr profile highlighting the importance of CVM in an agent-mediated world.
A nevent1q…49vd">note from MaximumSats (Max (npub17td…v95p)), developer of the LNBits processor in the CVM SDK, discussin MCP-to-Nostr bridges.
News from the MCP world 🤖
What is going on in the MCP world?
PR2127 presents a draft specification, SEP-2127, that proposes a standardize way to describe MCP servers, called Server Cards. This would allow an MCP client to discover server capabilities using a
.well-knownendpoint, without the need to establish a full connection.Note: This proposal together with the registry specification defines a series of HTTP endpoints attached to specific servers to allow discoverability of MCP servers. In ContextVM, we think this is an anti-pattern, increasing centralization and gatekeeping. We already solved discoverability in CEP-6 (Public Server Announcements) where we standarized the usage of relays as decentralized repositories. Servers are free to announce their existence in any number of relays and curation is done directly by the relays. This way, incentives are always aligned without any central point of failure.
SEP-2133 has been officially formalized. This specification establishes a lightweight framework for extending MCP through optional, composable extensions. In particular, it provides guidance on how extensions should be proposed and adopted, and defines both a list of official extensions, developed and recommended by MCP maintainers, and one of experimental ones, for simple discovery, prototyping and collaboration.
SEP-1730 has officially landed, providing a tier system for MCP SDKs. This allows to establish clear expectations for feature support, maintenance commitments, and quality standards. The specification defines a three-tier system, based on objective, measurable data. In particular:
Tier 1: Fully supported. The SDK implements the full protocol and is well supported; Tier 2: Commitment to be fully supported. The SDK is actively working towrds full support; Tier 3: Experimental. The SDK is in its early stage.
Find out more about ContextVM:
Check out our website for documentation, blog posts, and more Join our Signal group Follow ContextVM on Nostr, ContextVM (npub1dvm…3jdm) Follow Relatr on Nostr, Relatr (npub1w5r…eu4t) Check out our GitHub repositories and leave us a ⭐
ContextVM on Nostr: The second issue of "The ContextVM World" is out! Hope you enjoy it 💛 ...
The second issue of "The ContextVM World" is out! Hope you enjoy it 💛