I’d love to see a NIP for a unified API that a client can use to talk to each one of these WoT Service Providers. A unified NIP would make life easier for the dev — integrate multiple SPs at once, no need to do them individually — and would empower the user to select which SP to use. What do you think?

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

We should unify our efforts. A handful of NIPs to spec out APIs to talk to WoT Service Providers. I suggest: 1. Nostr WoT Connect — Vitor’s suggestion. This allows users to adjust their preferences, eg select algos, adjust parameters, etc. It would include new user sign up. The idea is clients like amethyst can build the front end for users to adjust their preferences, and users see their preferences take effect everywhere they go, which means no need to change WoT prefs over and over again with each new client. 2. WoT Service Provider Management API. This would be for operators of the WoT Service Provider to manage the service. @cloud fodder suggested this and can perhaps take the lead. 3. Maybe a third NIP that describes an API to fetch trust metrics. This is similar in purpose as @npub1wf4p...dgh9 ‘s WoT DVM NIP which Vertex uses, but this would not use DVMs. I am guessing a heated discussion can be had over DVMs, one that we won’t resolve in the next week, so let’s just give the community a choice: fetch metrics by this vanilla API NIP or via WoT DVM. We need some way to come together on these NIPs, and asap as the WoTathon looms near. We can help organize this at @nosfabrica. We should have input from every WoT service provider: Brainstorm, relatr, Vertex. (Others?) But we also need to take into account the perspective of the other side of these APIs, the clients, a perspective that @Vitor Pamplona understands well. @Pip the WoT guy @Jeroen ✅ @Sebastix

Don’t forget 👀 The GrapeRank library which I you and I built together … takes in a simple json object which can be passed in however the host is setup. ``` GraperankSettings = { interpreters : [ { protocol : "nostr-follows", iterate : 6 }, { protocol : "nostr-mutes", }, { protocol : "nostr-reports", } ], calculator : { attenuation : .7, rigor : .2, minscore : 0, precision : 0, devmode : false } ```

GitHub

graperank-nodejs/README.md at main · Pretty-Good-Freedom-Tech/graperank-nodejs

Contribute to Pretty-Good-Freedom-Tech/graperank-nodejs development by creating an account on GitHub.

Yes! There will be more APIs yet to come, in addition to the ones I listed above. For example, an API between interpretation engines and graperank calculation engines, as in the below figure. Our first step at NosFabrica is rebuilding Brainstorm. We’ve hardly had much time even to think about interpretation engines. I’ve been thinking I need to write up a long form article about the role of interpretation in WoT. https://camo.githubusercontent.com/8ffde3dca78c198814db954b4599ca273a3e00718af150e6c67d9d0bab925c1c/68747470733a2f2f692e6e6f7374722e6275696c642f7141574a5532345455624859647250532e706e67