π It has been an incredible year for ContextVM. 2025 marked the birth of this project, initially known as DVMCP, which we launched shortly after the MCP protocol was introduced.
This year has been a whirlwind of experimentation, creation, innovation, new possibilities, and loads of fun. Developers are discovering a transformative way to work with ContextVM, thanks to its unique features, ease of use, expressiveness, flexibility, standardization, and seamless integration with new paradigms like AI, all while remaining fully permissionless and open source π
Product managers and those looking to integrate their services on Nostr to leverage its benefits are finding that ContextVM offers a powerful way to architect their products and solutions. By using relays as message buses, you can decouple the business logic of your application from Nostr specific conventions while still benefiting from Nostr's security and censorship resistance.
You can seamlessly integrate ContextVM with your existing stack without needing to rewrite everything to make it work over Nostr. This opens up possibilities for unified APIs, geographically distributed, composable, unstoppable apps, and more, the possibilities are endless and yet to be discovered.
2026 promises to be another amazing year. ContextVM is a community driven, fully open-source project that anyone can use, contribute to, or fork. Our vision is one where this technology liberates individuals, communities, businesses, and other entities from the control of gatekeepers and power structures. The future we envision is permissionless and full of collaboration between free individuals, positive-sum games, where the right to speak, associate, and the right to compute are equally important and transcendental.
We have a lot of work ahead, and that makes us really happy π¦Ύ Powerful features and specifications are already in development, promising even more possibilities, integrations, and capabilities. We hope that 2026 will see more people adopting Nostr, Bitcoin, CVM, and other freedom technologies, bringing and solving problems through this lens.
Without further ado, thank you to everyone who showed interest, contributed, integrated, and benefited from this project. We wish you all a great start to the new year π
Let's continue building!
Thanks! I appreciate that you like what we are doing here. It is organic in the sense that any client can connect and subscribe or publish, as there is no NIP-42 auth requirement. Users don't need to sign challenges, and clients don't need to handle auth. However, writing is rate limited by the author signing the event and the bucket algo
Not exactly, it's a WoT relay using relatr as an 'oracle' and a bucket algorithm for rate limiting and publishing policies. It is intentionally built without using NIP-42, all the accounting is based on the authors of the event. We recently published an article about this, you can read it here: https://contextvm.org/blog/wotrlay-moderation-as-a-bucket or as a long form.
Do you have some feedback? We are just exploring this idea, and it's working fairly well. I haven't seen anything inappropriate in the feed
Just released! π
Docker deployment of Wotrlay is now available. You can run this WoT relay using a single command 'docker run ghcr.io/contextvm/wotrlay:latest'
You can also find more options and configurations in the docker documentation https://github.com/ContextVM/wotrlay/blob/master/DOCKER.md .
We have just deployed using this at wss://wotr.relatr.xyz π₯
#wot #wotrlay
You can add it to Amethyst as a public outbox or inbox. You can also set it for other categories, but these should be sufficient. Yes, Amethyst likely connects and publishes to it when replying to this note or if you follow a user who has the relay set in their relay list. I hope this clarifies things π
Amazing! thanks :)
After running a public instance of Wotrlay for a couple of days already (wss://wotr.relatr.xyz), we discovered a fascinating synergy between Wotrlay and Relatr π
They complement each other perfectly. As more people use or include this relay in their lists, their interactions on Nostr organically prompt Relatr to validate profiles that might not already be in its database. This process helps Relatr validate and rank these new profiles, increasing the number of relations in its view of the network. Consequently, the more people who use our Wotrlay instance (or their own), the fewer blind spots a Relatr instance will have, creating a perfect tandem of openness and organic discovery. This synergy was not something we anticipated when we first conceived Wotrlay, but it works beautifully π
If you'd like to help us test this further, please add wss://wotr.relatr.xyz to your relay list. Soon, we will provide more options and documentation to make deploying Wotrlay easier, so running your own instance should be fairly straightforward. Relatr is already deployable in one click in umbrel through nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr 's community store and also is available as docker image
Currently it is using the public instance of relatr which uses the nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc 's pubkey as source.
I don't understand what you mean exactly. In this project, spam is mitigated by each one's bucket. By NPS, do you mean Net Promoter Score?
It is more a classic bucket, it adds tokens at a constant rate until capacity is reached. Requests consume tokens when available. There is a full analysis of the current implementation here https://github.com/ContextVM/wotrlay/blob/master/wotrlay-v2-analysis.md . Thanks for the suggestion anyways!
What if relay moderation looks like a bucket?πͺ£
We are exploring exactly that with Wotrlay, a new WoT relay we are introducing today! It treats moderation as resource allocation, where the web of trust determines your publishing capacity.
Wotrlay gives each public key a 'bucket' of publishing capacity that refills at different rates based on their social graph rank. Low-rank identities can still participate, but at a measured pace. Higher-rank identities gain more capacity organically through network participation, no manual approval needed.
Try the public instance at wss://wotr.relatr.xyz
This proof-of-concept integrates Relatr for dynamic ranking and is built in Go using the great Rely framework from nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup. Kudos to him for it and the WoT example that inspired this project.
If you want to dig deeper, we've published an article that walks through the bucket model, progressive rate limiting, newcomer onboarding, and why this approach avoids auth friction while keeping the relay permissionless in practice.
All the code for this project, is open source and is made to be run by anyone π
https://www.contextvm.org/blog/wotrlay-moderation-as-a-bucket
check out the code and more details at: https://github.com/ContextVM/wotrlay
nostr:naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyt8wumn8ghj7un9d3shjtnwdaehgu3wdejhgtcqremk7arjd3shjttddajx2unpw35k7m3dv9ej6cfdvf6kx6m9ws3h5adq
Happy Christmas! Thank you to everyone for accompanying us this year π
We have a little, yet special gift for you. We revamped our website. It was functional, but lacked content and a better design. Now you can find much more information, contact details, and all the links to navigate the ContextVM ecosystem, learn more, build, or participate. We take advantage of this opportunity to also make a slight modification to our logo. We hope you like all of this. We want to make ContextVM a great ecosystem of freedom tech where everyone feels welcome and supported, and part of it is to make it beautiful. Committed to open source. Let's keep building! π«‘
Visit: https://www.contextvm.org/
If you have any feedback, we would love to hear it!
π CVM SDK v0.1.47 has landed! π
This release packs a punch with improved reconnection handling. Previously, if a relay used by a client and a server experienced a prolonged outage (minutes or hours), the apple-sauce relay handler would fail to publish new messages after the relay came back online. With this update, clients and servers automatically handle this, resubscribe and resume event sending as soon as the relay is back online. Server operators, don't miss out, update to the latest SDK version for a smoother, more reliable experience.
Performing some maintenance on our public relatr instance, sorry for the inconvenience.
nostr:npub1jss47s4fvv6usl7tn6yp5zamv2u60923ncgfea0e6thkza5p7c3q0afmzy is Super Based π©
πThe awesome CVM repo is growing! Three new servers have been added in the past few days. They are:
- Nanalytics (https://github.com/humansinstitute/nanalytics): Website analytics like your Nanna used to bake. Over Nostr, privacy-preserving, simple analytics, easy to host.
- Earthly Geo Server (https://github.com/zeSchlausKwab/earthly/tree/master/contextvm): A server focused on geocoding and reverse geocoding via OpenStreetMap Nominatim. Features search_location for forward geocoding and reverse_lookup for coordinate-based place metadata.
- Wavefunc Music Metadata Server (https://github.com/zeSchlausKwab/wavefunc/tree/main/contextvm): A server for radio stream metadata extraction and MusicBrainz lookups. Features extract_stream_metadata for Icecast/Shoutcast streams and musicbrainz_search for detailed track information.
The Geo Server and the Music Metadata Server are also public and are already integrated into earthly.city and wavefunc.live. They are accessible and can be used through the Contextvm website as well.
πContextVM SDK version 0.1.41 is now available with significant improvements to transport integration, relay handling, and async architecture.
Key new features include optional client public key injection in MCP requests, enabling better server integration and authentication capabilities. This feature, documented in CEP-16, allows server transports to inject client public keys into request metadata when configured with `injectClientPubkey: true`. Learn more at https://docs.contextvm.org/spec/ceps/informational/cep-16/
The release also brings robust relay reconnection for Nostr server transport, fixing relay restart issues in ApplesauceRelayPool with comprehensive reconnection tests. This ensures more robust operations in long lived servers.
Performance improvements come from async architecture enhancements including a TaskQueue utility for non-blocking event processing, parallel transport startup operations, LRU caching for session management, optimized authorization lookups, and improved notification broadcasting with backpressure handling.
These changes deliver better integration between transports and underlying servers, more reliable relay handling, and enhanced performance through optimized async operations.
π Exciting news! We're working on a new CEP for ContextVM: Common Tool Schemas! π
https://github.com/ContextVM/contextvm-docs/issues/15
Imagine a marketplace where users can choose the best server for their specific needs, without being locked into a single provider. That's the vision behind our new CEP!
With Common Tool Schemas, we're enabling interoperability between clients, allowing users to discover equivalent services, switch providers seamlessly, and compare offerings based on quality, cost, or trust. This is the original idea behind DVMs, where users announce a desired output and service providers compete to fulfill the job requirement in the best way possible.
π§ Key features:
- Reference server pattern for canonical tool schemas
- RFC 8785 JCS for deterministic hashing
- CEP-6 announcements for discovery
We'd love to hear your thoughts and opinions on this proposal! Share your feedback and help us shape the future of ContextVM. You can just share your thoughts in the comments of this note, or in the issue
#ContextVM #CEP
In Relatr, we use the relations within the following list as well, aka social graph distance. The difference is that we focus on a trust model that always starts from the perspective of a source pubkey. This is because in decentralized networks like Nostr, there is no global state or a way to compute a global trust score. Our approach is to embrace this and accept that trust is a social phenomenon that occurs between the relation of two profiles: a source and a target. This means that what might be trustworthy for you may not be for me, and this is the only feasible approach we found that might work, as the idea is that everyone can run their own Relatr instance setting yourselve as the source.
In the other hand, the insight that led us to choose this approach is that if you trust the source pubkey from an specific Relatr instance, you can in some way extend your trust to what the source pubkey trusts. The analogy would be: if I trust you, I can trust what you trust. So, even though the trust is always computed from a source pubkey, if you trust the source, the score would still be meaningful for you.
There is more information on the Relatr.xyz page in the About section. We also wrote an article when we introduced Relatr, going through the rationale behind our approach. Hope this helps!
Hey! We just answered this a moment ago. Just keep in mind that Relatr is about relative trust score, so it's going to always be determined by the source pubkey. The idea is that the actual value of the trust score doesn't matter that much. It doesn't matter if you have 100, 95, or 50. The important part is that it's easy to determine if there are impersonators of you, so it's easy to determine who is the impersonator or the real one.
Hey! So, a root NIP-05 is when you are the 'default' or root profile in the NIP-05 domain. For example, if your NIP-05 is negr0@hodl.ar, the root NIP-05 would be _@hodl.ar. Notice that the underscore represents the default or root value of the domain. This typically indicates that the user is the owner of the domain, which can have some presence connotations. In the case of Relatr, having a root NIP-05 is just a way to slightly increase the score in the case you have a valid NIP-05. On the other hand, the reciprocity metric determines if the source pubkey and the target pubkey follow each other.
nostr:npub1th6r23tltjuy6r498z90hlg092yx0ddk5a700xdkytdqjgfhmrysceymrz uses the default instance of Relatr, so the source pubkey from which the trust is computed is determined by that instance. The default instance is accessible from relatr.xyz
Hope this clears up some doubts. Feel free to ask if there's anything else we can help with.
This is another awesome example of the possibilities that bring contextvm. Easily deployable analytics for your page, with no more dependencies on evil corporations that harvest your data. Reclaim your sovereignty, and have fun along the way, it has never been this easy
Half of the internet is down today, but Nostr is unaffected. None of the ContextVM ecosystem is down either. Some clients and relays might be down if they are behind Cloudflare, but the protocol itself is not affected. A protocol cannot be taken down; it will find a way. If a client is down, you can switch to another client or, even better, run one locally. Jumble and Nostrudel are already good options for this. If a relay is down, you can go to nostr.watch, pick a new one, and use it to communicate. Even better, you can run your own relay. It can be as easy as running Citrine on your phone and exposing the relay through Tor. No domain is needed; just a couple of apps on your phone and voilΓ , you can still communicate with your peers. Be your own infra provider. This is why ContextVM.
The approach we could take with CVM is to leverage the native notification system that MCP has built in for asynchronous and long-running jobs, which I believe fits this use case. MCP also has the concept of resource subscription, allowing you to subscribe to changes in a specific asset exposed by the server. For example, you can subscribe to 'hello.txt', and if the document changes, you receive a notification indicating that the resource has changed. However, for this specific case, I think regular notifications would suffice.
Here's how it would work: If the CI runner is behind a CVM server, the git client or any authenticated user can send a call to a tool named 'run_ci' (for example). Inside the json rpc object representing this call there is a 'progresstoken' value set by the client calling the tool, which the server then uses for correlation. Once the tool is called, the server streams back progress notifications, embedding the same 'progresstoken' defined by the client. This is how correlation works in MCP. The server can then send all the notifications generated during the process and end with a final response, which is the result of the runner.
We have been experimenting with this stream-based approach, and it already works out of the box in CVM. It is also bidirectional, allowing the client and server to exchange messages within the context of a tool call execution. This effectively enables reconciliation protocols with 'need' and 'want' states, similar to what Git or even negentropy does under the hood.
Yes, that would be awesome. At ContextVM, we are trying to create the perfect ecosystem of tooling and specifications so that developers only need to focus on developing. Currently, the language that CVM integrates best with is TypeScript, as the only SDK we have right now is for TypeScript. As well CtxCn is a convenient tool to integrate a CVM server into a TypeScript project. We will be creating more libraries and SDKs for other languages as soon as we can. However, this shouldn't be a limiting factor, as you can call the server from any language that can publish and receive Nostr events. You would just need to build the JSON-RPC call and listen for the response. No need for an SDK to do this
This is quite cool! Why limit yourself to a single WoT provider when you can use multiple and present the results? The more perspectives, the better. After testing Profilestr, we noticed that Profilestr, Vertex, and Relatr tend to output very similar scores, with only slight variations. This indicates that they are quite solid, even with different approaches to compute the trust scores. Relatr and Vertex can be used without leaving the nostr. Relatr uses CVM, Vertex uses a DVM-like API, Profilestr offers a REST API endpoint, so there's no excuse not to integrate some of these options into your client. Fight spam, protect your users from impersonators, and increase the value.
Thanks to nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr for contributing Umbrel support for Relatr. Now everyone can deploy their own instance from home without hassle. You just need to add the hzrd's community store by following the instructions here https://github.com/hzrd149/umbrel-community-app-store , install Relatr, and you'll be up and running. We are so excited to keep working and improving this to truly democratize WoT and foster a healthier ecosystem π
Run the mint on localhost > Use ContextVM to wrap its api > You have a mint addressable by pubkey and accessible through nostr. All calls use ephemeral events and are gift wrapped in the case of encryption
That's for sure; the key here is still that the trust is computed from a specific source pubkey. So, if there is a more relevant pubkey in the social graph than the impersonator's, it will rank higher because it will likely have more favorable validators. Definitely, this approach can be improved and strengthened. We could sample distances to a target pubkey from different direct contacts of the source pubkey to get more paths validated. The architecture will allow this thanks to the Nostr social graph lib by nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk that we are using.
Thanks for the feedback; it is very appreciated. As we mentioned, this is still an experiment, and we need to keep tweaking it to get more relevant results and metrics.
The new spec has just been merged. You can read our latest blog post about this and the final changes we made to the spec after the review process https://dvmcp.fun/blog/new-spec With that in place, it is time to start refactoring the dvmcp bridge and discovery packages π
nostr:naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqqyxueth94ehqetr9u62lk