-
Notifications
You must be signed in to change notification settings - Fork 308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reputation data-type #20
Comments
My proposal is to have an event format like {
"id": "...",
"kind": 7,
"tags": [
["p", "pubkey-of-person-being-rated"],
["honest", 97],
["judge", 90],
["driver", 25],
["any-other-category", 12]
],
"content": "Paul is great person, but not good with cars."
} Apps can decide which tags they will use. The basic ones most apps would care about are "honest" and "judge". "honest" means this is not a thief or scammer or whatever. "judge" means how much we trust their judgement of others, so we can inherit their judgements of others (and also someone that marks us as a good "judge" can inherit our judgements and also this next person's judgements, and so on). |
While the network is small it doesn't make much sense ot implement deep recursion, although that is not super hard to do, but all those decisions are to be taken by the user and clients, I just want an event format flexible enough. Many people (@Kukks, @nGoline?) have expressed their opinion that putting some cost on judgements make them worth more (because prevents sibyl attacks?). I think proof-of-work or other things are generic enough that they can be added to any event, for example, as a tag |
Datatype sounds perfect! |
By dofus proof-of-account you mean proving you are someone on Twitter and stuff like that? That can be done with a scheme like https://github.com/fiatjaf/nostr/pull/15/files, but instead of relying on relays I think it can just be a purely client-side thing (although relays may also use these to limit user access etc if they want) added to event kind |
I think this kind of thing fits nicely in my proposal above. You just need a relay (and it doesn't have to be a relay, can be any service or entity of any kind) to have a known Nostr pubkey and publish its own reputation events. If my service anti-thief-attestation.com wants to assert the Nostr key "abcdef" is not a thief they can just publish an event tagging that key as Even if the user doesn't know anti-thief-attestation.com, the BUber client can query their reputation events in the background and show that to the user like "you don't know this guy, but our partners have said he is good". |
It would make sense to me that signing the rating would also be part of the data type too right? |
Yes, that's my idea too. |
We've talked about this idea for Secure Scuttlebutt SSB on Planetary. And I've heard it come up every so often on many social projects. It's deceptively complex to maintain high trust in the quality of reputation amidst groups of people conspiring to game the system. There is a big lesson to learn from Advogato, a FLOSS developer social network & reputation system that launched back in the day (1999) any new effort should examine where they left off: Advogato Has Failed |
this is great, imo. simple and readable and usesful. |
Can we have a reputation datatype?
[rep: [id:<string>,rating:<int 1-100>, comment: <string>]]
ID: To give context (is this rep for taxis, dentistry, cobbling, etc)
Rating: 1-100 seems the most flexible as different UIs can translate as stars, whatever
Comment: character limited comment "Phil is an excellent dentist"
Sock-puppetry can be dealt with by relays offering verification services "verified by legit-verify-relay.com", or a Proof of Account data-type #15
The text was updated successfully, but these errors were encountered: