# Kusama Automated Registry Identity

Authors: [yangwao](https://twitter.com/yangwao), [vikiival](https://twitter.com/vikiival)

[Code Repository is at github.com/vue-polkadot/apps/tree/identity](https://github.com/vue-polkadot/apps/tree/identity)

[Setting identity](https://wiki.polkadot.network/docs/en/learn-identity) such as legal name, twitter or riot in substrate ecosystem can increase trustfullnes between participats.

Through the research about identies we found [great article by Chevdor](https://www.chevdor.com/post/2020-01-registrar1/) where he describes manual user judgenement where **he needs to check recieved signarure by other human.**

We've realized that doing **judgments by human mind** could be exhausting, could result in **human error** (improper verification) and late delivery.
Why not solve all issues at once? After all, we are building trustless systems here.

The weakest point here is Registrar as it's going skin-in-the-game with own reputation and giving you judgment level based on their process and fees. We can not do anything about it, but we can **speed-up** the process here by automate this.

We think registrar are a **super important piece of trust that shouldn't be given to anyone.** Could have financial impacts on how UIs are identifing them.

### Rare case of registrar process

[How does the process of registrar looks like](https://kusama.polkassembly.io/referendum/56)

Points of being registrar in discussion [58](https://kusama.polkassembly.io/referendum/58)

### Our case
The goal of this short article is to present automatic **judgement process** using commnon services such as **telegram** and **phone number**.
We picked these use cases, because we see potential of making judgement process simplier.
Moreover, telegram bot could run with **public auditable logs** as a serverless function. The same goes when the user who requested judgment, sent **SMS** to our public number.

### Channels
In addition, we can extend our service with following channels:
- telegram bot
- phone number using sms
- smtp server for email verification
- twitter bot anyone can DM it with(out) follow
- riot bot

Now for simplicity of solution we've decided to run it as **serverless** function outside of Substrate ecosystem.

### Economical constraints

Right now rule for setting identity on-chain for Kusama is [10 KSM deposit](https://wiki.polkadot.network/docs/en/learn-identity#setting-an-identity) and processing fee - decided by registrar.
> Setting the identity on-chain currently requires a deposit set to 10 KSM. Those funds do no go anywhere, they remain yours but are locked in your account as long as the identity is set.

As we see in the snippet below each registrar has different processing fee.
Registrar #0 is ask `25 KSM` as processing fee. On the other hand Registrar #1 wants only `5 KSM`. This opens many doors with new economic incentives.

identity.registrars: Vec<Option<RegistrarInfo>>
[
  {
    account: FcxNWVy5RESDsErjwyZmPCW6Z8Y3fbfLzmou34YZTrbcraL,
    fee: 25.000 KSM,
    fields: []
  },
  {
    account: Fom9M5W6Kck1hNAiE2mDcZ67auUCiNTzLBUdQy4QnxHSxdn,
    fee: 5.000 KSM,
    fields: []
  },
  {
    account: EK8veMNH6sVtvhSRo4q1ZRh6huCDm69gxK4eN5MFoZzo3G7,
    fee: 1.000 KSM,
    fields: []
  }
]

### Afterthough

In future we believe that this could work as [offchain worker](https://www.parity.io/substrate-off-chain-workers-secure-and-efficient-computing-intensive-tasks/) and bootstrap nice automated identity & reputation systems in headless and autonomous way.

# Under the hood

Work is being done at [github.com/vue-polkadot/apps/tree/identity](github.com/vue-polkadot/apps/tree/identity) by [@yangwao](https://twitter.com/yangwao) and [@vikiival](https://twitter.com/vikiival)

### Creating identity as User in KodaDot

User will fillup registration form as follows in Set Identity window in [KodaDot UI](https://twitter.com/KodaDot)

On the background it looks like this

User->Apps: setIdentity using payload
Note right of Apps: Extrinsic submission
Apps-->Substrate: extrinsic event!
Substrate-->Apps: identity set!
Apps-->User: setIdentity done!
Note left of User: User is happy,\n but w/o green check mark ✅

### How challenge is created

<blockquote class="twitter-tweet">
<p lang="en" dir="ltr">No I decided to not open source the scripts for now but all the input and the outputs are verifiable by anyone.</p>&mdash; Chevdor (@chevdor) <a href="https://twitter.com/chevdor/status/1270707748691341313?ref_src=twsrc%5Etfw">June 10, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

As we are not aware how current challenges are created, In initial idea we decided to use **uuid generator**. We believe that we could find more robust solution.

As we mentioned we generate **uuid** for user.

const { v4: uuidv4 } = require('uuid');
uuidv4(); // ⇨ '1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed'

### Example Payload

After we generate challenge for user, example payload is sent to user.

{
  "account": "DksmarhWHaogeqDZDMpuzquVpSau6wUK6zXm8861WjnbXHo",
  "challenge": "1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed",
  "display": "yangwao",
  "riot": "@yangwao:matrix.org",
  "email": "[e-mail]",
  "tel": "[phone]",
  "telegram": "@yangwao"
}

User then needs to sign challenge with his/her account. We need to send signed message back to registrar.

We can chceck if the data are correct using **Verify signature**

### User Requests Judgement from Registrar

Phone/Telegram process upon `api.tx.identity.requestJudgement(Dksmar...bXHo);`

User will be instructed to send signed challenge to Telegram bot

User->Registrar: requestJudgement \n('Dksmar...bXHo')
Note right of Registrar: bot picks on-chain identity \n to provideJudgement() \n for Dksmar...bXHo
Registrar->User: Can you sign this challenge \n with your account \n and send it back \n to this telegram handle \n @KusamaVerifyBot?
Note left of User: Signs challenge \n with account \n to be verified at \n /apps/#/toolbox/sign
User->Registrar: Sending signed challenge \n to @KusamaVerifyBot!
Note right of Registrar: Magic part 🔮 \n bot will do verification \n schnorrkelVerify(data,\n signature, keyringPubKey)  
Registrar->User: You are doing well, sign is \n cryptographically verified 
Note right of Registrar: provideJudgement(0, \n Dksmar...bXHo, Reasonable)
Registrar->Substrate: provideJudgement(...args)
Substrate->User: Wild green check appears on your fancy UI

## Code

### Telegram bot

Briefly description how telegram bot could work if bot is in charge of registrar pool.
Also TG BOT will have publicy auditable logs where it will put verification transaction on-chain.

User->TG BOT: verify address Dksmar...bXHo

TG BOT->Substrate: query identityOf(Dksmar...bXHo)!
Substrate->TG BOT: identity info
Note right of TG BOT: Check if user's handle \n equals identityOf(Dksmar...bXHo).telegram
TG BOT->User: You are approved, \n your identity matches!
Note right of TG BOT: Telegram handle is valid

### Conclusion and Future work

We believe that jugdement verification process could be automatized and human registrars could spend their focus and energy differently.

In future we believe that this service could run on offchain worker using decentralized logs and database.

Note:
If you are interested with hacking around identity here is couple of usefull queries:

api.query.identity.identityOf;
api.tx.identity.setIdentity;
api.tx.identity.provideJudgement;
api.tx.identity.requestJudgement;