Let’s talk about two levels of verification and how to achieve them in a scalable, social way.
Level 1:
You make some connections, which include someone from a seed group, none of which is someone you knew previously. This is what currently happens at “verification parties.”
Level 2:
You go to the seed group and bring family or friends. You’ve connected to someone from the seed group and your close connections have done so, too. Your close connections have indicated in the connection that you are “already known.”
I think the key to scalability here is that it should be possible to have people getting level 1 and level 2 verification simultaneously in the same meeting, and especially that separate groups of family and friends can be achieving level 2 verification at the same time.
The meeting instructor can instruct you to mark a connection as “already known” if they came with you to the meeting, and encourage people who got level 1 to come back with family/friends to get level 2.
I think it could soon become the norm that most people are getting level 2 immediately, but people who show up without knowing anyone can still get level 1 so they feel they’re making progress.
It may help to see the new options for the connection screen, since it hasn’t been released yet:
I like the Idea.
My only concern is that sometimes people just want to be verified fast, and they, instead of choosing “just met”, will go right away with already known so they’ll be verified with lvl 2.
I have 3 ideas to mitigate this issue:
1st: the option of already known only shows to an specific qr code, that means that you have a 1 on 1 qr code, a many to many for just met, and a many to many to already known.
2nd: only show the already known option after they mutually confirm each other before. This has issues on meetings cause usually you show different qr codes, and probably multiple people will try the already known feature.
3rd: Set parties for friends and families: there’s some calendar tools that allows for people to take time slots for meetings, can be 10 minutes meeting, in which the person should be verified before they can use it, that way we know that they have done the process right.
P.s: Is there a possibility to have a brightID stars app for admins, or managers that can have more tools like flagging, special qr codes or others?
I’m not worried about this. Some people will try it; some won’t. Some will be too worried that they’re risking their level 2 verification if they do it incorrectly, so they’ll try to do it correctly. If you choose “already known” for someone who doesn’t do the same for you, it doesn’t work. Also, I think it will soon become the norm for most people to come with a family member or friend who invited them, which is exactly what we’re going for.
If we’re still worried about this, or it becomes an obvious problem, we can try some ideas. Even with the ideas to mitigate the problem, people might match up with people they find in our servers and arrange to connect to them as “already known.”
To avoid the behavior @monomesa said where people will try to use “already known” for everyone and hope some people do the same, we can give a penalty to a person who chooses “already known” when someone else chooses “just met.”
We could subtract mismatched levels from matching levels–so if you had 10 connections where you chose “already known” and the other person chose “just met” and 10 where you both chose “already known” they would cancel each other out and you would have 0 qualifying “already known” connections.
We could record someone’s initial confidence level choice for the purpose of detecting mismatches, since we allow people to change the confidence level. (We could store both current and initial level).
If we let people know there’s a penalty for a mismatched choice, it will stop 99% of people from naively trying it.
Connections with “already know” level will be most important thing that different algorithms will rely on to verify users based on. So I’m absolutely agree with you that one of the most important problems that we should try to solve is to prevent such connections.
I try to add a different discussion with this subject and include your suggestions.
One question is that why should they join the call together? Why do you prefer joining a call with a friend over simply having a single connection with already know level beside showing up in a call.
It seems you are after preventing a specific type of attack where an attacker create multiple accounts and join with each one to a call with different manager and connect them together with already know to have them all verified. But it seems attackers can do exact thing with a friend, so each one can create multiple accounts, show up in a different call with each account and have all of accounts verified together.
It shows that they know someone whom they can invite to seed community.
This level is less about attacks (although this attack is harder because it requires an accomplice) and more about encouraging honest people to use the “already know” level correctly at least once. If we care about connection confidence levels at all, we need to encourage users to use them in the way that we intended.
I think we might get better results if we ask someone to bring a friend to a call rather than send a friend to a call, because it requires some coordination. Otherwise, you could be lazy and fulfill the requirement simply by making random “already know” connections to everyone you find on discord. If the “already know” connection must happen in a group connection, then you should try to use it correctly, otherwise you run the risk of the other person marking you as “just met,” since that’s what they’ve been instructed to do. It’s easier just to actually bring a friend. Sure, if you have no friends, you can make friends with someone on discord to fulfill the requirement. Coordinating with someone to join a meeting with you sounds more like friendship than spamming out connection requests and hoping someone will connect. I think many people will find bringing an actual friend to be the path of least resistance, which exactly what we want.
It makes sense to have such an achievement in the client and have such a verification to help client verify if users fulfilled that and check that achievement, but as you mentioned it can not help a lot in preventing attacks.
I think it’s very important to find solutions to prevent users from making already know connections to someone they do not know. I started a discussion about that here.
If you’re talking about superficial friendships that really should be “just met” then the solution is to find ways to use the even higher confidence levels.
