The objective is to allow users to assign a subjective confidence when making a connection.
One could imagine a slider from “obvious spam” on one end, to “the most trustworthy person I know” on the other, with the default being somewhere in between.
Let’s discuss how user-supplied confidence levels could be used and implemented.
Excited to see this topic up for deep discussion here. I think this could be a killer feature for brightID for a bunch of reasons. It will give our algorithms far more information to utilize and it will be more engaging for users as they interact with each other.
I imagine a year from now we may have an elaborate UI, gamifications, and lots of interesting algorithms parsing the rich data. But for now let’s get a quick v1 out the door. What simple version can we spin up in the next 10 days so people can start playing with it. This is a feature we need to see users interact with. Having this in a usable form for the Gitcoin rush is going to be key to our success
.
Overall I love that idea.
But we need to think a bit about the negative (“obvious spam”) side of the slider. This kind of changes the meaning of “confirm connection” - Right now a confirmation is always a positive thing, i “confirm” an implicit assumption that the other person is existing.
With the slider to the negative side i can confirm a connection, and at the same time say “this is not a human being”. This will be a conflicting message/experience for the user, especially if there is also a “reject” button. How can the user decide if he should confirm with a negative setting or right away click reject? He likely does not understand what is the difference.
And does it make sense at all to connect with an “obvious scam” contact?
So maybe it would lead to a more consistent UX if we have the slider only in the positive range, from 0 (“i just saw that guy in the meeting, so he is probably human”) to 100 (“that’s my wife”).
Very good points. I think “confirm” and “reject” would need to be replaced. Maybe a slider plus a single button. The text for the button could change based on the position of the slider (e.g. “confirm spammer”), or it could be a static, generic “submit” button.
The idea to connect first before flagging a spammer came from Mahdi. It’s important to prove that a user actually tried to connect with you (including spamming QRs or connection codes) before you flag them as a spammer, otherwise setting that flag could be abused.
Maybe we could also not show the profile of a user that has been marked as spam by the majority of the verified users that have connected to it because the profile name and image could themselves be spam or offensive.
If we want to allow connections to have a confidence level, it should be a separate operation. The reason is: If I’m a spammer / scammer and someone tries to get me to co-sign a connection operation that says I’m a spammer, I wouldn’t sign it and I would keep phishing until I find people that give me a good confidence level.
Being able to set the confidence all the way to zero probably means we don’t need to have the concept of “removing” a connection. Setting certain flags can set the confidence to zero; other flags could set the confidence to some other low or medium level (such as the “I forgot who this person is” flag Luke suggested). This is simpler than supporting a remove operation. A low-confidence connection could be hidden in the UI, and not returned by the API–so it appears as if it has been removed. If you want to raise the confidence of a connection, connect to the person again. Having flags change the confidence level is more fine-grained than having them remove people from groups. We can reserve removing people from groups to group admins.
I have some thoughts on how confidence data could be used.
The first use is related to spammers used as part of a larger sybil attack. If a user has more low-confidence connections than high-confidence connections to verified users, the anti-sybil algorithm doesn’t consider them–it’s as if they don’t exist on the graph unless their situation improves (which is likely for real people and unlikely for sybils). They can’t be verified and no trust flows through them. This stops accounts used in partially-successful spam attacks from boosting the scores of collaborating sybil accounts. This should prevent wide-net spam attacks from being useful.
The second use is probably obvious. The confidence could be used to weight the edge between two connections; since setting confidence is unilateral, the lower of the two confidences levels could be used as the edge weight.
Neither of these addresses the issue of targeted sybil attacks, where the attacker abuses existing trust or attempts to deceive a small number of people. I’m still of the opinion that what’s described in the white paper about “health” (which is staking something which external apps look at to give or deny extra rewards) is the best approach, but I’m open to changes or alternatives.
Good point to split the operations. So the first operation is the connection which has to be signed by both parties. Then each party submits an additional operation to set the confidence level that only requires their own signature.
This requires some default/failsafe handling on our node, in case the second operation does not get through for any reason - the confidence level should be treated as an optional additinal information, not mandatory.
Circling back to the UI and timeline - what can we do in time for gitcoin? If we target removing the reject button this has some implications on other parts of the app and backend. We need to have the functionality in place to not show connections that have been confirmed with negative confidence.
I think it’s a higher priority to launch group connections, notifications, and fix known issues and issues that pop up related to them. The confidence level feature may have to wait until the middle of round 7.
I guess we may gradually move to removing the “Add Connection” operation as mutual connection creation and reduce things to “Set Confidence Level”, but I agree that we should start by adding new operation beside “Add Connection” operation.
So initially this operation can only be sent by someone that you have connection with. In fact we are considering having connection with someone as allowing them to talk about us.
So we should have default value for confidence level.
I think default level should be “human” as @UBIpromoter mentioned in keybase, that means I saw this person in a remote call but I do not know him.
I can’t see this link, but as @castall mentioned on keybase frontend channel:
I imagined it as 4 or 5 discrete levels (is that what you mean by categories?), not percentages.
Yes. Don’t forget there can also be connections that represent spam or attacks. See also Rating a connection (and not removing) We should remove the ability for one side to remove a connection.
I imagined it as 4 or 5 discrete levels (is that what you mean by categories?), not percentages.
I’m not sure how it will work on the backend, but i always think 0-100 (or normalized vector values 0…1) offer a lot of flexibility for score calculations etc. We don’t need to make this available in the UI, but for the API this might make sense. This will allow flexible modification of the UI at any time.
I think the most flexibility comes from naming the levels. Otherwise you can be stuck with having to keep track of things like: “33 used to mean ‘not sure’ but then we decided it should be 25 and now 33 is ‘neutral’” You would have to run scripts to update the numbers should they change, whereas if you use named levels, you can change their mapping to a numerical value in one place.