Tell me more?

A single NIP that allows users to control their WebOfTrust preferences with providers and see their graph evolving over time. Something that would allow any client to build interface into their profile with WebOfTrust calculators.

Something like this? CC @Gzuuus

GitHub

GitHub - ContextVM/relatr: Comprehensive service that computes trust scores for Nostr

Comprehensive service that computes trust scores for Nostr - ContextVM/relatr

yes yes yes

Yes, but make all the interface available via Nostr calls so that any client can operate the service without having to go to the service's website. For instance, an Amethyst user should be able to sign up for an account and/or call "Recompute my web of trust" from the client. Than any WoT provider can follow the interface and on Amethyst we can just make a screen to pick a provider just like users pick a wallet provider today.

That's already possible, it's the whole idea behind CVM and Relatr. You can easily integrate it into any Nostr client without needing a service website. All you have to do is call the service using its pubkey and perform a search or look up an individual pubkey. So, if a Nostr client integrates this feature, users could specify their own instance for a personalized Web of Trust computation, or use the default Relatr service, or any other public instance. The only difference is the pubkey of the service. I've already heard from people who are implementing it in their clients.

Is the interface specified as a NIP so that any other WoT project can just follow? That's the point of making a WoT connect :)

It would be great. I am skeptical whether the end user would actually pay for such low-level primitives that every social media app has built-in, but I'm open to discuss.

I am skeptical too. But I know clients won't pay. So, we will need to market these for users directly, clearly demonstrating why their WoT graph is better than any other algo in Nostr. To me it always boils down to interests and the ability for users to filter their own graph (of users and events) weighted by their specific interests. Language, for instance, is a big one. Posts (or users) in my language should be weighted higher than in any other language.

Why do you think clients won't pay? Traditionally apps are made by companies and those companies pay for the services they use. What makes you say nostr is different in this regard?

Well, I have a client and won't pay. It doesn't make sense for me to pay for any service on behalf of my users. On Nostr, most clients are too small and will never have the coding structure AND the regulatory structure to make passthroughs of cash. Damus and Primal are the only ones that can do it today. All the other 200 clients can't. Lots of other service providers wanted Clients to pay. This is not a new idea. It just has never worked. Open-source is just not good for that.

We agree with the fact that Nostr is too small right now. But email was small too, but the it grew and I imagine gmail and co. use some paid services or host then themselves internally. It's so much easier for a user to relate with Amethyst, the client they use, rather than with a service provider they don't know it exists, don't know or understand what it does. Or rather, it does things that are so fundamental they never had to pay for them.

I wasn't saying that Nostr is small. I think it is a good size for any service provider to play the game. But the apps themselves are way too small for payment integrations. And they will always be small. Apps on Nostr are like Watch faces. They don't have the time to build the supporting infrastructure to redirect cash. On the second point, yes, people trust Amethyst more than a service they never heard about, but that is fixed when Amethyst recommends services in a settings page. We pass the trust we have to providers. If we just code a WoT settings screen where you are one of the providers, users will click on it and create an account with you. The better the integration, the better the capture. That's also why I think we need to have WoT-visualization clients whose only job is to "sell" how web of trust is better than everything else. Then users just need to pick a provider and use in all apps.

Traditionally clients have the money to pay for services because they’re monetizing our data and raking in billions of dollars. Our goal is to destroy this business model and replace it with a new one. If anyone monetizes our data, it will be the end user, not some big tech platform. And WoT will be how we monetize our data. If you want to leave a review for a really good restaurant, the fiat way is you leave your review on Yelp for free and they monetize your review. The way we’re going to pioneer is that you have the option to give your review away for free, but an even better option is that you sell your review for a few sats. And I’m going to be willing to pay you a few sats for your review because my WoT tells me that you’re probably not a bot, you’re probably a person, you probably live in the same town as the restaurant, you probably meet whatever requirements I decide are important to me. idk if our #wotathon will make it this far, but one of the applications we envision for our Decentralized Lists NIP is that I can start a new decentralized list of something I want — example: best steak restaurants in some town I plan to visit next week. To do this, I publish a kind 9998 event, per the NIP, and it includes a description with whatever details I desire. I then place a bounty of, say, 5000 sats, with automatic payout of 500 sats to anyone in my WoT who submits an item to this list (kind 9999 event) until the bounty runs out. High enough bounty means your desired list gets populated quickly. How will the bounty be managed? We’re not sure. It might require some sophisticated middleware, like maybe @Tim Bouma‘s #safebox, but we haven’t thought it all the way through. We are, however, confident that a tractable solution exists and someone will build it. Can someone build it in the next 6 months, in time for the hackathon? Decentralized Lists with a secure bounty system? If someone does it, and does it well, it will be a contender for the win. We will see!

All of the above is covered in this article: View article →

I’m calling it the Uniform Control Plane.

My understanding of relatr, and correct me if I’m wrong, is that the client integrates relatr, and scores are calculated by the client. We’re envisioning that the scores are calculated by a WoT Service Provider independently of clients, then communicated to clients using Trusted Assertions or some other method, with the rationale spelled out below. btw I would love to see someone use relatr as the core engine of a WoT Service Provider. View article →

The entire specification is outside of the nips repository. What's the point? nips are a mess. Everything a developer could need to work with CVM is available at

ContextVM Documentation

ContextVM

The intersection of Nostr and MCP

But in summary each CVM server self-describes its API using JSON schema. We are also working on a 'common schema' specification so that services can adhere to a common schema. For example, Relatr could define a common schema that other instances of it or other services can use to be interoperable, as they would have the same API.

Hey! Not exactly. Nothing is computed client side, the client simply makes a call to a Relatr server. The server computes the trust score based on social graph distance and custom validations. So yes, the scores are calculated by the service provider independently of clients . As we discussed a few days ago, we are considering adding trusted assertions to the mix. This way, a client can choose to either fetch published trusted assertions, call the server, or do both depending on it's needs

Ah yes, that makes sense. The communication between client and relatr server is performed via a model context protocol API, correct? Is there a document with the MCP API spec, and would it work to turn it into a NIP? If I understand correctly (and again, correct me if I’m wrong) you’ve designed it so the communication is done under the hood, meaning the dev doesn’t have to know how the API works, and this is to make life as easy as possible for the dev who wants to implement relatr. So Vitor’s idea is this: what if I want my users to have the option to redirect their API from Alice’s relatr server to Bob’s relatr server to some other WoT Service Provider that’s not necessarily relatr (maybe it’s Brainstorm, maybe it’s Vertex, maybe some other WoT SP)? The challenge would be to make a generic API that supports multiple WoT Service Providers that may or may not calculate the same metrics in the same formats. Trusted Assertions handles this challenge well, and a WoT API should be able to do the same. What do you think? Can your MCP API spec be morphed into a Nostr WoT Connect NIP?

Yes, but the cool part is to specify the API so that any WoT that is not based on the Relatr codebase can also be used. We can do it blossom style or nostr wallet connect style. Either way, we will need something defined to avoid clients having to hard code each WoT implementation out there.

Yes, I agree. That's the reason behind the concept of 'common schemas' for CVM, so different servers can adhere to the same canonical schema. When integrating it with a client, if we use CVM, the user would only need to provide the public key of the server they want to use, or fall back to a default instance, that's it, we could use nprofiles to provide relay hints. The current methods of the Relatr API are basically two: one is a pubkey lookup, which takes a target public key as a parameter, and the other is a search, which takes a query as a parameter. These methods have other optional parameters, but there is no need to define them unless you want to tweak. On the other hand, I was thinking about using trust assertions in Relatr and publish scores once they are computed. In this case, a client could choose to simply fetch the trust assertion. However, this approach would be limited if it cannot find specific public keys. In that case, a call to a server would be required to get the score for the missing trust assertion

We envision that the ecosystem will require multiple methods to communicate metrics from WoT Service Providers to clients. Trusted Assertions is one. An API like what the two of you are discussing is another. I’d LOVE to see the two of you (and others) hammer out the details of a NIP for this. And the sooner the better, so teams can follow the NIP for the #wotathon ! What shall we call this NIP? How about Nostr WoT Connect? Its purpose will be so that users can control their settings and preferences at WoT Service Providers to which they are subscribed. It could even be used to sign up as a new customer for a SP. Clients like Amethyst could build the front end and support as much or as little of the NIP as they desire: initial sign up, modify their kind 10040 note (Trusted Assertions settings), change parameters for any given supported algo, etc.

Publishing trusted assertions would be great because we can cache them on the client in the same way we cache everything else and use Nostr REQ requests to see if updates are available as users navigate. All clients do that already for Kind 0 (to get user's name/picture). It is very easy to just add a new kind to that same request and get the scores as well. And since these are replaceables, they update only when needed (when the score actually changes, which is rare) and the EOSE can be used to only request for changes since the last event, avoiding the data use of downloading the info for the same user over and over again because we don't know if they have changed or not in the server via other methods. I will be adding them to Amethyst next, so if you publish it, let me know because I just need to allow users to set up the WoT trusted provider to your pubkey and then they will see the scores in their interface. The search interface needs an API, though. So, we might need to define the inputs and outputs in a NIP. This could be via http calls, like how blossom does, via DVMs or via NIP-50 itself (user auths and sends a search that uses the WoT of the authed user).

Literally what I haven’t shut up about for almost two years. 🤜🏼🤛🏼 View article →

@Vitor Pamplona Nostr Commerce Connect?

Yes, that sounds great! I think that trusted assertions and a DVM-like API (using CVM) would be sufficient for a wide range of use cases. Trusted assertions alone wouldn't be enough for the case I mentioned earlier, where you encounter a user who doesn't have any assertion attached. To get the score in such cases, you would need to call a service requesting the score for that specific user who doesn't have any assertion attached. The search interface API we already have in Relatr is quite straightforward. It is specifically designed to be unopinionated, just a required 'query' parameter, which is a string. There are other parameters, but they are totally optional. Regarding the interface for the API, yes, it can be exposed in different ways. I like what Profilestr is doing by exposing a REST API and leveraging different WoT providers under the hood, currently Vertex and Relatr. In the case of Relatr, it is designed for CVM, which already provides all the primitives for authentication and other requirements for a solid user/service interaction

Ohh so, you don't build the graph for everybody? You just compute assertions for users my user is requesting or has requested? That could take some time to do it on the fly.. why not just compute everything? I assume you need the graph to compute wot for others that follow me (follows of follows) but I might be misunderstanding something.

http://relatr.xyz by @Gzuuus is a good start

The way Relatr implements this is as follows: on the first server run, it takes the source public key defined in the config and the configured hops. It then starts scraping relays to obtain follow lists. Once all contact lists for the defined hops are scraped, it builds the social graph (currently using Martti Malmi's library). After that, it begins to compute the defined validations. Once this process is finished, the system is ready. At this point, if someone requests the trust score for a public key not in the graph, Relatr fetches the contact list, performs validations, and returns the computed trust score. This new public key is then added to the social graph, and the validations are cached, so this is just done once. Relatr does not attempt to build a global graph, however, you can define as many hops as you want to get a more complete picture. Even in this case, there will be instances where new public keys appear, and you'll need to compute the trust for them. I hope this clarifies the process

> “I am skeptical whether the end user would actually pay for such low-level primitives that every social media app has built-in” @Pip the WoT guy > “Well, I have a client and won't pay. It doesn't make sense for me to pay for any service on behalf of my users.” @Vitor Pamplona I think you’re both missing the WoT value prop … but in different ways. Users will pay to access WoT powered recommendations and discovery for the same reason that they pay for AI credits … but don’t pay for Google. Clients will pay for WoT services (on behalf of their users) NOT by representing the user’s npub directly but by providing their own npub’s (value added?) take on “content and user curation” … for users who DONT wish to “bring their own WoT provider” (or don’t have one). Why? Because FULLY realized WoT powered content and user discovery WILL BLOW PEOPLES MINDS … and everybody will want a piece of it. I mean … that’s just my optimistic take.

Interesting. It's weird to load a key that has no connection to the graph. Meaning that if it wasn't computed on start, then nobody in the extended user's follow (recursive) follows this key. Which means the score should be zero, no? When you get a new key to compute, how do you find connections to the existing graph of users to appropriately score it?

I agree. I would just never do WoT based on our key. I find that quite centralizing in nature and the point of Amethyst is to break these centralization points even when we are the point in question.

You may feel different once the ecosystem is established. 😉

Yes, it's weird, but there are still existing cases where this would happen, such as new users with new public keys that were not present when the social graph was created. To compute new keys, the process is to first get their contact list, add it to the graph, recalculate distances, and then, if the key is reachable because it has some connection in the graph, calculate the validations.

This is a great line of thought to come back to. Pip and Vitor are right to question whether users will pay for personalized trust metrics. The initial WoT use case is to get rid of the super obvious bad actors, and for this use case, most users will be content to use trust metrics personalized to someone else: an influencer, one of their friends, etc. At this stage, “personalization” of trust metrics would mean adjusting the parameters to case a wider or a narrower net. Brainstorm already does this. But will users pay for that? Maybe a few, but it’s not a must-have. Once the bots are gone, we turn our attention to contextual trust. This is where personalization gets more interesting. Suppose Alice is interested in sports, Bob in the latest developments in AI. They’ll want their personalized Brainstorm to keep track of everything having to do with that field — including an ever-changing ontology — and to stay up to date, which will be a complicated matter. Will users be willing to pay for this? I think some will. But what if I can piggyback on my friend’s personalized WoT for free for topics like these? Might still be a tricky sell. And then we come to the next level of complexity: privacy. This might be the hook that starts to bring in a lot of users. Maybe I want personalization of interests, AND privacy regarding who/what I’m following and why, AND I want *inviolable control over the curation* because otherwise I won’t trust the slop content being fed to me. The trick is going to be to make personalization a must-have. And not for ideologues, but for normies. A combo of personalization of interests, inviolable control that keeps out the slop, and privacy may be required to make personalized trust a must have. Which is not an intractable problem, but it will take a lot of work.

And how can I forget: personalized WoT turns the legacy monetization model on its head. No longer will you give your data away to big tech for free. You can give it away if you want, OR you can sell it for micropayments. I’ll be willing to pay you a few says for your restaurant review if my grapevine tells me with a high degree of confidence that you’re not a bot, if your previous restaurants have been helpful and in good faith, etc. But I’m not going to pay anyone for anything unless I am ***VERY*** confident in the information my WoT is feeding to me. And I probably won’t have the requisite confidence without the features in my previous note: personalization of preferences, privacy, and provably inviolable control over the trust calculations. Brainstorm will provide all of these.