Knowing MetaID, the layer1 DID protocol based on UTXO model

What I will share with you today is MetaID, the layer1 of distributed ID scheme implemented on the UTXO public blockchain. If you are interested in UTXO or DID, you must read this article, because the following content will help you quickly get to know and master “MetaID” from the aspects of conceptual interpretation, technical principles, and data structures.

Meet MetaID

MetaID is a DID solution otherwise known as a distributed identity protocol. It can be roughly understood as: everyone has a specific ID in the entire network, and all data associated with the person in the entire network can point to this ID, including chat records, published dynamics or articles, purchase records, etc. MetaID is built into the UTXO model MVC public chain.

MetaID website: https://www.metaid.io/

Then let’s introduce MetaID, as shown in the picture above. As a user, I generated my own MetaID on the blockchain. First, there is a Root node, and there is an Info node in the next layer, which will be derived from my name node, mobile phone number node, avatar node, etc., This means that my MetaID has my basic information, and the Protocols node; to better understand it, we can label it as a “personal data folder,” and my future related data will be in accordance with the data Attribute classification — similar to a personal computer — which is classified and stored in the “On-Chain Weibo” subfolder, “On-Chain Chat” subfolder, etc.

Okay, after getting a general understanding of what MetaID is and what MetaID looks like, let’s talk about what it does, and briefly talk about it.

Bust Data Silos

What is an information island? Here is an example: I registered an account on Twitter and posted a post. Can I see the post I posted on Twitter on Facebook? Of course not, because these are two different application providers, both of which have different databases, and are independent of each other. This is an information island. So why can MetaID solve it? Because MetaID actually treats the blockchain as a public database, the dynamics I publish can be displayed by different application providers. For example, application A uses the MetaID system, and when I publish a post Z in application A, app B which also uses the MetaID system will allow me also to see my post Z in app B. If app A says it will no longer be in use one day and is about to be closed, then I’m not worried that the posted post will disappear because it is permanently saved on blockchain which means I can still see my post in App B.

Data cannot be tampered with

Due to the characteristics of the blockchain, the data cannot be tampered after it is uploaded to the chain, but it does not mean that it cannot be modified. However, modification or deletion will leave traces. The so-called modification is to use the characteristics of the MVC authentication protocol to re-uplink a version data node, and this modification or deletion is controlled through version control. This will not be explained further for the time being.

The value of data belongs to the user

This may not sound like much at the moment, but we currently have a lot of data information stored in the apps on the market, such as purchase records, search records, etc., and app vendors will exclusively recommend relevant apps based on the behavior traces of these users. Advertisement information, to achieve the best interests of application providers, can be regarded as one of the data values, and the data value mentioned by MetaID belongs to the user, which is the characteristic of its MetaID tree structure. All relevant on-chain data grows on the user’s own MetaID tree; it is up to the users to authorize specific application providers to use, paid or free, according to their personal preferences.

In fact, MetaID has many functions, and there are many places that need to be explored. For example, in games, if a user uses MetaID to generate a game character and can use it back and forth between different game vendors, the playability will be unimaginable. It can be regarded as an imagination to be achieved. I prefer to think of MetaID as a tree where different users cultivate their own data trees and grow valuable fruits on the soil of blockchain.

MetaID principle and application effect

The MetaID protocol forms the user’s own data in the form of a directed acyclic graph into its own data tree, which is collectively referred to as the tree below, which means that the data generated by a user is all under its own tree, and all the user’s actions are recorded under the tree, and is stored in the blockchain. It is different from the traditional way of managing data on the Internet. Simply speaking, it is still a bit abstract. Let’s give an example, taking the Web3 application based on MetaID — — ShowBuzz. Comparing this on-chain Twitter with traditional internet Twitter:

First, let’s briefly talk about the so-called user data tree. Figure 1 roughly depicts some action records of MetaID users on on-chain Twitter. No matter the action of posting/like/commenting, etc., it will be recorded under the user tree, which is spontaneously initiated by the user, and the data service provider cannot manipulate and delete the action records under the user tree without the user’s authorization (if readers don’t understand it, you can refer to the example I gave in the previous chapter). The user tree is a layer of folders and every step of your operation is saved in these folders. Posts are saved in the “Post” folder, and comments are saved in the “Comments” folder.

Data Generation

How does traditional Twitter get every post/like/comment for data service providers? By developing different service interfaces for each service function. The request data structure and content of each interface are different which means there are special interfaces for posting, special interfaces for comments, and so on. As shown in Figure 2, each service interface receives data and processes it into a corresponding table.

How does the on-chain Twitter, based on MetaID, generate on-chain data such as posts/likes/comments, etc? Since the MetaID protocol defines a general data structure, the method of uploading to the chain can also be unified. Whether it is posting/liking/commenting, etc., it is all uploaded in one method. The only difference is the data content. The specific content will be explained in the next chapter.

Data association

In traditional Twitter, the data is already associated with the table in the database when it is generated, and each like/comment data in the table has an ID corresponding to a certain post. As shown in the picture:

Based on MetaID on-chain Twitter, the data becomes the association between users. The data service provider associates the data according to the protocol rules and the rules of the action protocol. As shown in the figure, user B’s comment action data is for user A’s post 2, and the data service provider aggregates the data into the data format of the Twitter application, which is convenient for application display. In this way, a simple on-chain Twitter application is like this form.

Use effects

The picture below shows the effect of the actual application — ShowBuzz, as an example. Each action is recorded under the user’s own MetaID tree, and the data on the chain is captured by the data service provider, and the interaction between users is carried out to achieve the current state of the application. Of course, the action is not only posting/like/commenting, but also a series of actions such as forwarding, paid reading, etc.

Explore ecological applications: https://www.mvc.space/user/task?type=mvc-app

MetaID Data Structure

The overall protocol format of MetaID is:

<chainFlag><P(node)><txID(parent)><metaIDFlag><nodeName><data><encrypt><version><dataType><encoding>

There are 10 parts in total, and each part is represented in the table below.

The first three parts are: <chainFlag><P(node)><parentChainFlag:txID(parent)>, which are the standard parts of the MVC (MicroVisionChain) authentication protocol, and the remaining seven parts are the extended parts of the MetaID secondary protocol. With that, it can be said that the MetaID protocol is an extension protocol based on the MVC authentication protocol.

Here is an example

E.g:

How is the data of microblog on-chain constituted in the MetaID protocol format? As shown in Figure 1, the data in the figure is the data that has been uploaded to the chain, and its TXID is 6d900eda21edf50a9e1ccf25badad700da150d79b54949821cf9141ada39afab

Among them, Data stores the content of the SimpleMicroblog protocol and stores it in JSON format. Different protocols have different JSON formats. Encrypt is 0, indicating that the Data is unencrypted, so the plaintext data can be seen on the chain, which means it is open to anyone to view on the chain.

Among them, Data stores the content of the user’s name/nickname, and stores it in text form. Different NodeNames have different functions. For example, email stores user email data, and avatar stores user avatar data. Encrypt is 0, indicating that the Data is unencrypted, and the default email and phone nodes are encrypted, that is, the ciphertext data seen on the chain.

Summary

MetaID currently supports multiple UTXO structure blockchains such as MVC, BSV, BCH, and Doge. Here is a brief introduction of MVC as an example. MVC has a built-in native distributed ID protocol “MetaID”, which is the first Layer-1 distributed ID solution implemented on the UTXO public chain. The distributed ID solution is an important basic protocol for Web3 applications. Only through the distributed ID protocol can the complexity and threshold of developing Web3 applications on MVC be greatly reduced, making it possible for Web3 applications to explode on a large scale. Based on MetaID, we can build a Web3 world that carries a large number of users where data is owned by users and applications are interconnected.

Author: Kyle