Nostr Web Client

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.

Gzuuus 1mo ago 💬 2

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

Reply to this note

Please Login to reply.

Discussion

david 1mo ago

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.

Vitor Pamplona 1mo ago 💬 2

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

Gzuuus 1mo ago

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

Vitor Pamplona 1mo ago 💬 1

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.

Gzuuus 1mo ago 💬 1

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

Vitor Pamplona 1mo ago 💬 1

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?

Gzuuus 1mo ago

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.