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

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 💛

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.

De nada ;)

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

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.

🚀🚀

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.

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