Before diving in here, it’s importation to point out that Know Your Customer (KYC) and Identity Verification are two very different things.
Now that we’ve reached this point in humanity’s timeline, many of us have performed digital transactions online (involving currency). As a result, many of these people are now familiar with what KYC means and the various KYC rules that exist within our respective jurisdictions.
But, in my experience, very few people have grasped the concept of Identity Verification.
Both KYC and Identity Verification involve collecting information about a human being, prior to giving them access to certain capabilities.
Typically, there are laws that govern commercial transactions (transactions involving currency), which is where KYC compliance comes into play.
However, if you are simply trying to build a website or another type of software application (such as an app or, better yet, a decentralized application (dApp)) that doesn’t involve commercial transactions (such as an information-based website or even a game), KYC laws become irrelevant and you only need to worry about Identity Verification (and only the forms of Identity Verification that you want your software application to recognize and/or accept so that user roles can be properly assigned within the software application).
When designing your application, depending on what type of Identity Verification System or protocol you want your application to run on, there may or may not be some hard costs associated with your chosen Identity Verification Protocol, which is particularly important if/when your application needs to scale to a global level.
At this point, if you aren’t sure what the word “protocol” means, it’s just a fancy word for a step-by-step process, such as IF/THEN logic, a formula, or even a recipe.
With this in mind, designing an Identity Verification Protocol can be a mind-boggling endeavor, depending on what type of software application you are designing.
In my experience, when designing protocols, the simpler the approach, the better.
As some of you in this community have already stumbled on, I recently shared a thought piece on HIVE, which summarizes my viewpoints on humanity to date and my concerns about our future.
In this thought piece on HIVE, I mentioned my desire to play a game (an interactive game that my father and I originally envisioned) with my entire family.
As I alluded to in my thought piece on HIVE, I think there is a way to design an Identity Verification Protocol that would provide anonymity to its users, starting with 3 users/human beings.
To avoid starting from scratch here (and reinvent the wheel), I realized that humanity already has a head start, as Follow My Vote released their Intellectual Property (IP) (with respect to their designs for an open-source end-to-end verifiable voting system capable of hosting elections securely online) into the public domain in January of 2021.
This IP already incorporates an Anonymous Voting Key Registration Protocol into the overall system design, which allows for independent verifiability of transactional data stored in a blockchain database (i.e. decision data (a vote(s)) stored in a database (a ballot box)), all while protecting each participant’s right to privacy (i.e. their anonymity) within the system.
After mulling things over (while watching one of my favorite movies, Dr. Strange), as luck would have it, I now think we might be able to build on that protocol and make it work for this game in a way in which we can scale the dApp to a global level, all without charging any fees (meaning without requiring KYC).
To clarify, if you take the time to understand the different user roles of this system and how the flow of information goes throughout Fig. 2 of our patent application, you’ll see how anonymity is achieved for a user (i.e. a voter), prior to the user casting a decision(s) (i.e. their vote(s)) to be stored in the blockchain database.
From there, imagine 3 users/human beings in a room that all know the true identity of one and other, all whom have never played this game (meaning that they don't exist within the game), that then choose to form a group of 3 in order to play this game, by first downloading and installing this game/application/decentralized application (dApp) from a development platform on a preferred device of which the user owns.
From there, each user/human being in the group of 3 can submit their Personal Identity Information (PII) to each of the other users/human beings in the group of 3 (including themselves), who would be acting as Identity Verifiers in this scenario. This type of PII could be any type of information, as long as each user/human being in the group of 3 agrees that the chosen type of PII is an acceptable form of personal identification.
As an example, the type of PII chosen by the group of 3 could be something as simple as the user's/human being's name (or even a nickname).
Once all 3 users/human beings have their PII verified by the Identity Verifiers and their sovereign identities are created within the system, the rest of the Anonymous Voting Key Registration Protocol would be executed, registering anonymous voting keys to all 3 users/human beings in the group of 3.
From there, the users/human beings in this group of 3 can go about their lives playing the game/application/dApp, meaning that any of the 3 users/human beings in the group of 3 can create a poll(s) or issue(s) on which any of the 3 users/human beings in the group of 3 can cast a vote(s).
One cool thing about this game/application/dApp is that, at any point in time, should a user/human being choose to do so, that user/human being can connect another device that they own to their anonymous voting key, so that they can continue playing the game/application/dApp however they wish, as they live out their life.
Once all 3 users/human beings connect on a poll/issue, meaning that all 3 users/human beings in the group of 3 vote in the same way on a poll/issue (such as believing that taking another person’s life is wrong, regardless of the reason), a shared connection (a swarm) is created/generated between all 3 of the users/human beings in the group of 3 (while each user/human being remains anonymous) based on a newly discovered common ground, meaning from a shared belief. At the time a swarm is created/generated, a public key and a private key (a key pair) is created/generated for that swarm to use within the game/application/dApp.
However, should any of the users/human beings in a swarm of 3 users/human beings decide to change their mind on the poll/issue that connected them, the shared connection (the swarm) is instantly disbanded/dissolved and that swarm's key pair can no longer be used within the game/application/dApp.
As other groups of 3 users/human beings decide to join the game/application/dApp (in their own way), they can cast a vote(s) on any poll(s)/issue(s) that any of the 3 users/human beings in those groups of 3 create; and naturally, over time, another shared connection (a swarm) is likely to form in the game/application/dApp.
[NOTE: Here’s where the SWIDCP gets interesting.]
However, should a group of 3 users/human beings decide to join the game/application/dApp by submitting the same type of PII as another group of 3 users/human beings and create their each of their sovereign identities using a mix of Identity Verifiers approved by the original group of 3 users/human beings that already exist, these two groups of 3 become one group of 6 users/human beings within the game/application/dApp that can create poll(s)/issue(s) and cast vote(s) and verify data on those same poll(s)/issue(s). So forth and so on.
Another way in which I was thinking this protocol could work is that, once a swarm is created/generated, each user/human being in a group that vote(s) in the same way on an poll/issue is automatically added to the swarm that already exists around that poll/issue. In this way, should one or more of the original 3 members of a swarm change their mind/vote(s)/stance on the poll/issue, the swarm isn’t instantly disbanded/dissolved.
In the User Interface (UI) for this game, each swarm could have its own profile page, which showcases the data relevant to that swarm (as stored in the blockchain database); and, at the bottom of each swarm’s profile page, you could have links to other swarms that involve 3 or more users/human beings that are also involved in the swarm that pertains to the profile page in which you are viewing.
In this way, the users/human beings playing this game/application/dApp could navigate the game in a way that focuses on the common ground that we share with each other as human beings, above any other approach.
The reason that I’m calling this the Swarm Wise Identity Calibration Protocol [SWIDCP] is that I believe that we are all human beings, first and foremost, and the only thing that truly separates us from one and other is what we believe to be the truth. The more data we collect on what we believe as humans, the more we will truly get to know who we really are.
In other words, I think that the SWIDCP, when combined with this game/application/dApp, in this way, will calibrate and recalibrate the truth in our beliefs, as individual human beings and as a human species, over time.
All of this is to say that, this game/application/dApp could turn into a search engine that people use to discover the truth about humanity and/or what we believe to be the truth.
In this way, the SWIDCP could be considered a formula/recipe for truth serum or elixir.
In closing, all beings should consider any of the ideas discussed in this post as being in the public domain. So, if you want to take these ideas and run with them, be my guest!
Dear @onelove, we need your help!
The Hivebuzz proposal already got an important support from the community and is close to be funded. However, it misses a few votes to get past the return proposal and your could make the difference!
May we ask you to support it so our team can continue its work this year?
You can do it on Peakd, ecency,
https://peakd.com/me/proposals/199
Thank you!