Chirp - Kusama's Twitter

As the technical education team at Web3 Foundation, it is our duty to push the envelope with interesting proofs of concept in order to entice other developers to follow suit and build interesting experiments of their own.

With that in mind, we're building Chirp - a Twitter clone on Kusama which under the hood uses the system.remark functionality. This post will not go into detail how the app works - we'll cover that in an upcoming webinar, but will instead explain why I - Bruno Škvorc - am applying to the Kusama governance to become the third identity registrar in the system.

Registrar

Kusama has an on-chain identity system which allows people to add metadata to their accounts. This metadata can, in turn, be validated by registrars - companies and individuals who have been added to the registrar list by the on-chain governance.

A registrar will usually charge a fee to perform this service, and it will focus on certain fields on a given account - like validating the email, riot handle, and Twitter account of a given address.

However, given that the two current registrars on Kusama currently charge 25 and 5 KSM respectively to do this, and both rely on a full set of personally identifiable information to be added to an account, I feel like this is unfair to potential Chirp users - both financially and from a privacy perspective. Tweeting should be possible somewhat anonymously, after all.

Chirp's registrar, if approved, will serve only as a means to protect against basic Sybil attacks, as described below.

Basic Sybil Resistance

As a very basic method of spam protection and Sybil resistance (the resistance against a user creating many alternative accounts), the Chirp registrar will check for the following:

1. [BURN] Did the account applying for verification burn 1 KSM token by sending it to CaKWz5omakTK7ovp4m3koXrHyHb7NG3Nt7GENHbviByZpKp and did the account log the proof of this burn into a custom field?
2. [VERIFY] Was the account already validated by registrar #0 or registrar #1?
3. Does the account have a chirp field set? (the username they want in the Chirp network)
4. Did the account commit 1 KSM as the verification cost?

If either [BURN] or [VERIFY] check out, AND condition 3 and 4 are true, the account will be auto-verified to a level of "Reasonable" but only on one field: chirp.

While this does not prevent someone with a lot of KSM from Sybil attacking the system, it does provide other benefits:

1. The attacker's funds are drained rapidly (2 KSM or more per verified account)
2. Half of the attacker's funds are given to all other KSM holders in the form of deflation due to KSM being burned.

Proposal

The proposal with the pre-image hash

0x90a1b2f648fc4eaff4f236b9af9ead77c89ecac953225c5fafb069d27b7131b7  

...proposes to add the account E4x8NJPyoNsx1EAgoUKGo1a8FcZpw6Y2XZKNQuqAuZUqjjA, identified as Bruno | W3F / Chirp-registrar, as a new Registrar. To validate that this account is indeed behind this proposal, please verify the following message from the address E4x8NJPyoNsx1EAgoUKGo1a8FcZpw6Y2XZKNQuqAuZUqjjA:

The account E4x8NJPyoNsx1EAgoUKGo1a8FcZpw6Y2XZKNQuqAuZUqjjA is announcing candidature for a registrar. The purpose of the registrar is app-specific in that it will only provide rudimentary spam-protection for the Chrip application. This spam protection requires proof-of-burn and a commitment of 1 KSM per validation of an account.

The hash to verfiy is: 0x16134f8be6f2ee24ded009ed0e4ac35d095f1c327f19f050d8d5497ad441884a3675f061aac846259580afadc00c4ceacf48f4a0461697ca6e38651397192902

The proposal has been submitted to Democracy and can be seconded.

Future plans

While the registrar will be owned and operated by Bruno Škvorc at first, employee at Web3 Foundation, the application logic of the registrar will be fully automated and the key controlling the registrar's account will be turned into a multi-sig registrar as soon as time permits. At that point, the Technical Education team at Web3 Foundation will have multi-sig authority over the key.

This registrar's purpose is app-specific, but this does not prevent other dapps from using its verifications to similarly protect themselves from spam without infringing on people's privacy.

What about...

... the fact that you can simply read proof of burn transactions from the chain, or that an account was verified by someone else already, and don't really need this registrar?

This is true, but it makes things much harder for Chirp. Nothing prevents un-verified accounts from posting system remarks that match the Chirp tweet format, but the official UI will be scanning these remarks and rendering them based on certain rules. One of those rules is the account having been verified.

If we didn't have the verification on the account itself, we'd have to scan the whole blockchain for that account's transactions until we find the burn TX and only then would we show their chirp to people. At scale, this falls apart. Instead, by adding a custom field to an account which contains the TX as proof of burn, Chirp can immediately check the account's validity without a significant performance degradation.

Think of it as a database versus a plaintext file of content - a web 2.0 application could certainly store all its data in text files on the hard drive, but querying those in a structured manner to show relevant and linked data quickly and effectively would be a pain. An indexed database is the only solution that makes sense. Think of these verified accounts as the database part of Chirp.

... the fact that someone with a lot of KSM can register a bunch of accounts?

See above under Basic Sybil Resistance.

... the burn address? Do you have the key to it?

No, the address has been generated from a null-key, which means it can never have a private key which would unlock it. Any funds sent to it are effectively burned. You can verify that the address is indeed a dead end by following instructions in this StackOverflow post.