manime on Nostr: Thank you for being part of this second panel discussion in our ongoing Sovereign ...
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.
david (npub1u5n…ldq3) LezKoma (npub1elt…cume) hodlbod (npub1jlr…ynqn) Ghaz (npub1ekr…vd7t) JohnBNevin (npub1vvl…la5v) manime (npub1man…n9tn)
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 franzap (npub1wf4…dgh9) and Vitor Pamplona (npub1gcx…nj5z) 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. 💜
david (npub1u5n…ldq3) LezKoma (npub1elt…cume) hodlbod (npub1jlr…ynqn) Ghaz (npub1ekr…vd7t) JohnBNevin (npub1vvl…la5v) manime (npub1man…n9tn)
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 franzap (npub1wf4…dgh9) and Vitor Pamplona (npub1gcx…nj5z) 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. 💜