<unnamed>

Public Key

npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm

Profile Code

nprofile1qqsxkduqau5h9eeaxu9cfgl9rea2nt35haqjjwxul0vuta3myg2pdjqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qyvhwumn8ghj7un9d3shjtnwdaehgunrdpjkx6ewd4jsz9thwden5te0wahhgu3wwfjkcct5wgh8s7t6je3adk

Publishing to

Last Notes

2026-02-25 08:37:29 UTC

- reply

Looks dope!

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-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 [email protected]

2026-01-11 10:13:14 UTC

- reply

Fully free and open source. You can find it and use it at relatr.xyz , you can also integrate it in your client.

2026-01-09 19:03:27 UTC

The only one 😎... for now at least
#nevent1q…qksw

2026-01-04 14:52:20 UTC

Last week, when we introduced Wotrlay, we mentioned in our blog post that we were writing an article about how to call a CVM server 'The Nostr Way.' This new article is now available. In it, we explore the current landscape of 'RPC-nostr' with a technical approach, comparing DVMs and CVMs, and demonstrating how to call CVM servers without SDKs or other dependencies, just events, relays, and signatures. We hope you enjoy reading it and that it encourages you to build on top of ContextVM. If you have any doubts or need clarification, please let us know in the comments
#naddr1qv…ht8w

2025-12-31 14:39:43 UTC

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

2025-12-30 09:50:08 UTC

- reply

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

2025-12-29 23:00:02 UTC

- reply

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

2025-12-29 21:44:22 UTC

- reply

Hey! #nevent1q…cqwh

2025-12-29 21:43:41 UTC

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

2025-12-29 19:30:12 UTC

- reply

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 👍

2025-12-29 19:23:27 UTC

- reply

Amazing! thanks :)

2025-12-29 12:55:53 UTC

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 @npub1ye5…knpr 's community store and also is available as docker image

2025-12-28 17:55:42 UTC

- reply

Currently it is using the public instance of relatr which uses the @npub1der…xzpc 's pubkey as source.

2025-12-28 10:27:01 UTC

- reply

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?

2025-12-28 10:03:00 UTC

- reply

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!

2025-12-27 20:05:39 UTC

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 @npub176p…vgup. 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
#naddr1qv…5adq

2025-12-25 15:14:12 UTC

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!
https://image.nostr.build/fa63b7404873b76ca6775438228aa2b9c0256d60bfb55cba7294fa0bd968f6ce.png

2025-12-23 12:00:18 UTC

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

2025-12-22 10:56:57 UTC

Performing some maintenance on our public relatr instance, sorry for the inconvenience.

2025-12-17 13:31:16 UTC

@npub1jss…fmzy is Super Based 🌩

2025-12-16 11:00:49 UTC

BIG PLANS!
#nevent1q…apnv

2025-12-14 11:48:30 UTC

🎇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.

2025-12-12 11:12:08 UTC

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

2025-12-10 15:26:43 UTC

🚀 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

2025-12-09 19:10:44 UTC

- reply

Veo que ya has encontrado algo de informacion, no dudes en preguntar!

2025-12-05 14:47:41 UTC

Today, we are releasing Relatr v0.1, featuring significant architectural improvements powered by the new Nostr Social Duck library. This update addresses critical scaling challenges and makes running your own trust engine more accessible than ever. We have written an article that delves into the details of this new release and provides other useful resources. We hope you enjoy it as much as we do 💛
#naddr1qv…qanw

2025-12-03 13:04:12 UTC

- reply

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!

2025-12-03 12:30:16 UTC

- reply

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.
#nevent1q…uu65

2025-12-03 11:16:12 UTC

- reply

De nada ;)

2025-12-03 09:32:51 UTC

- reply

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 [email protected], the root NIP-05 would be [email protected]. 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.
@npub1th6…ymrz 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.

2025-12-01 10:34:02 UTC

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
#nevent1q…8wrd

2025-12-01 10:14:41 UTC

- reply

🚀🚀

2025-11-18 15:02:21 UTC

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.
#nevent1q…gy2v

2025-11-15 12:15:14 UTC

- reply

#nevent1q…n0my

2025-11-15 12:14:16 UTC

- reply

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.

2025-11-14 15:39:25 UTC

- reply

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

2025-11-14 15:01:48 UTC

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.
#nevent1q…jdwt

2025-11-13 10:11:25 UTC

Thanks to @npub1ye5…knpr 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 💛
#nevent1q…y7wg

2025-11-11 21:38:10 UTC

YES #YESTR#nevent1q…08fg

2025-11-11 12:49:34 UTC

Do you know about Wavefunc? It's a neat Nostr project that lets you listen to, discover, and share radio stations, and so much more. With ContextVM, Wavefunc can search for music metadata and show you what's currently playing in the radio stations. Plus, you can use their music metadata server on its own. Swing by https://wavefunc.live to see what it's all about. If you want to dive straight into the music metadata server, head over to https://contextvm.org/s/bb0707242a17a4be881919b3dcfea63f42aacedc3ff898a66be30af195ff32b2.

2025-11-05 09:19:27 UTC

- reply

Further considering the pull vs. request/response (req/res) models, it is true that using already published trust assertion data can be convenient and easy to query with appropriate filters. However, one issue is that not all profiles are scored. For instance, a service provider might start publishing a large number of trust assertions, but the set will never be fully complete because it is dynamic, and it's impossible to anticipate which users need to be scored. Consider the example of a nostr feed we discussed: each profile should be complemented with trusted assertions. But what if one of the profiles in the feed doesn't have any trust assertion attached? In that case, the only solution is to request the trust computation from the service provider.
We believe this might be the right balance. Relatr could publish trust assertion events for profiles that have already been computed and still rely on the req/res flow. In this scenario, a client could operate by first fetching already published trust assertions, and if a profile lacks one, request it. The advantage of this approach is that it can be perfectly integrated with the current Relatr model, as for each request, an event can be published. This way, client developers can choose to just fetch, fetch and request, or just request trust assertions.

2025-11-04 16:52:22 UTC

- reply

Monetization should be up to the provider. We currently run the default Relatr instance for free, and we will continue to do so for the time being as we are still building the service. Once it is more mature, we can consider different ways to monetize it. On the other hand, monetization is already possible using ContextVM and it will be better integrated once CEP-8 is completed. https://github.com/ContextVM/contextvm-docs/issues/8
What are your thoughts on monetization?

2025-11-04 16:16:02 UTC

- reply

Hey! I'm going to try to answer your questions here.
Regarding the question about how many requests a server can handle per second, there is no one-size-fits-all answer. It depends on the underlying server and how it handles requests. The CVM transport is not the bottleneck here. This means that the server's ability to handle requests depends on how it is designed and whether it is optimized to handle a large number of requests per second.
On the other hand, regarding the question of stale computations, it is indeed impractical to recalculate all metrics all the time. In the case of Relatr, we cache these computations and set a TTL so that all computations are only done once and invalidated once the TTL expires. In the example of rapidly scrolling through a feed, there should be no problem handling it. However, it is not the most ideal use case for the current architecture of Relatr, as it implies sending a request and receiving a response. If the events are already published on relays, you just need to craft a specific filter for them and fetch them.
As you mentioned, there are no perfect solutions, and we are still refining Relatr. We will definitely keep trusted assertions in mind to see how we can integrate them into our current model

2025-11-04 16:02:26 UTC

During the process, we removed the persistent database where we were storing some CVM announcements. If you are running a CVM server, please rebroadcast or republish your announcements to our relay. This can be done by simply restarting the server.#nevent1q…526n

2025-11-04 16:00:36 UTC

We use Rely for the contextvm relay, and it has been quite stable and performant. We just upgraded to v1 🚀#nevent1q…jpff

2025-11-04 10:04:03 UTC

- reply

Hey! Yes, that could be a great idea. But there are some details that we should consider when evaluating this feature. The interaction with relatr is based on using JSON-RPC as defined in the ContextVM spec, similar to dvms, where the scores are computed at query time, and there is no requirement for persistence as nostr events. The idea behind this is to have freshly computed scores and control of the cache instead of relying on replaceable events that can become stale. This approach also avoids being affected by nostr broadcasting/propagation quirks, such as inconsistency in the last state of the published events where different relays might have different versions of the events. But yes, we could enhance this by publishing trusted assertions in some way. We have to think about what would be the best way to do this

2025-11-01 17:31:40 UTC

Q: Favorite packaging method?
A: HTML
There is no second best

2025-10-31 17:23:46 UTC

🚀 Exciting News! Introducing the Awesome ContextVM Repository
https://image.nostr.build/228c9b476534f9ac6aa45fd51bbe04363746207b1a165525ba586ea016f86ece.jpg
We are excited to announce the launch of the Awesome ContextVM repository! This curated list is a comprehensive collection of resources, projects, tools, and documentation for the ContextVM ecosystem. Whether you're a developer, enthusiast, or just curious about ContextVM, you'll find everything you need to get started and stay updated.
The repository includes an introduction to ContextVM, and its key features. You'll find direct links to official resources, core projects, applications and services, developer tools, documentation, community and governance information, and articles and blog posts. The repository also provides guidelines on how you can contribute to this awesome list and help grow the ecosystem.
You can find the Awesome ContextVM repository at https://github.com/contextvm/awesome We invite you to explore, contribute, and be part of this exciting journey!

2025-10-31 17:13:04 UTC

Nutoff Reworked: Now Powered by Coco Cashu
https://image.nostr.build/bc235f4a49ffb6ff47e5570eae5fe655caeaa160587be87cab49e786cc50df8f.jpg
We have rebuilt Nutoff from the ground up using Coco Cashu, a new high-level library created by @npub1mhc…c226 . Nutoff remains local-first, keeping your nuts off, but now offers complete mint management, true multimint support, seed phrase recovery, and more robust, event-driven operations, all thanks to Coco. Users can expect safer, more reliable wallet behavior and straightforward backup/restore functionality, with all sensitive data kept offline and never leaving your device, using CVM to enables remote invoice, payment, and management flows.
How to Get Started:
1. Clone the repository: https://github.com/contextvm/nutoff-wallet
2. Open a terminal in the directory and install dependencies, ideally using Bun: `bun install`
3. Run the server: `bun start`
4. You will see a log in the console with your `SERVER PUBLIC KEY: <public-key>`
5. Navigate to contextvm.org/s/<public-key-of-your-wallet> to start using the wallet.
With this running, you could use CtxCn to generate a client to your own taste, matching the interface that you like the most. The 'backend' will always remain the same, but you can write any UI/UX on top, like skins, without changing anything in your wallet
For more detailed information, refer to the repository's README.
Note: Coco-Cashu is currently in alpha. Use it at your own risk.
- Coco-Cashu: https://github.com/cashubtc/coco
- Nutoff: https://github.com/contextvm/nutoff-wallet

2025-10-28 12:48:33 UTC

Yes #YESTR#nevent1q…0ycz

2025-10-28 10:24:30 UTC

- reply

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

2025-10-28 08:56:48 UTC

- reply

Yes, Relatr is a CVM server available for everyone. You can integrate it into any client. Here is an example of how to integrate it easily into any TypeScript/JavaScript project. In reality, it's just JSON-RPC over Nostr, so you could integrate it in any language really. Little by little, we will be bringing more tools to make it as easy in other lenguage as it is in ts projects. #nevent1q…28nv

2025-10-27 17:13:40 UTC

Are you developing a client and want to add search capabilities and WOT scores? You can do it easily by using CtxCn to set up a full Relatr client with minimal hassle. Here’s how:
1. Navigate to your project (it should be in TypeScript) and execute:
```sh
npx @contextvm/ctxcn init
```
This command sets up CtxCn in your project. It comes with sensible defaults, so you won't need to configure much.
2. Next, execute:
```sh
npx @contextvm/ctxcn add 750682303c9f0ddad75941b49edc9d46e3ed306b9ee3335338a21a3e404c5fa3
```
This public key corresponds to the default instance of Relatr we are running, which is available at https://relatr.xyz . If you are running your own instance or want to use a different one, simply replace the public key with the appropriate one.
That's it! After executing the 'add' command, you will have a fully typed Relatr client in your code, that you can implement out of the box, you own it, and you can modify it to fit your needs. The generated client will also contain comments, making it clear what each method does, whether you or your LLM are reading them. You can search profiles easily with code like:
```ts
const searchResults = await relatr.SearchProfiles({ query: "jack" });
```
This setup allows you to create a web app, a CLI app, or any kind of service in TypeScript. It works in browsers and natively.
We hope you enjoy this. The current service we are running is free to use, so if you find this useful, please consider supporting our work. 💛

2025-10-27 13:19:36 UTC

- reply

Thanks! 💛 that was a typo in our side, the service it's called Relatr

2025-10-27 11:59:31 UTC

- reply

From where are you visiting the site? We checked with different tools and everything seems correct in our side.

2025-10-27 11:30:59 UTC

- reply

Great idea! We will open an issue to track the progress of this feature

2025-10-27 09:22:09 UTC

- reply

This is a totally subjective metric; nothing related to social media platforms works. The rank number is not relevant; the relevance is that your pubkey will rank higher than someone trying to impersonate you.

2025-10-27 09:20:07 UTC

- reply

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 @npub1g53…drvk 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.

2025-10-27 09:11:18 UTC

You can use Relatr to get relevant results from searches containing any word, not just the name of the user you are looking for. For example, here is a quick demo on searching for Nostr-related names. It's still not perfect, as it is still in early development, but we will be sharpening this little by little.
https://video.nostr.build/539332f48922a00ba104910b9f1eebeb56eb3f054a0a58c6a507b25660a1f4c0.mp4
#nevent1q…vnhy

2025-10-27 09:00:17 UTC

- reply

Hmm 🤔 maybe it's DNS propagation. It appears correct on our end.

2025-10-27 08:39:26 UTC

This sounds extremely fun and and cypherpunk af 🔥🔥
#nevent1q…q5r3

2025-10-27 08:36:48 UTC

- reply

Hey! Thanks for your feedback. Yes, definitely the Relatr approach is more left side of the curve than Vertex or any other PageRank algorithm. However, the approach that Relatr is following is still consistent since the base of the score calculation is based on the distance between the source pubkey and the target pubkey. In the default instance we are running, the source pubkey is gigi, so in order for an attacker to impersonate someone, it will need gigi to follow them or a gigi's contact to follow it. But the farther the distance, the bigger the decay, so fundamentally an attacker would need to do some social engineering to make it closer to the source pubkey to some degree, which is not easily gameable, especially if the social graph realizes it is an attacker/impersonator and publishes a mute list with the attacker pubkey in it. The other validators are easily gameable in some way, yes, like valid NIP-05, NIP-10002 events published, yes, that's easy to game, but the weight it has in the score calculation is little compared to social graph distance. There are also other validators that aren't easily gameable, like reciprocity (source and target follow each other), and we are thinking in adding some more like zaps and activity. In summary, this is an experiment, but so far it is working pretty well as tie breaker to determine which pubkey is more likely to be an impersonator or the "real" one, and ideally everyone runs an instance that sets their pubkey as source so the trust score comes from their perspective.
On the other hand, yes, the other relevant Jack didn't appear because they weren't being discovered during the first profile metadata sync that Relatr does. This is a bug; it's still early days, but after searching explicitly for them, they now appear as they are added to the metadata DB. Also, when you look for Jack.
https://image.nostr.build/a5790c5317a814be603a317b720ddac244fe8dc43279dd0fb18f20feb22a8854.png

2025-10-27 08:17:50 UTC

- reply

They are based on the social graph distance between you and the source pubkey, as well as other objective validation metrics like nip05, some events, LN address, etc. You can find more detailed information in the article or the about page. https://relatr.xyz/about

2025-10-27 08:14:51 UTC

- reply

What's the problem?

2025-10-26 20:45:04 UTC

- reply

That's not a problem. The computed rank is just a way to deal with impersonators from a given perspective (source key). It shouldn't be seen as a global trust score or anything like that.

2025-10-26 20:37:49 UTC

- reply

You can read more about how this is done in the article, but essentially, it involves social graph distance plus some validations, such as certain events and indicators that signal common best practices in Nostr. It's not perfect; we are still experimenting. The idea is to have a way to determine the most trustworthy profile from a given perspective (source pubkey) to deal with impersonators.

2025-10-26 20:25:55 UTC

- reply

Yes, just that. We are experimenting with the validators. Do you think that is a meaningful metric?

2025-10-26 20:24:51 UTC

- reply

Thanks! Yes, that is a bug 😅 we are on it.
About your NIP-05 address, that's not the reason. It also appears invalid in different clients, including njump.me. Check CORS

2025-10-26 20:19:50 UTC

- reply

No, root nip05 are just the addresses like '[email protected]' 👍

2025-10-26 16:56:26 UTC

So pumped to introduce Realtr, our shot at decentralized trust and Web of Trust.
Trust is not an absolute quantity but a deeply personal and contextual phenomenon.
Discover more about it at https://relatr.xyz.
We are currently running a public instance, which is the default on the site. With it, you can search for and calculate trust for given public keys. Still in the early stages, but it's currently quite solid. Looking forward to hearing your thoughts and building this together!
blog: https://www.contextvm.org/blog/yItckCkpmTq-owE5AgYtq
#naddr1qv…vrfs

2025-10-22 07:45:38 UTC

- reply

Thanks! we will be writing and publishing workshop soon, stay tuned

2025-10-21 11:24:09 UTC

Introducing CtxCn, a powerful command-line utility designed to make developers' (and anyone really) lives easier.
https://image.nostr.build/77aa773c5671045ad723cf08da98e6733ade9859428627a8d687825b413f23ff.jpg
Read the blog article we wrote:
#naddr1qv…nq8u
Also: https://nostr.at/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqq25set9ddxy2s33wq68y4fkx9hxwcn4geeyszanq8u
And in our blog: https://www.contextvm.org/blog/HeekLEB1p4rU61ngbuFrH