Mydi - Your Web3.0 Identity

Mydi lets you create a public social profile for all of the decentralized web.

Comment 1

Mydi - LightPaper

Frank Jia - October 1, 2021

Note: Mydi is currently live on Solana Devnet at https://mydi.vercel.app/

Introduction

The increasing adoption of Web 3.0 technologies, specifically decentralized apps (dApps), has unique ramifications for the definition of digital identity. Users typically interact with dApps by connecting their blockchain wallet, thus sidestepping the need to create segregated user profiles for different apps. As the user base of these dApps continues to increase, the blockchain wallet becomes the user's identity.

But this mapping of entity to wallet is not one-to-one. An individual can create an arbitrary number of wallets on a blockchain. Thus, an individual can manage multiple digital identities. But unlike the centralized data ownership of Web 2.0 social login, the individual has complete control of these identities.

The future of the distributed web is uniquely capable of this many-to-one mapping. A person can now manage an unlimited number of separate personas (one for work, and another for personal use, for example). Additionally, the nature of sovereign wallet management means that this individual has ownership and control over the data that each identity is publicly associated with.

We thus see that the self-ownership of blockchain wallets enables a new and unique paradigm for digital identity management, yet there exists no intuitive way to associated a public social profile with a wallet address.

Mydi - The Protocol & dApp

At the core, Mydi is a protocol for users to manage their public profile on the blockchain. Mydi establishes a common, blockchain-agnostic schema for user information storage and management. This schema can be applied to any supporting blockchain. Once a user's information is published, the created profile can be openly queried by any decentralized application on that blockchain. To enable anyone to create one (or multiple) social profiles, the Mydi dApp creates an intuitive interface for a user to view and manage their identity.

The goal of Mydi is to enable the creation of public social profiles that is owned completely by the user. The user has control over what information they expose to the public. This is distinctly different from the Web 2.0 model, whereby the platform has ownership of the data.

Stakeholders

Under the Mydi protocol, there are two stakeholders: validators and users:

Users have complete control over their public profile - this includes reading, writing, and deleting entries under their profile. Users also grant access to validators to edit their profile on their behalf.

Users are incentivized to use the platform to leverage the possible dApp integrations resulting from a public social profile. Because this profile is publicly accessible on the blockchain, dApps can retrieve a set of information (such as display name or email) about the user without asking. For example, a platform can automatically populate a user's display name after the user connects their wallet, without having to ask the user to fill out an account creation form.

Validators are external entities that can modify user profiles on the behalf of the user. By default, only the user can create and edit "records" within the public profile. However, the user can grant permissions to validators to write to specific namespaces within their profile. If the user fully trusts the validator, they can grant permission to write to all namespaces.

The first and most obvious use-case is that a user might want to delegate editing of their profile to an external service for a better user experience.

But, enabling validators has a perhaps more important benefit - enabling trust in the public data. Take the example of a Twitter social account integration - if I have full control over my profile, there is nothing stopping me from writing numFollowersOnTwitter = 10,000,000. As such, external dApps cannot trust this profile if using this information for their services.

So, let's assume that Twitter or an external OAuth service is a registered account on the blockchain. To "verify" the metadata, the user grants permission to this account to write to a specific namespace - in this case, twitter. The user then logs in through their Twitter account, and the validator updates the user's Twitter entry to reflect the validated data. When this entry is made, the blockchain reflects that the Twitter authority has signed the entry. Thus, querying clients can be sure that the data within the twitter namespace is valid.

Protocol Schema

With an overview of the protocol and the stakeholders, we can now explore the schema of the stored public data. We use a pseudo-Typescript format to describe this schema for readability.

Each user profile is stored like so:

// Identifier of the wallet - ex. Pubkey on Solana
type WalletIdentifier = string;

// This is stored on the blockchain
interface UserProfile {
        // The set of allowed validators for this profile
    validators: {
        [validatorKey: WalletIdentifier]: {
                        scopes: string[];
            last_authorized: number; // Timestamp for authorization
        }
    },
        // Public user data
    data: {
        [namespace: string]: {
            metadata_uri?: string; // Can be empty if no metadata
            last_updated: number;
            validator: WalletIdentifier; // Either external validator or user
        }
    }
}

How this data is stored will vary depending on the blockchain, but must be able to be adapted and transformed into this format. The validator entry corresponds to the set of validators that the user has granted permissions to. Within each entry, the scopes array holds a set of scopes. Each scope corresponds to a namespace within data that the validator is allowed to edit. In cases of complete trust, users can grant the all scope - which allows the validator to write to all namespaces.

The data entry reflects a set of public data that the user has published about the profile. each data "item" is stored under a namespace. For example, a Twitter account connection would be stored under the twitter namespace. The user (and allowed validators), have complete control over what to publish under each namespace.

Some examples:

The general namespace can hold a metadata_uri field that points to the following JSON file:

interface UserGeneralMetadata {
    name: string;
    photoUri: string;
    description: string;
    // ...and more fields
}

The twitter namespace can hold metadata like the following:

interface UserTwitterMetadata {
    handle: string;
    numFollowers: number;
    numFollowing: number;
}

But what if the user doesn't want to expose their public Twitter handle? They choose what to expose:

interface JohnDoeUserTwitterMetadata {
    numFollowers: number;
}

In this case, the only public data is the number of followers.

We thus see that the ability of the user to have complete ownership over the profile data allows the creation of true pseudonymous profiles. The user shares only what they wish to expose to the public.

Mydi dApp

The Mydi dApp provides an easy-to-use interface for users to manage their profiles. Additionally, Mydi acts as an authority for common social account integrations as well as CAPTCHA verification. The goal of Mydi's dApp is to kickstart adoption of the protocol by reducing the barrier to creating a profile. Additionally, we built in social account integrations and human verification so that other dApps can begin to query the Mydi protocol for public user information.

We made a conscious decision to not store any centralized user data on the Mydi platform. This means that all social OAuth authorizations are transient - once the user chooses the subset of data that they wish to publish to the blockchain, we permanently discard the rest of the data. This is to maintain the privacy of our users.

Applications & Integrations

The power of the Mydi protocol lies in the ability for any dApp to immediately access public user information. Here are a few applications and possible integrations of the Mydi protocol.

Whitelisting for NFT Releases

Recently, we've seen issues in NFT distribution where users can create bots that buy unfair numbers of NFTs. This circumvents any smart-contract logic that prevents a wallet from minting more than X NFTs.

Mydi profile data can act as a whitelisting mechanism for NFT drops by using the captcha namespace. NFT distributions can check the captcha field of a given address:

const UserCaptchaData = {
    metadata_uri: "", // No metadata needed for a captcha
    last_updated: 123456,
    validator: "SOME_TRUSTED_PUBLIC_KEY",
}

If the field doesn't exist, the dApp can redirect the user to an authority, such as our web-app, to create their profile and complete a CAPTCHA verification.

An example user flow could look like the following:

  1. User enters the NFT minting app
  2. User connects wallet, the minting app queries their public profile and fetches the captcha namespace
    • If the user does not have a public profile (or has not completed a CAPTCHA): The minting app directs the user to Mydi, where the user can create a profile and complete a CAPTCHA under the Mydi authority.
    • If the user has a verified captcha, the minting app makes sure that the validator public key is from a trusted account - for example, Mydi's public authority address.
  3. If all these checks are successful, then the NFT minting app adds the user to its whitelist.
  4. The user can now mint NFTs, whereas bots cannot.

One-Click Login Profiles

Integrating dApps can reduce user friction by querying user profile data directly from Mydi instead of asking for common items such as display name for each sign-up. Additionally, dApps can request permissions from the user to write to unique scopes within their profile. This enables Mydi to act as a decentralized public social data store for all dApps on a given blockchain.

Web 2.0 ↔ Web 3.0 Gateway

Mentioned briefly in the whitelisting section, Mydi acts as a bridge between Web 2.0 social media and the new Web 3.0 paradigm. By acting as a social account verification authority, Mydi enables integrations such as Discord & Telegram bots to automatically associate a user profile with a wallet address without having to integrate OAuth 2.0.

This enables unique applications such as gated communities for holders of NFTs, or Discord guilds restricted to DAO members holding a certain token.

Pseudonymous Profiles

By allowing users to share only what they wish, wallets are no longer completely opaque. Instead, users can choose to maintain profiles that hold some sort of public information or credibility. For example, an individual may choose to share that they have 10,000+ Twitter followers or has 500+ stars on their Github repositories. While the exact identity of the wallet is still unknown, there is some "street cred" associated with the profile

Next Steps

Partner Outreach + Integration

The Mydi protocol is powerful because it enables a web of social public profiles. As such, integrations with existing dApps on the Solana blockchain is key to the adoption of Mydi. As we have finalized an alpha version of the protocol, we can begin to prepare for mainnet launch by exploring integration possibilities with existing platforms on Solana.

Improved Tooling for Querying & Integration

We want to make it easy for any dApp to manage and query user profiles on the Mydi protocol. We will focus on creating developer tooling, such as NPM packages for browser & Node.js dApps and Pip packages for Python dApp backends. These packages would enable:

  • Querying of profile data
  • Requesting of authority permissions (to enable a dApp to write to specific fields within a user's profile)

Expansion to Other Blockchains

Mydi is blockchain-agnostic. This means that the Mydi schema and protocol can be supported by any blockchain. An implementation for Terra is in progress, with planned expansion to Ethereum & EVM-compatible blockchains.

Built With

  • magic
  • next.js
  • solana
Share this project:

Updates