Introduction

The internet world is at an impasse. With increasing pressure from users for freedom of speech, and unwillingness from monolithic companies to loosen their indoctrinated moral grip; humanity loses as a whole. The internet contributes to 12% of the Global GDP and has grown 7x faster than any sector in the past 4 years. It’s clear that something so substantial to our economy should facilitate the proper measures in order to ensure that users won’t be exploited, correct?

Elon + Twitter

On March 27, Elon Musk first expressed his distaste for how Twitter handles user censorship and verification. To this I responded:

“In order to properly facilitate freedom of speech, we also need a universal identity mechanism”

In the time since that tweet, Elon Musk has successfully purchased Twitter and will be taking it private. This is in hopes of alleviating shareholder agenda as an influence over the product roadmap. In his statement after the purchase Elon stated that “Authenticating every user” was one of his initial goals. This presents an opportunity for Elon’s ideals to be brought to fruition with the technology being built at Sonr.

TBDex: The Incumbent

TBDex is a liquidity protocol being developed internally by the Square team as a means for discovering liquidity and exchanging assets when the existence of social trust is an interactable element of managing transaction risk. TBdex incorporates a lot of essential verification specifications present in Sonr including Decentralized Identifiers (DID), Verifiable Credentials (VCs), and Identity hubs. With TBDex being the potential candidate for Twitter’s new verification procedure (due to Jack Dorsey’s involvement in both companies), it’s important to assess the drawbacks of its architecture before being set on a choice.

1. Architecture Philosophy

The most glaring problem is the philosophy behind TBDex. The protocol is being designed with existing financial providers in mind and seems flexible enough that developers could integrate existing authentication methods and systems of records. This creates a mechanism where multiple sources dilute the actual verification property of identity. Existing sources are flat-out not designed for decentralized identity in mind and should not be incorporated into the fundamental primitive of the verification mechanism.

2. Phishing

Under the “Risks & Considerations” section for wallets in the TBDex white paper, it states that a hacker could pose as an on-ramp and off-ramp PFI node in order to steal a user’s personally identifiable information. Pending code implementation, it is unclear as to how TBDex handles PII in their protocol but as I’ll detail later on, there are remedies in place with Sonr to prevent this risk. The bottom line is you can’t pose such a considerable risk involving secure assets to wallet developers who are a layer removed from the verification implementation.

3. Reliance on Wallets

TBDex utilizes wallets as the means of generating verifiable credentials, which brings a myriad of problems along with it. Any system which allows users to generate accounts on a whim which are only protected by a small combination of words is not a secure, nor an effective, way to uniquely identify a human being.

Sonr: The Solution

The Sonr Team has thought about the problems presented by TBDex in great detail and has uncovered some essential truths that will help mitigate them.

1. Wallets are features not products

The fundamental functionality present in most wallet implementations is essentially standard. As market adoption increases, the apps that make wallet interactions an afterthought will be the ones to be able to reach mainstream product-market fit.

2. You’ll always have an infinite number of internet accounts, but only a finite number of devices connected to the internet