owned this note
owned this note
Published
Linked with GitHub
# Spec for i-am-human v1.0
Author: KazanderDad, Robert Zaremba
## 1. Overview
A protocol on the NEAR blockchain that allows verified humans to mint various Soulbound Tokens (SBT) to represent them, which, when reviewed together as a Class, will represent one and only one Unique Human as being the account owner. The Class can then be used for "human-gating" access to votes, polls, DAO membership, etc.
More specifically, version 1 of the i-am-human protocol will consist from the following smart contracts:
* I-am-human Class smart-contract: An algebraic class representing the ever-evolving proof of humanity
* One or more different smart contracts issuing SBTs, each of which certifying one or more aspects of personhood (e.g. aliveness, uniqueness, humannness). We are envisioning the following release sequence for the first SBTs:
1. **NDC Seed SBT** – Issued by the core i-am-human protocol stewards to anyone who is a wellknown and trusted active contributor in the NDC GWG or broader NEAR Ecosystem. Application based, requires face verification.
2. **NEAR Community SBT** – Issued by invitation from holders of either the NBC Seed SBT of the Community SBT. Three diferent invitations required before SBT becomes active. Issued to anyone who are or has been an active ecosystem member. No application required, only three vouches / invitations (mint events). No uniqueness verification. Note: Accounts created before 2021 will get supplemental attribute "OG"
3. **NEAR Web-of-trust SBT** – An SBT issued by randomly paired up users who validate each other during an impromptu video call. Requires prior face verification and submission of contact info which gets checked against a database of other users (hashed).
5. **KYC SBT** An self-minted SBT which acts as proof that the user has undergone KYC, but without disclosing any of the KYC on-chain.
6. **POAP SBTs** Proof-of-participation for various in-person events, which for us serve as a proof-of-aliveness. DAO managed contract, where any event organizer can apply to the DAO to get a dedicated POAP, in return for guranteeing that they will only be given to in-person attendants.
7. Standalone face verification SBT (TBD)
* Various different (non-SBT) on-chain validations
* Check that the Near account used is a named account
* Check for existence of an account on Near.social with username and profile picture assigned
* Check for age of the Near account
* Check for existence of staked NEAR (required for certain votes only, not required for personhood)
* Blocklist
* The blocklist will include all accounts from which an SBT has been recovered. This will serve as a measure to prevent selling an SBT or otherwise initiate any unneccessary transfers.
This spec describes the scope and specifications for version 1.0 of the i-am-human protocol.
* The i-am-human protocol was first conceptualized in this [hackathon entry](https://devpost.com/software/i-am-human-app)
* The spec for v0.1 of the Community SBT can be found [here](https://hackmd.io/ZvgUeoF4SMGM4InswH0Dsg)
* The current v0.2 implementation can be found in [this GitHub repo](https://github.com/near-ndc/i-am-human) and at [this website](https://i-am-human.app/)
* Further functionality for v2.0 is aspirationally listed at the end for reference
Some important tenets and underlying assumptions for this spec on include:
* Three primary characteristics are considered when determining personhood within i-am-human, and all have to be true:
* Humanness. Users have to be human. Bots, AIs etc are not allowed
* Uniqueness. One and only one account is allowed per each human
* Aliveness. Deceased users are no longer eligible
* Definition of a users personhood should be abstracted away from all other criteria. Personhood does NOT correlate to any requirement to hold NEAR or any other token, to stake NEAR, to be of a particular race, gender, age, ethnicity, to belong to any particular group or DAO or be approved in any other way
* Everyone that fills the criteria to vote or otherwise use their i-am-human credential should be allowed to do so. If an app wishes to futher constrain, then it is up to that app to do so. Criteria suc ha "acceptable" social behavior or even conformance to local laws is not part of the scope of i-am-human
* The same criteria should apply to everyone. No special priviliges for admins, founders, supporters, etc.
---
## 2. Background
The Near Digital Collective (NDC) is in the process of beeing formed, intended to be the long term governance forum(s) for the Near ecosystem. The constitution of NDC relies on three houses of governance, each of which will convene into regular congresses, and each of which will also have a frequent need to vote or take polls. NDC has a desire to move on from simple token-weighted voting to something that is more representative of the community and fair.
This is where the i-am-human protocol comes in. The protocol aims to create functionality to "human-gate" smart contract functions such as voting and polling. The objective is assertain that each human is only allowed to represent themselves (vote) once, and conversely that each vote is backed by one and only one unique human. Once this is accomplished, we can build much better voting mechanisms, such as quadratic voting or 1-person-1-vote.
Read more about the [NDC](https://gov.near.org/t/formation-of-near-digital-collective-ndc-and-call-for-participation-in-the-community-working-group/27544) that i-am-human is designed to support, and the evolution of its [voting framework](https://hackmd.io/NlFbUcC6TsaeLr7oAAdtdw?view), its [governance framework](https://hackmd.io/@robert-zaremba/ryyYTfcYi) and in [this roadmap](https://hackmd.io/0uenIyPOS1uAo4BLlxTA7Q?both#)
## 3. General Specs
> ### OPEN QUESTIONS for this section
> - [ ] Are 3 of 4 SBTs a good compromise for requirement
> - [ ] To what degree do we ask admins to defend against sybil attacks (or do we only rely on biometrics for Sybil defence)? Even if manual check is not an effective Sybil defence beyond a few hundred applicants, it is still a significant psychological deterrent...
> - [ ] Etc.
### 3.1 i-am-human SBTs
We are assuming that that credentials will be issued and minted on-chain as Soulbound Tokens, building on the standard proposed (defined?) in [NEP-393](https://github.com/near/NEPs/pull/393). In summary, we will use SBTs with the following characteristics:
* Mintable by a trusted certifier (not directly mintable by the user)
* Have a defined expiration date
* Can be renewed by the issuer
* Can be revoked by the issuer
* Can be recovered for the user by the issuer
* Can be transferred by the user
* When transferred or recovered from an address, then that address becomes blacklisted
* Can only have max supply of 1 per account
The following SBTs building blocks are contemplated to be included in version 1.0 of *i-am-human*:
* Proof of uniqueness, as evidenced by a face scan which is then compared against a database of previously scanned faces and validated for uniqueness
* Functinality provided by either [Verisoul](https://www.verisoul.xyz/) or by [GoodDollar](https://www.gooddollar.org/)
* Proof of humanness, as evidenced by trusted admins verifying applicant users, or by randomly paired applicants verfying each other, after having met the user in a video call
* This is also the scope of the v0.2 proof of concept, and the current functionality implemented on our [website]([i-am-human.app](https://i-am-human.app/))
* Proof of humanness and aliveness, as evidenced by presenting government issued ID, passport or similar papers ("KYC") and comparing them against a video selfie
* Functinality provided by several KYC providers, e.g. KYC DAO, nKYC, Fractal, etc.
* Proof of aliveness, as evidenced by asking the users to speak a random sentence and ensuring that they are saying it correctly.
* Functinality provided by [Verisoul](https://www.verisoul.xyz/)
Read more details in section 4 below about the specificiations of these five protocols that we will includ in v1.
Proof-of-personhood can be described as a neverending cat-and-mouse race against ever more powerful attackers. They will get constantly better at attacking any proof-of-personhood protocol, and as a consequence we need to get ever better at staying one step ahead of them. For this reason it is not pertinent to lock down a spec to a certain set of attribute, but we should instead design a spec that can evolve over time. Users should expect the list of SBTs and other criteria to continuously evolve over time.
### 3.2 SBT Registry
SBTs will all be minted, managed and belong in an ecosystem that we will refer to as the Registry. SBTs within the Registry will share a few common traits, notably
> [name=KazanderDad] Question for Robert: Is this an accurate definition of the Registry? Or is it narrower and only related to the blacklist?
* They will be minted on the same blockchain (Near) and will comply with [NEP-393](https://github.com/near/NEPs/pull/393)
* They will share a common blacklist
* When certain activities are performed on one SBT, this may also trigger similar activities on all other SBTs in the same account (e.g. recover one triggers recover of all)
* They will individually have marginal utility but collectively will make up enough information to determine "humanness" of an account
We refer to the ruleset that define the collective group utility of several SBTs as the Class of SBTs, which then operates on the Registry. The operation includes checking for the existence and status of required SBTs and performing algebraic checks on the collective of such SBTs.
We are specifically concerned with our own "i-am-human class" in this specification (see 3.5 below). It should be noted that any protocol will be able to define and operate their own classes too (similar to how anyone can create their own ruleset to validate various combinations of GitCoin Passsport stamps).
### 3.3 Blacklist
SBTs are not supposed to be freely transferrable between accounts without very specific reasons. This sets SBTs apart from NFTs. As a deterrent against abuse of the limited transfer/recovery privilege, we implement a "Blacklist" feature.
The Blacklist feature will trigger upon transfer events and recovery events both. When triggered, this feature will
* Move the SBT from the from-account to the to-account
* Simultaneously trigger a move of any other participating SBT in the same from-account to be transferred/recovered to the same to-account
* Add the from-account to the Blacklist
When an account has been Blacklisted then the following rules will apply:
* Future minting of any participating SBT will not be allowed
* Future recovery to the blacklisted address will not be allowed
* Future transfer to the blacklisted address will not be allowed
* Any SBT that may remain with the blacklisted address will not be eligible for any votin, polling, DAO entry, or other such human-gated activity
### 3.4 Recover and SoulTransfer
It is very important to have the SoulTransfer and Recovery functions available to users. The SBTs in the i-am-human ecosystem are designed to only be mintable once per lifetime for a user, and also to be important for that user in that they unlock important functions such as voting, polling and DAO access. Loss of the account might happen. We must design a system where such unfortunate events do not mean that users neccessarily also lose access permanently to their "proof of humanity"
The SoulTransfer function is intended to be used in cases where a user has reasons to believe that their account has been compromised, and for this reason would like to transfer out their SBTs to a non-compromized account.
Similarly, the Recover function is intended for cases where a user lost access to their private keys of the account where they keep their SBTs, and therefore would like to recover the SBTs to a new account that they have access to.
The mere existence of the Blacklist also acts as a strong deterrent against attempts at identity theft. For example, it would be of little use for a criminal to extort a user for access to their private keys, when they know that the user can simply recover those SBTs at a later time.
There should be some minimum amount of checks and balances validation before allowing a transfer or recovery to happen, in order to prevent marketing and selling of individual credentials:
* Validating that the same user owns both the from-account and the to-account, either by requiring the user to sign in with both accounts in the same transaction, or by requiring that the transfer is counter-signed with the to-account within a short period of time, e.g. 5 minutes
* Preventing known marketplaces and exchanges (e.g. OpenSea) from triggering the transaction
* Presenting the user with a confirmation dialogue, alerting them that this transaction should only be used in exception cases and only between their own accounts and that the old account will be blacklisted
* Introducing a time-delay before the next sequential transfer / recovery can be performed, in order to prevent re-use of the same credential twice in the same vote or poll, defaulting to equal to the longest voting period
> [name=KazanderDad] Question for Robert: is it even possible to require signing of one transaction with two sets of private keys simultaneously?
### 3.5 i-am-human Class
#### Class introduction
Personhood, which we define as the intersection of "humanness", "aliveness and "uniqueness", is a finicky concept to capture on-chain. Particularly, any attempt to boil down Personhood to a single-variable attribute will always be suceptible to critique, and will also be vulnerable to targeted / specialized attacks.
> One such example is the case of WorldCoin which attempts to scan the iris of all humans, and use it as the one and only key to determine both humanness and uniqueness. This approach is severely limited for several reasons: lack of scannning technology, public resistance against providing biometrics to a technology provider, lack or continued aliveness checks, and a whole host of other issues.
Personhhod must be approached as a multivariable problem. We are all defined not only by our retina, but also by our face, voice, fingerprints, as well as which friends we surround ourselves with, which government we interact with, our many online accounts, our place of residence, and much, much more.
Similarly, the SBTs in the i-am-human ecosystem each have some standalone utility (e.g. an SBT to certify the uniqueness of your face scan). But it is only when they are taken together as a whole that they become truly important. We call this a Class.
The Class is a smart contract that is designed to ingest many different SBTs issued to an account, as well as oracle validations as required for the same account. The output from the Class is a "humanness" score that the account represents based on the full collection of SBTs and Oracle inputs.
#### Overall Class requirements
In version 1.0 we will define the i-am-human class to require at minimum two of the following three options:
* 1 valid, non-expired Seed SBT or Community SBT, see 4.1 below
* 1 valid, non-expired FaceVerified SBT (face scan and uniqueness check), see 4.2 below
* 1 valid, non-expired KYCDAO SBT (government issued credentials), see 4.3 below
The reason to not require all three is that one user might have difficulty to attaing - or moral objections against participating in - one of the options. It seems prudent to allow at least one opt-out oppotunity.
However, we do need to have at least 51% attainment in order to prevent a Sybil attack by which a user might get 1 credential for each one of their three Sybil accounts. This is why 2 must be required and 1 is not enough.
Additionally, both of the following on-chain criteria have to be fulfilled
* The Near wallet account ID to be used must also be registered and matched with exactly 1 near.social account (representation of self in a social account), see 4.4 below
* The Near wallet account ID to be used must have a custom name, see 4.5 below
#### Class function specs
The class will support the following functions
* Transfer ownership
* Argument: Receiver
* Require: Caller is owner
* Require: Receiver is not empty string
* Example: Transfer ownership to the AstroDAO
* Assign required SBT / oracle / API calls and corresponding required responses
* Require: Caller is owner
* Argument: Which address to query
* Argument: Function call for the query
* Argument: Expected response
* Argument: Required or Optional?
* Argument: Weight to assign if response is satisfied
* Logic: Creates a new API requirement and assigns a new sequential ApiRequirementID
* Example: Require valid Community SBT
* Example: Require valid Verisoul SBT
* Example: Require Community POAPs dated no older than 365 days
* Example: Require near.social with jpeg and name populated
* Remove required API calls
* Argument: ApiRequirementID
* Require: Caller is owner
* Require that the identified requirement exists
* Logic: Removes the identified requirement
* Query required API calls
* Returns: A vector of all ApiRequirementIDs, including their required call functions and their corresponding response requirements and weights
* Assign required m-of-n logics and responses
* Require: Caller is owner
* Argument: Vector of ApiRequirementID and corresponding counts
* Logic: Creates a new logical m-of-n requirement and assigns a new sequential LogicRequirementID
* Reponse: Sum of weights
* Example input: Require SBTs A, B and C (but not D)
* Remove required m-of-n requirement
* Argument: LogicRequirementID
* Require: Caller is owner
* Require that the LogicRequirementID exists
* Logic: Removes the LogicRequirementID
* Query required m-of-n
* Return: Vector of all ApiRequirementID and corresponding counts
* Example: "Require SBTs A, B and D, returns weight 5, or Require SBTs A, B and C, returns weight 7"
* Assign minimum thresholds
* Argument: Vector of thresholds and responses
* Logic
* Query minimum threshold
* Return: Vector of all thresholds and responses
* Example: 5 or more returns "Qualified silver tier", 7 or more returns "Qualified gold tier"
* Query1 - Requirement breakdown of address
* Argument: Which address to query
* Require: Address is not empty string
* Logic: Iterate across all ApiRequirementIDs, making one call for each and logging the responses
* Returns: A vector of all ApiRequirementID calls made and their respective responses
* Query2 - Logic logic breakdown of address
* Argument: Which address to query
* Require: Address is not empty string
* Logic: Iterate across all LogicRequirementIDs, making one call for each and logging the responses
* Returns: A vector of all m-of-n calculations performed and their individual return weights
* Query 3 - Simple Status of address
* Argument: Which address to query
* Require: Address is not empty string
* Logic:
* First run Query 1 to get the result of all required API calls
* Then evaluate if all non-optional calls are satisifed, panic if not
* Then run Query2 to evaluate the total weight returned by each logical m-of-n operation
* Require that at least one m-of-n is satisfied or else return "Not qualified"
* Then compare the highest returned weight to the minimum threholds, returning the output of the highest threshold met
### 3.6 Application Form & Sybil-defence Database
We will need to store a database of applicants, their corresponding information, and the status of their application. The reason for this is three-fold
1. Provide an easy way of capturing applications
2. Facilitate processing of the applications
3. Keep a database of people already admitted and approved, against which Admins will cross referenece all new applicants in order to rule out a new application being a duplicate entry / a Sybil attack
Note: we fully realize that this manual verification approach is not ideal, and that it is not sustainable beyond maybe a few hundred people. At larger numbers it will be a superhuman task to thoroughly cross referencce new applications against all previous entries. This problem will be addressed in future versions.
The form will adress the following fields
* Type of application
* Mint nnew
* Renew
* Revoce
* Revoke
* Applicant's details
* Name
* Email (to which a video call invitation can be sent)
* Preferred language
* Telegram contact details
* Near social account
* Near account address
The database will address the same fields plus also the following:
* Details of assigned admin
* User name
* Near account address
* Status of application
* new
* in progress
* approved
* denied
* Time stamps
* Date submitted
* Date processing started
* Date of video interview
* Date approved/denied
* Processsing notes
* General admin notes
* Rejection reason
* Version history
Features and validations
* **Apply** - Applicant's address is populated from the signed in wallet. Type of application could be populated depending either on which "apply button" or manually selected in the application form. Status is set to "new"
* **Self-assign** - Admin's wallet address and user name is populated from the signed in wallet, and status is updated to "in progress"
* **Assign** - Allows admin to manually override prior assignment (e.g. in case assignment failed). Status is updated to "in progress, reassigned"
* **Check** - Checks the current status of the applicant's various SBTs
* **Approve** - Calls the Mint function for the applicants wallet, and closes the application if mint was successful. Status is updated to "approved"
* **Renew** - Calls the Renew function for the applicants wallet, and closes the application if Renew was successful. Status is updated to "approved"
* **Revoke** - Calls Revoke function for the applicants wallet, and closes the application if Revoke was successful. Status is updated to "approved"
* **Deny** - Populating a rejection reason is mandatory. Status is updated to "denied"
### Upgradeability
> TODO:
> - [ ] Define upgradeability mechanism.
> - [ ] Decide who and how can upgrade the smart contract.
---
## 4. Specific Functionalities By SBT Type
> ### OPEN QUESTIONS for this section
> - [ ] Which FaceTec protocol to use?
> - [ ] Which KYC DAO to use?
> - [ ] What should be true for a near.social account to be valid? Which badges should we check for?
> - [ ] Should we ask for social accounts (other than near.social) in the SBT application? If so, which?
> - [ ] Etc.
### 4.1 Community SBT
The Community SBT is the first implementation example of our SBTs. For sake of expediecy, we designed this as a semi-centralzied solution, with a group of trusted and active human participants in the NDC were selected to be DAO members tasked with validating the rest of the NDC collective and mint Community SBTs for each of them that successfully passes their validation.
Once the Community SBT has been bootstrapped and started up for some period of time, we will also token-gate access to the DAO such that only accounts with the Admin role in the Community SBT contract will be granted access to the DAO.
The SBT contract has a role "Contract Owner" which is required for many of the administrative tasks, such as
* Transfer ownership
* Requires caller to have owner role
* Requires receiver to be not empty string
* Optional memo argument pushed to the emmitted event
* Add administrator
* Requires caller to have owner role
* Requires receivers to be not empty vector
* Requires each receiver to not already have admin role
* Optional memo argument pushed to the emmitted event
* Remove administrator
* Requires caller to have owner role
* Requires receiver to be not empty vector
* Requires each receiver to already have admin role
* Optional memo argument pushed to the emmitted event
* Change max time before expiry
* Requires caller to have owner role
* Requires TTL to be not empty and not 0
* Optional memo argument pushed to the emmitted event
* Change source path for SBT image
* Requires caller to have owner role
* Optional memo argument pushed to the emmitted event
```
/// Contract owner can transfer ownership to new owner.
pub fn transfer_ownership(&mut self, receiver: AccountId)) {
}
/// Contract owner can add a new admin.
pub fn add_admins(&mut self, admins: Vec<AccountId>) {
}
/// Contract owner can remove an admin.
pub fn remove_admins(&mut self, admins: Vec<AccountId>) {
}
/// Contract owner can set max time to live (before expiry)
/// Expressed in seconds
pub fn admin_change_ttl(&mut self, ttl: u64) {
}
```
The SBT contract has a role "Admin" which is required for the following
* Mint STB
* Requires caller to have admin role
* Requires time to live is equal to or smaller than default TTL
* Requires receiver to be not empty string
* Requires receiver to be not blacklisted
* Requires receiver to not already have an SBT
* If time to live is 0 or omitted, then use default TTL
* Optional memo argument pushed to the emmitted event
* Renew SBT
* Requires caller to have admin role
* Requires time to live is equal to or smaller than default TTL
* Requires receiver to be not empty string
* Requires receiver to be not blacklisted
* Requires receiver to already have an SBT
* If time to live is 0 or omitted, then use default TTL
* Optional memo argument pushed to the emmitted event
* Revoke SBT
* Requires caller to have admin role
* Requires receiver to be not empty string
* Requires receiver to already have an SBT
* Optional memo argument pushed to the emmitted event
* Recover SBT
* Requires caller to have admin role
* Requires sender to already have an SBT
* Requires receiver to be not empty string
* Requires receiver to be not blacklisted
* Requires receiver to not already have an SBT
* Optional memo argument pushed to the emmitted event
```
/// SBT MINT: Mints a new SBT for the given receiver
/// Requires caller to have admin role
/// If `metadata.expires_at` is None then we set it to ` now+self.ttl`.
/// Panics if `metadata.expires_at > now+self.ttl`.
pub fn sbt_mint(&mut self, mut metadata: TokenMetadata, receiver: AccountId) {
}
/// SBT RENEW: update the expire time of provided tokens.
/// Requires caller to have admin role
/// `ttl` is duration seconds to set expire time: `now+ttl`.
/// Panics if ttl > self.ttl or `tokens` is an empty list.
pub fn sbt_renew(&mut self, tokens: Vec<TokenId>, ttl: u64, memo: Option<String>) {
}
/// SBT REVOKE: Removes SBT from the given accounts.
/// Requires caller to have admin role
/// Panics if `accounts` is an empty list.
pub fn sbt_revoke(&mut self, accounts: Vec<AccountId>, memo: Option<String>) {
}
/// SBT RECOVER: Transfers SBT from a give account to another.
/// Requires caller to have admin role
/// Panics if `accounts` is an empty list
/// Adds the recover_from accunt to the blacklist registry
pub fn sbt_revoke(&mut self, recover_from: AccountId, recover_to: AccountId, memo: Option<String>) {
}
```
The following queries are available and public regardless of role
* Is admin?
* Returns true if given address (or caller, if omitted) has admin role
* SBT?
* Returns information and metadata (such as token ID, minted date, and expiry date) about specific given token ID
* SBT total supply?
* Returns total amount of tokens minted by this contract
* Includes valid, expired and revoked tokens
* SBT by owner?
* Returns information and metadata (such as token ID, minted date, and expiry date) for a given address
* SBT supply by owner?
* Returns total supply of SBTs for a given address, regardless of expiry status
```
/// Returns true if given address (or caller, if account is None)
/// is an admin.
pub fn is_admin(&self, addr: AccountId) -> bool {
}
/// Returns information and metadata about specific token ID
pub fn sbt(&self, token_id: TokenId) -> Option<Token> {
}
/// Returns total amount of tokens minted by this contract.
/// Includes possible expired tokens.
pub fn sbt_total_supply(&self) -> U64 {
}
/// Query sbt tokens by owner
pub fn sbt_by_owner(
}
/// Returns total supply of SBTs for a given owner,
/// regardless of expiry status
pub fn sbt_supply_by_owner(&self, account: AccountId) -> U64 {
}
```
The Soulbound Transfer function is available to SBT token holders only
```
/// Soulbound transfer implementation.
/// Returns false if caller is not a SBT holder.
/// Adds the from_accunt to the blacklist registry
#[payable]
pub fn sbt_transfer(&mut self, receiver: AccountId) -> bool {
}
```
#### Internal note: Changes compared to v0.2
* *Add SBT image*
* *Allow expires at to be empty. If empty then assume expiry is issued_at + default_TTL*
* *Add recover function*
* *Add contract owner, implement for certain functions*
* *Transfer / recover one SBT triggers transfer / recover all SBTs*
* *Keep the TTL edit function*
* *Add username of admins*
### 4.2 Verisoul / GoodDollar SBT
Verisoul is a protocol that will ask a user to scan their face and use their voice to speak a string of randomly assigned words. The protocol will then compare the face and voice "vectors" against a database of all previously scanned vectors. The result is boleean true if the user is determined to be an alive and unique human, and a false otherwise. If successful then the protocol will mint an SBT to represent the same.
> TODO: Spec on how the interface will work. Pending review
> TODO: Determine possibility to fund Verisoul
> TODO: Select between Verisoul and GoodDollar
### 4.3 KYCDAO / NKYCDAO SBT
> TODO / TBD - Pending review of KYCDAO and NKYCDAO
> See very last section (5.3 at botttom) for selection criteria
### 4.4 Near.Social SBT
Near.social can be loosely described "decentralized alternative to Facebook" that is native to Near. It is built on a combination of web2 and web3 technology.
#### Reasoning
Near.Social is initially not sybil proof at all, nor is it really a proof of personhood. Because anyone can create as many accounts as they want, and it's very easy to do so.
So why include a requirement to create and disclose your Near.Social account into i-am-human?
The idea here is first to help raise awareness of this platform. To get people to see it and sign up for it, thereby doing good for the ecosystem by driving up user count of the platform and kickstart it. The Near community has expressed a goal of building out and focusing efforts around Near.Social, so why not help?
But more importantly, IF users started building their personality online, and it's connected to their personhood, then the stakes are higher to behave well. To to not misbehave by creating fake accounts, and thereby "burn" your personhood. So it's more of a prevention against fake accounts on near.social than it is a proof-of-personhood.
Then, as people add more friends and connections over time, it becomes a proof-of-personhood protocol. Developers can build graph analytics features and analyze what percentages of clusters are verified with i-am-human. We will collectively be building a web of trust. And when trusted people connect with other trusted people, the overall trust grows stonger. People will start caring about behaving well with their one verified account, more than they care about their non-verified accounts. It will be a positive spiral.
Also, as an added bonus people might be nicer to each other on Near.Social this way.
#### Specification
Criteria for eligibility:
* Base criteria
* Account is not an empty string, else throw error "cannot be empty account"
* Account has a legible name (see 4.5 below), else throw error "must be a named and legible account"
* A query of near.social for the account should return the following properties
* Account is registered with near.social, else throw error ("account not registered on near.social")
* Account has assigned a custom name, else throw error ("account must have an assigned name")
* Account has upoaded a custom profile picture, else throw error ("account must have custom profile picture")
* Account has more than 3 followers who already have the Near.Social SBT, else throw error ("please ask at least 3 verified accounts to follow you")
Function calls
* A eligible account will be allowed to self-trigger **Mint** of a NearSocial SBT.
* Any holder of a Near.Social SBT will be allowed to trigger a **Transfer** and a **Revoke**.
* (**Renew** is not applicable for this SBT)
Note: In order to bootstrap and seed the pool of users, we need to start with 0 followers required, then increase to 1, then 2, and eventually land on 3 once we have 20+ users in the seed pool.
### 4.5 Named Near Account ID
Near accounts by default come as a randomly generated and illegible string of characters. Users that go through with the onboarding process and fund their first acccount then get an option to name their subsequent accounts with a more legibile name.
#### Reasoning
We are proposing to make it a requirement that users register with their legible account names for a few reasons:
* **Sybil detection.** Easier for admins to remember and compare against other already approved accounts when checking for duplicates
* **Pseudonymity.** The objective of i-am-human is to allow users to be verified while pseudonymous. It is not to allow users to remain fully anonymous. Named accounts are better for pseudonyms, random accounts foster full anonymity
* **User friendlines.** We want to also build user friendliness when participating in inherently social activities such as voting and polling. Named accounts are better for user friendliness
* **Friendliness.** We also want to foster friendliness in a more genuine and general sense. When user's digital activities - such as posts on near.social - appear under their own favourite username as their unique moniker, then this encourages people to be more friendly to one another.
* **Traceability.** We do allow for soul-transfer of SBTs from one account to another. However, we don't want this to be a way of hiding. When Alice.near want to transfer his SBTs to theri new identity to Bob.near, then this should be allowed. But it should also be traceable if needed and also possible to publicise. If Alice.near was a scammer, they should not be allowed to disappear entirely and reappear as Bob.near without anyone being able to detect it and report it.
#### Specification
An account should satisfy the following conditions to be eligible
* Not allowed: Is exactly 64 characters long and contains more than 10 number characters
* Allowed: All other account names (?)
We will prevent non-eligible accounts in the following ways
* Not eligible to apply for a Community SBT
* Not eligible to apply for a Near.Social SBT
* The i-am-human Class will return false for non-eligible accounts
## 5. UI, Roles and Processes
> ### OPEN QUESTIONS for this section
> - [ ] Is one admin enough to mint and SBT, or should multiple admins approve?
> - [ ] Does the DAO fall under the House of Merit's authority?
> - [ ] Do we hire admins? How should they be compensated? How many do we need? Are they full time or part time? Do we have a follow-the-sun approach in terms of geographical coverage?
> - [ ] Should there be an application fee paid by users? Do we required users to show proof of stake before applying?
> - [ ] Should we utilize and AstroDAO to manage the admin adds/removes (as proposed here), or should we instead require 3 admins to approve adds/removes without an AstroDAO (as proposed previously)
> - [ ] Etc.
### 5.1 Role of i-am-human DAO
A DAO will be set up as a Sputnik/Astro DAO to manage the i-am-human protocol. Administrators and other trusted community representatives can be initially added to the DAO, which will act as the steward of the Community SBT contract as well as the i-am-human Class.
The DAO will fall under the authority of the House of Merit (?), and will be abide with and execute vote results in that forum.
The scope of the DAO includes to propose and vote on
* change of admins
* new admins to be added to the SBT contract
* existing admins to be removed from the SBT contract
* parameters to be changed in the SBT contract
* max time to live before expiry of an SBT
* parameters to be changed in the Class contract
* which smart contracts to include
* which oracles or other on-chain function calls to include
* how many are required of each
* how many m of n criteria are required
The role of Contract Owner for both the Community SBT and the i-am-human Class will be assigned to the Community SBT DAO on the Sputnik DAO platform. Members of the DAO will be voting on the above functions, and after a vote has been successfully passed the Sputnik DAO contract will perform a function call to the smart contracts executing the vote on-chain.
### 5.2 Administrator Role
The contract will contain a list of highly reputable accounts: admins.
#### Seeding the Admin Pool
In the initialization we will provide the initial set of addresses representing know, reputable people. They have to be KNOWN in the sense that they have made several appearances on screen in working groups such that their characteristic face and/or voice is known to several others, and REPUTABLE in the sense that they are constructively participating members of the Near community with opinions that are generally heeded and respected by several others.
#### Admin Signup / Recruitment
The signup proces contemplated for admins in version 1.0 is to leverage the standard AstroDAO feature, whereby a current DAO member in good standing proposese themselves (or someone else) to become a Admin, inclusive of a detailed and public introduction of themselves (or the proposed candidate).
Administrators will then be added and removed by function call triggered by the DAO vote as described above.
We anticipate that there may also either be a job description posted for a paid positions to entice people to sign up, or (more likely?) it may be incorporated in the job description of a few already existing trusted NDC staffers, who are then confirmed as admins by a vote in the DAO.
#### Tentative Job Description
Administrators are tasked with the following, at minimum:
* Reviewing members, determining their "uniqueness, aliveness and humannness" and if deemed acceptable then **approving** users, minting an SBT to their account
* Supporting users who lost access to their account with **recovering** their SBTs to a new account
* Renewing expiring or expired SBTs, re-certifying the users, and if deemed acceptable then **renewing** their SBTs for them
* **Revoking** SBTs for members who fail to meet the standards required for an SBT
#### Application Processing
A web form will be used to track, by applicant name and public key, if the applications are
* not started
* started, and by which admin
* complete, approved and minted), and by which admin
* completed, denied, and by which admim
Admins will be able to switch between two views to see the lost of applications
* All applications
* My self-assinged applications
Filtering should be possible based on
* Preffered language of applicant
* Name of admin
* Type of application
* Mint - new applicants
* Renew - users with expiring or expired SBTs
* Recover - applicants who lost their private keys
* Revoke - reports of abuse and Sybil attacks (users with more than one SBT)
* Status of application (see options above)
Adnins will self-assign applications to themselves according to their individual capacity to process them.
When an application has been started, it is up to each individual admin to schedule a video call with the applicant (their contact details are in the application) and review that the is a human that is both alive and unique, to the best of their abilities.
We recommend that admins at minimum perform the following checks:
* Review the application for any inconsitencies, and contact the applicant to remedy if required
* Check the status of the applicants wallet address
* Cross reference the applicant against the database of approved applications, identifying any possible duplicates
* Schedule and attend a video call with the applicant
* Ask the alllicant if this is the first time they are applying
* Review the applicant's submitted information. Identify and remedy any discrepancies
* If possible duplicates were identified, then investigate with the applicant(s) and possibly increase the requirements, e.g. ask for KYC information
* Have the applicant confirm that they understand that they can only apply once, and why this is so
* Have the applicant promise to not apply again with a different account, nor otherwise abuse the system
* Make detailed notes in the application database on what was discovered and discussed, which remedies were taken.
A major challenge will be for admins to collectively determine uniqueness, i.e. to capture any duplicate entries (Sybils) by the same person. In version 1.0 we will optimistically chose to trust that there is a low frequency of Sybils in the core team, and trust that the team of admins is capable to detect them. (For version 2.0 we plan on increasing these uniqueness checks.)
After concluding their due diligence and the video call, admins have to close down the application by chosing one of four possible resolutions:
* Approved new application, which will also trigger a Mint action, passing along the applicants wallet adress
* Approved application to renew, which will also trigger a Renew function call, passing along the applicants wallet address
* Approved application to recover, which will also trigger a Recover function call, passing the applicants wallet address
* Rejected, which will not trigger any on-chain functions
Examples of justified rejection cases include:
* Applicant found to have muktiple addresses registered in the protocol
* Applicant didnt pay the application fee, if any
* Applicant didnt pay the renewal fee, if any
* Apicant found to be impersonationg someone else
### 5.3 User Processes
Users are the key actors in the i-am-human protocol. Users can apply to be included (= receive and SBT), and once included can check the status of their SBT.
#### Applying for a Community SBT
In version 1.0 users will be asked to populate a simple form to apply to receive an SBT. This form will then be accessible only to admins who will pick up applications and start reviewing them.
Minimum information includes
* Name
* Email (to which a video call invitation can be sent)
* Telegram contact details
* Near social account
* Near account address
There are two variants of the application, and the UI will determine which option to present to the user depending on if they have or don't already have an SBT in their account
* Application to receive an SBT, available to users without an SBT
* Application to recover an SBT, available to users with and SBT
Once a user has submitted an application they can expect an admin to reach out to them with an invitation to participate in a video call. During this call they have to be present with the camera turned on, and will have to respond to various questions and instructions from the admin.
When approved, the user can expect to see an SBT minted into their account.
If rejected, the protocol will not issue any messages or status updates. (They may receive an email or notification directly from the admin off chain.)
#### Aquiring a Verisoul SBT
> TODO
> create section 4.2 first
#### Aquiring a KYC SBT
> TODO
> create section 4.3 first
#### Signing up for a Near.Social account
> TODO
> create section 4.4 first
#### View Status of User's SBTs
Users sign up and get verified for various SBTS as described above.
Users themselves can then access and review details for their own SBTs
* Reveiew SBT details such as minted timestamp, valid/expired, transaction history, etc. for each of their SBTs (by querying the individual SBT contracts and the indexer)
* See the eventual blacklisting status of their account (by querying the registry)
* Review the overarching "humanity" status across their collection of SBTs, blacklisting, and other on-chain information (by querying the Registry and Class smart contracts)
#### Other User Actions
Users can also take the following other actions on an exception basis from within the UI
* Request a renewal
* Request a recovery
* Request an SBT to be revoked
* Initiate transfer between their own accounts (which will also trigger transfer of all other SBTs in the same account, as well as blacklisting of the old account)
---
## 5. Aspirations and Known Issues
### 5.1 Known Issues
Below we list known issues, which we won’t address in v1, but we will address them in v1.1 or v2.
* Near.Social is not a proof of personhood protocol yet. By adding it now we are contributing to making it one.
* v1 relies on a centralized backend database with some PII (personally identifiable information). It's very limited in scope, but none the less PII, which is both sensitive to hacking and against our principles of trustless decentralization. We are planning on replacing (decentralizing) this functionality too and destroying the database as soon as possible.
### 5.2 Aspirations For Future Versions (v2 or v3?)
Without making any promises, the aspiration for future versions of the i-am-human protocol may or may not include the following features:
* Adding more verification protocols
* Optional KYC based on government issued papers
* Verified ownership of social media accounts
* Integration with BrightID, Idena and/or Gitcoin Passport for stronger proof of personhood
* Removal of admin role, replacing it with a peer-based review, whereby each users are randomly assigned a set of peer-reviewers
* On chain submission with a small fee, consisting of maybe three parts
* Verification fee. Then any admin can “pick” the application, and he will receive a fee back to his account as a small reward, mitigating the need to fund a salary for admins. But the fee should be small, to not discourage poor people from applying. Maybe 0.5 N?
* Storage fee. 0.005 N will be charged for the on-chain storage fee.
* App fee to cover costs for website and server maintenance and security. We are storing PII for all users in the backend Anti-Sybil database and should make sure it is secure.
### 5.3 Known Inherent Flaws
The concept of SBTs relies on publically verfifiable proofs, which is fundamentally very diferent from "verifiable credentials" as defined by DID consortiums such as w3.org and identity.foundation
The main drawbacks of using SBTs as credentials are
* the lack of zero-knowledge proofs
* the lack of partial disclosure of PII
This leads to a reluctance to add too much information about one self, or even any personal information, and hence by design encourages people to invent pseudonyms if they want to remain relatively untraceable.
For a solution where people represent themselves with their real name and/or a broader set of PII (than an email address, near address and a profile picture), a fundamentally different design must be choosen.
### Out Of Scope: KYC
One feature that is often suggested to include in i-am-human is to leverage various "typical" KYC methods, many of which we have deemed as out of scope. Here is why.
* SMS text validation.
* This builds on an assupmtion that most people ony have one cell phone
* The reason we don't like this method is that it's too easy to spoof phone numbers. There are "bot farms" with banks of phones at their disposal. These are the attackers we are trying to defend against, so let's not make it that easy for them.
* Also, not everyone has access to a phone, so it would not be entirely inclusive.
* And a lot of people legitimately have two too, so could easily get two accounts.
* KYC based on name and address
* This builds on an assupmtion that most people ony have one piece of identity card.
* First of all, the assumption isn't true at all, as most people have multiple, and could then create one account for each (e.g. driver's licence, health/insurance card and passport = 3 accounts)
* Another reason we don't like this method is the complexity of learning to distinguish between all kinds of different cards out there, combined with having to parse through all various spellings of your name and formats of your address. Doable, but certainly ot easy.
* Another reason we don't like mandatory KYC is that not everyone have access to goverment issued papers. There are 1.7Bn paperless people in the world, or 20%. We don't want to exclude them.
* KYC with National Identifier (e.g. social security number)
* This builds on an assupmtion that most people are residents + citizens of only one country.
* Again, the assumption is not true. Many are citizens of one country and residents of another, or both.
* The main reason we don't like this requirements is that many many governments either won't put the national identifiers on their ID card, or frown upon asking for the identifier.
* And, again, the 1.7Bn paperless...
Generally speaking, **all** of the above methods have in common that it would neccesitate for us to keep a backend database of personally identifiable information (PII) against which we would have to cross-reference any new applicant. Be it your phone number, ID-card identifier, your legal name, or your national identifier number... we don't want to know it, we don't want to store it, we don't want to rely on it. And we are guessing you feel the same way.
Another suggestion we often hear is that we should rely on someone else to do the KYC for us. "There are many KYC services out there". The challenge with these is three-fold:
1. They also cannot determine uniqueness, for the same reasons as mentioned above. They can only determine humnanness and aliveness, but not uniqueness
2. We don't want them to store this information (your information) either.
3. We are trying to keep this as cheap as possible for you. Those companies are trying to make a profit and charge fees
* Plus the esoteric reason that if (when) we were to explode in popularity to billions of users, then we would give them a monopolistic advantage....
The way we can see KYC possibly useful is if we can find a provider that will fulfull these criteria
1. Cheap. No or low cost per verification (<$0.10)
2. Can distinguish official ID cards from most countries across the world (including developing countries) from a fake one
3. Supports HQ photo upload and video connection across all common browser platforms and devices
4. Can verify the likeness between face on live video and the image on the official ID card = "humanness"
5. Can verify and attest to the "aliveness" of the same person, e.g. by verifying that the person can blink, etc
6. Can generate a non-reverese-engineerable hash of the face to be stored in a database, and can then compare future applicant faces against the same database
7. Or can generate a non-reverese-engineerable hash of the name and location of the person into a database against which all future applicants name and location is cross checked