Why Nostr? What is Njump?
2024-05-26 01:45:16
in reply to

ManiMe on Nostr: This is why I want you to work with us on making bombproof Sovereign WoT for Nostr. I ...

This is why I want you to work with us on making bombproof Sovereign WoT for Nostr. I am gonna host another panel discussion on this topic. Will you join us?
quoting
Thank you for being part of this second panel discussion in our ongoing Sovereign Webs of Trust series to find consensus around solving for WoT on Nostr.


I’d like to use this thread for “post panel” conversation and questions. (Instead of retreating prematurely to an issues thread in the NIPs GitHub repo.)

Speaking of which …
Searching for “WoT” on NIP issues only brought up ONE result, in which and are basically discussing the SAME points that we did today. ☝🏼

https://github.com/nostr-protocol/nips/issues/1039

Here’s what’s on the table:

1. “is trusted” attestations should be part of a list event or each as individual events?

2. “is trusted” attestations should be private to author, private to author and “trusted” account, or public for all? (implementation and privacy concerns?)

3. “is trusted” value should be a binary or scalar? (or presented as binary but manipulated as scalar?)

4. “context of trust” (I trust so and so for X but not Y so much) should be embedded into trust attestations … or derived at “runtime” when content filters are applied?

5. What (in broad terms) would a content filter spec look like, where anybody (client, relay, DVM, or individual) could “publish” a filter for end users to “subscribe” to? Such filters could take ANY event data on nostr (including “is trusted”) to produce “recommendations” for content, accounts, and other stuff. IMHO, this is where rubber meets road for WoT on Nostr, and is often overlooked in light of implementing “is trusted” trust attestations.

Hopefully between now and next panel we can nail a few of these, and have some new voices as well. 💜
Author Public Key
npub1manlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqvyn9tn