Replying to Avatar franzap

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

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!

Reply to this note

Please Login to reply.

Discussion

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?

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.

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.