Hahaha ok, thought it was something new. We think that as enshittification continues extending its shadow through the internet and digital world, it is going to be more and more valuable for individuals to be able to fully, self organize, associate, collaborate and share their resources. We feel that the infrastructure as a service model that we are seeing more and more is going to be a huge bottleneck and more discriminatory since the heavy computations they offer will struggle with a more democratized demand for the resources. So, the more people, the worse that model scales without sacrificing a competitive environment and becoming a monopoly. At the same time, things are going to get cheaper to run at low scale and people will be able to share the resources they have to satisfy demand at their scale. This vision can be true or not in the future, but it is one of the fundamental whys behind CVM, high bandwidth collaboration between individuals. If you feel curious about our point of view and ethics you can check our blog, we have some nice articles like https://contextvm.org/blog/forging-a-new-frontier

Thanks! Yes, Nostr is a whole paradigm shift, and CVM is another building block of Nostr that leverages as many of its inherent features as possible. Very powerful. We would love to know more about that concept of cognitive computing resources you mentioned. Would you mind explaining what it means?

Thanks for your words! We are glad that more people are aware of CVM and the possibilities it brings. If you ever need to clear any doubt please just ping us, we are more than happy to assist. CVM is fully open source and community driven, we all build this together 💛

🎇Meet CVMI: the Army knife we are building for ContextVM development🧑‍💻 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 #buildi

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

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.

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 and

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

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

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

Thanks and you are building awesome stuff 🔥

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

Add skills just like this `npx cvmi add` pick the one that better suits you, then 🚀

🧑‍💻 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'."

As based as super 🔥

Are you ready for what is comming? 👀