Closed guaka closed 2 months ago
My thoughts: I wouldn't start with textual references at all.
But a trust information point can be a simple (nostr) note from one id to another id. There's no need for "smart contract" or pairing. A note can't really be expected to be deleted, but there can be updates or requests for deletion. On nostroots I would much rather start with a different system than what trustroots currently has. Something that's easier to parse and process with code, so just a bunch of dimensions of trust and type of encounter, starting with the binary stuff. Like this it's much easier for people to enter this information.
currently:
possibly good to have it more finegrained?
Keep it super simple and iterate from here.
Similarly I would like to see some kind of binary circle upvotes.
So if someone is part of the hacker circle and I met them, I can vouch for them to be a hacker. If people use this it can become super useful information to build other stuff upon.
Great idea. Keeping it simple makes a lot of sense. There's definitely something extra in a colorful text review that can really separate deeper/more sincere references, but it's probably not necessary for the basic goal. Mostly you want to know that you are talking to a real person and that their profile is not inaccurate. And the more users you see vouching for that, then the higher your confidence will be.
The solutions to dealing with spam are going to be complex, and they will be easier to address when you have more users to justify the extra work. They probably won't be needed for a while.
Regsrdless, the trickiest part is handling negative experiences. You don't want it to turn into rating their personality from 1-5 stars, and it would be useful to know if you don't want to meet them again because you generally don't like their personality or whether they did something totally inappropriate or illegal.
Possibly reporting negative experiences could be somewhat separate. I would think they would often require a text explanation. One of the advantages of having decentralized references is that things like sexual assault accusations can't be removed because of lawsuit threats. But without gatekeeping, negative references could get out of hand quickly.
Maybe there could be some binaries specifically for negative experiences, and the expectation is that you message the person who left the negative flag if you want to hear what happened? I would think there needs to be a prominent place for negative references, and you probably need to immediately know the basic category of the accusation.
NIP-77 is very relevant, it's still in draft mode and comments are welcome, especially from how it can be useful for Trustroots
see also https://primal.net/e/note147wcevmgnf6rrm5f5e9mw4qaf695whnuajuxzwgmle04njsz8u3ssraz0m
As far as programmatically developing trust scores, maybe aggregating anonymous scores would be ideal (and possibly dynamically weighting each score by each submitter's own score). I could imagine a series of y/n or rate 1-5: "would you trust this person with x" questions, with each question displaying an aggregate answer for reference readers. Probably a disservice to attempt separating individual answers/scores from their exact context to aggregate an overall score. Maybe there could be programmatic uses for extreme outlier scores like filtering or generating flags/warnings. But the end goal in this case is to help humans make decisions. So being systematic about it is a good idea, but not completely critical. This is why text based references work so well. The main questions of designing references probably center around "how can we help reviewers share their thoughts/experiences as accurately and succinctly as possible?" and "how do we deal with spam?"
commented on NIP-77: https://github.com/nostr-protocol/nips/pull/1208#issuecomment-2180204382
@guaka Take a look at NIP-64 proposal I just opened https://github.com/nostr-protocol/nips/pull/1321
discussion started at https://github.com/Trustroots/nostroots/issues/18#issuecomment-2035793698
deserves a separate issue here
(feel free to edit this description)