Original note: https://njump.me/nevent1qqs04pxd9zld32ucnwcepa2ak7v5vjlmgt75hhhqxg6jjsqud7ch44spz4mhxue69uhkummnw3ezummcw3ezuer9wchsygrtx7qw72tjuu7nwzuy50j3u74f4c6t7sff8rw0hkw97cajy9qkeqpsgqqqqqqsznxpqh
We are thrilled to unveil the new identity of DVMCP. Moving forward, the project will be called ContextVM and will be officially hosted under the https://contextvm.org domain. This rebranding is driven by several factors:
-
Conceptual Clarity: The term "DVM" remains ambiguous within the Nostr community. The recent "DVM wars" highlighted the lack of consensus around what a DVM is, and it doesn't seem this will change soon.
-
Avoiding Confusion: There is another project called DVMCP in the MCP world, which stands for "damn vulnerable MCP." Its goal is to provide a "hack the box" MCP experience, and we do not want to be associated with it.
-
Not Following the DVM Pattern: We initially called the project DVMCP because we were following the pattern described in NIP-90 DVMs to implement MCP over Nostr. However, this is changing now, as more information is provided below.
-
New Direction and Governance: There are enough technical changes that justify the rebranding, and we want to reinforce the open-source nature and community-driven governance of the project. The project is now under an organization.
We initiated this project early on, when MCP was just being announced. We started DVMCP following a "kitchen sink" approach, reimplementing everything to gain experience and understanding of MCP and how it can leverage Nostr's capabilities. This helped us delve deeper into MCP and understand its concepts thoroughly.
Additionally, MCP is a relatively new protocol, and its governance is still under debate. By following the "kitchen sink" path, we aimed to avoid distractions from breaking changes on their end. Now that the MCP protocol is more mature, we can better anticipate its evolution. Another reason for the rename is to move the project under an organization that better reflects its open-source nature and the community-driven governance we envision.
All these factors have led us to this decision. We will continue to use this npub for all related communications.
Technical Changes Overview
The most significant change in the specification is the elimination of separate kinds for requests and responses, opting instead for a single kind acting as a "socket." We think this is a more elegant solution. We will provide more detailed information about these changes in future posts, but you can read the spec right now at https://www.contextvm.org/ctxvm-draft-spec/.
We are also announcing the ContextVM/ts-sdk https://github.com/contextvm/ts-sdk, which provides all necessary pieces to work with ContextVM and demonstrates our new integration approach with MCP. We have based the design of our architecture on the transport domain of MCP, creating Nostr transports for servers and clients. The transport in MCP is an agnostic piece of the stack, with local transports like stdio or remote transports like SSE or streamable HTTP. Transports are simply transports, while servers and clients are the protocol-compliant parts. Now, we are introducing Nostr transports, making it easy to operate and consume MCP over Nostr using their SDK and the Nostr transports from the ContextVM SDK. This enhances both the developer and user experience, making it easier to reason about, as ContextVM is now a thin layer on top of MCP SDKs. Any changes in the MCP spec or their SDK will be handled out of the box, reducing maintenance costs and eliminating the need for adaptations to new MCP features. With everything related to ContextVM happening at the transport level, we believe this is a forward-thinking architectural choice.
The project is now live, and you can explore it at http://contextvm.org . The SDK is fully usable and offers all basic features. It also supports encrypted communication by default.
Our next steps include adapting the website to create a decentralized repository where anyone can discover MCP servers operating on Nostr and allowing users to try them out. Write more tutorials and guides. Next steps for the SDK include adding payment capabilities, after which we will be fully aligned with the current state of DVMCP. We will be releasing these features and more in the coming weeks.
We are looking forward to know your thoughs, and also we are looking for for contributors and testers. We will also want to host a community call this week. We are proposing Thursday, October 24, or Friday, October 25, at 16:00 UTC. These dates are just a reference, and if you have a better date drop it in a comment, we will adapt to the one that suits everyone best. Please join us and don't hesitate to ask questions.