Nostr Web Client

Replying to

Lez

Updated NIP-77 proposal about Web-of-trust.

https://github.com/lez/nips/blob/master/77.md

It feels clean and simple to me, also extensible, but I would love to hear feedback on that.

#wot #sovwot #wotnip #nip77 #trust #hierarchy

franzap 1y ago

Seems like nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 is working on something very similar, did you guys sync up?

I recently shifted my thinking around these complex kind of attestations, it's going to be hard to: (1) implement with good UX to actually make it work, (2) too many different opinions on how to go about it

As an example, bitcoinmints.com is already working today with kind 38000 which is definitely an expression of trust. The WoT implementation you suggest will not take into account these events? Another, if a very trusted friend (because met IRL) heavily zaps someone you don't know, isn't that a form of trust? Third, if someone is listed as "good guest" in kind 827919 for a couchsurfing-type app, isn't that a massive vouch even without signing a NIP-77 event?

Seems to me expressions of trust take very different forms, will be application-specific and therefore we should accept them as such. I'm tending to think that "writes" should be as easy, heterogenous and scattered as possible and the heavy work should be done on "reads", probably via sophisticated algos/DVMs which: (1) return a viable set of evidence to be verified client side, (2) themselves have a reputation

Reply to this note

Please Login to reply.

Discussion

franzap 1y ago

My latest thoughts on web of trust

nostr:note19kyxjsw8g3kes4yyd0j8t5a04ywur7v3fx8cyxuwmzxs522q5has3ty650

david 1y ago

Reading through Lez’s NIP now. For comparison, mine is linked below.

Both NIPs define a format for contextual trust attestations without specifying how such attestations are processed and utilized. Both NIPs allow the rater to specify a score and a confidence, and allow to specify whether trust is transitive or not, with transitive the default.

The main difference between our NIPs is how exactly context is represented. In accordance with the tapestry method, my NIP allows each individual context to be defined and represented by an individual event, which anyone can submit, which is referenced using its note id or naddr. In addition, my NIP specifies how to organize contexts into a hierarchy. The rationale is that this allows the ontology of context to be curated by your WoT. What happens if we don’t all magically agree on the meaning of a “troll” or a “bot” or something else? We need to have competing definitions and let the community decide which definition to use — perhaps different definitions at different times. Although this may seem too complicated and too much work for the user, I believe it will actually turn out to be more intuitive, LESS WORK, and LESS COMPLICATED, because most of us will be happy to delegate all of the hard work to our WoT. In addition, ORGANIZING CONTEXTS INTO HIERARCHIES IS ESSENTIAL so that trust in a parent context can be applied automatically to all child contexts; if we don’t do that, it will be necessary to do separate attestations for parent contexts but also for each and every child context, the number of which is in theory unlimited, and this would be absolutely positively definitively 100 percent unworkable and fatal to the entire endeavor.

https://github.com/wds4/tapestry-protocol/blob/main/guides/grapevineIncorporation/NIP-proposal.md

david 1y ago

I think you’re exactly right to be thinking of writes and reads separately, with writes being scattered and potentially in various formats. The heavy lifting is deciding what to do with the data, and we can be flexible in our approach: no need for everyone to use the same algo, or even to know what algos are available when creating the trust attestation.

On the topic of zaps: I think it is important to separate out in our minds the notion of PROXY INDICATORS of trust, like zaps, likes, etc, and EXPLICIT CONTEXT BASED TRUST ATTESTATIONS. No reason we can’t use both at the same time! The former exist in spades; it’s time for us to focus our attention on ways to represent the latter.

hodlbod 1y ago

Yeah, wot is basically the same as any other content-related algorithm. Different algorithms will take different things into account, and different people will choose different algorithms, maybe by use case. That doesn't mean having data structures that are explicitly wot-focused are a bad thing, they can be a useful part of the solution. But I'm with you — if someone kind 7's all of someone's notes, that's a strong signal, and doesn't require the user to maintain anything to get the benefits.

david 1y ago

Some algos will use only proxy indicators of trust, others will use only explicit trust attestations, and others will use both.

franzap 1y ago

Absolutely, well said. If people want to work on wot-focused explicit attestations, all the best. My gut feeling tells me it's not worth putting much energy in that. I might be wrong

Niel Liesmons 1y ago

Exactly! Love the Read vs Write angle you use here.

And indeed, easy writes are key. Explicit trust attestations are not easy.

Lez 1y ago

Haha, it feels a little bit like this classic xkcd: https://xkcd.com/927/

I think it's not a task of a NIP to define how we're going to use existing trust attestations, explicit (38000) or implicit ("827919") or proxy (zaps+likes). This is a field where "read" algorithms will compete. Maybe a NIP could be used to define the inputs or outputs for such algorithms, but it was not my intention with NIP-77.

I would be fine if app developers in the future chose this uniform format to express trust. I also think it's useful to have a query that returns a recursive trust graph, and algorithms can do anything on this data, possibly including other data sources. The goal is to avoid the xkcd situation as much as humanly possible.

And thanks for mentioning couchsurfing! https://www.trustroots.org wants to bring his community + reputation system to nostr, I'll contact him!

franzap 1y ago

Haha it does remind of that xkcd 😄

Re: trustroots, that's very cool. A friend and I were also planning to eventually bring it back, clearly using WoT

Fully agree with first paragraph. I just read NIP-77 and have some feedback and questions:

- I don't agree that "trust is transitive", why do you say this? It definitely scales down in an exponential way, anything beyond 3 hops is basically useless

- I think very few relays will end up supporting the REQ change, better go the DVM route as hodlbod said (plus with enough data these computations will become cpu intensive)

- Definitely like the '*', makes it easy to bootstrap

I know this was brought up earlier, but what kind of UX you think is required to start populating these events with complex data like scores 1-100 + confidence 1-100?

david 1y ago

On the topic of the UX of scores of 0-100 and confidence of 0-100:

The simplest UX would be a single button, like the follow button. Underneath the hood, you are leaving an attestation with a score of 100 and a confidence of 100 percent. Users will not need to know or think about what’s happening under the hood.

The next step up would be two buttons, like the follow and mute button. Underneath the hood, you are leaving an attestation with a score of 100 (follow) or 0 (mute).

The next step up would be either more buttons (e.g. scores of 0, 50, or 100) or a slider for the score, which you’d implement if users want more optionality.

Same thing for confidence: add more optionality if and when the users want it. Otherwise, don’t force them to have to make too many decisions.

hodlbod 1y ago

New Founding's American Forum did a really great job with presenting this using different color codes. I'll see if I can dredge up a screenshot.

Lezlancs 1y ago

Not sure where to post this in this deep thread. Here is what I think is the common part of our thinking. A simple standard way to express trust. Then we can build on top, on different directions. https://github.com/lez/nips/blob/master/77.md

david 1y ago

Simple, short, and sweet. 👍🏻

I have some other remarks —

should we open a discussion in your GitHub repo?