Thread

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. nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h 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 nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 ‘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 nostr:npub1healthsx3swcgtknff7zwpg8aj2q7h49zecul5rz490f6z2zp59qnfvp8p. 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 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z understands well. nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup nostr:npub17plqkxhsv66g8quxxc9p5t9mxazzn20m426exqnl8lxnh5a4cdns7jezx0 nostr:npub1qe3e5wrvnsgpggtkytxteaqfprz0rgxr8c3l34kk3a9t7e2l3acslezefe

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 } ``` https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs/blob/main/README.md

You’re a sick pedophile.

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

You’re a pedo