MetaID Technical Explanation
MetaID PROTOCOL FORMAT
The overall protocol format of MetaID is:
Among them, the first three parts are the node positioning part of MetaID, and the last seven parts are the node information part of MetaID. MetaID is created by the OP_0 OP_RETURN operation code in the transaction output of the UTXO model.
NODE POSITIONING PART
Locate part of the information for the MetaID:
< chainFlag > marks the information for the chain it belongs to. MetaID V1.1 can support mainstream UTXO model public chains, and temporarily supports MVC, BSV, BCH, DOGE, where "MVC" stands for MetaverseChain public chain, "BSV" stands for Bitcoin SV public chain, and "BCH" stands for Bitcoin Cash public chain , "DOGE" stands for DogeCoin public chain;；
< P(node) > is the public key of the node;
< parentChainFlag:TxID(parent) > is the transaction ID of the parent node, and "parentChainFlag" is the flag information of the chain where the parent node is located. MetaID V1.1 version can support mainstream UTXO model public chains, and temporarily supports MVC, BSV, BCH, DOGE, where "MVC" stands for MetaverseChain, "BSV" stands for Bitcoin SV public chain, "BCH" stands for Bitcoin Cash public chain, " DOGE" stands for the DogeCoin public chain; parentChainFlag is allowed to be empty or missing, if parentChainFlag is empty or missing, the "chainFlag" of the first part is taken, then the parent node and the current node are considered to be in the same chain.
MetaID NODE INFORMATION SECTION
The latter seven parts, namely:
The specific meanings are as follows:
| Key | Value |
|---|---|
metaidFlag | Fixed to ”metaid” |
nodeName | Node ID name |
data | Data content corresponding to the storage node |
encry | Indicates whether the content of this node is encrypted. This version of the protocol supports two methods: 0 means no encryption; 1 means ECIES encryption, that is, the encryption key is the public key of the corresponding node, and the private key of the corresponding node path is used for decryption. The default is 0 for no encryption. |
version | The version number of the node type. Different version numbers mean that the format of the data content is different. |
dataType | Optional items. The data type corresponding to data. For available data types, please refer here. The default is text/plain. |
encoding | Optional items. The encoding format corresponding to data, please refer here for available encoding types. The default is UTF-8. |
MetaID STRUCTURE
In this version of the protocol, there are only two child nodes under the root node of MetaID, namely "Info" and "Protocols".
Users only need a private key to use all applications that support MetaID.
User basic information and application transaction data are recorded on the nodes controlled by themselves, so that user data has nothing to do with wallets and applications, breaking the traditional data monopoly.
The nodes that MetaID must have are Root, Info and Protocols. This three-node agreement cannot change the name and does not accept version update operations.
We agree that MetaID is the TransactionID of the Root node.
ROOT NODE
The Root node is the vertex of MetaID. When constructing a MetaID transaction, TxID parent is empty and it is the vertex.
Since it is a vertex node, TxIDparent needs to be NULL. Then set the Root node name to Root, and the subsequent parts are not needed, so just set them be NULL.
The public key generation agreement of the MetaID-related P node node is generated using the HD scheme [2], and the Root node address agreement uses the HD scheme 0/0 path.
When constructing a Root node, the nodeName is fixed as "Root". The following is an example of building vertices:
INFO NODE
The Info node is a node that stores basic user information, and the nodeName is fixed as "Info".
The structure of the Info node is similar to Root, except that TxIDparent needs to point to the Root node and nodeName is set to "Info." The following is an example of building an Info node:
ABOUT BASIC USER INFORMATION
In this version of the protocol, the basic user information is placed under the Info node. The Info node contains the following 5 sub-nodes:
[Name] Username, it is recommended not to encrypt. The format is fixed as text/plain
[Avatar] user image, it is recommended not to encrypt. The format is binary, and the data part stores the binary stream of the picture
[email] User email, it is recommended not to encrypt. The format is fixed as text/plain
[Phone] User's mobile phone number, it is recommended to encrypt the data. The format is fixed as text/plain
[Bio] User profile, it is recommended not to encrypt. The format is fixed as text/plain
The structure diagram is as follows:
The contents of the five nodes above are applicable and can be set according to the needs. It is acceptable for the node not to be created or for the node content to be empty. However, it is recommended that when a new MetaID user is created in a general application, at least the name node should be set to determine the user name.
The following is an example of building a "name" node, we want to set the user's name to "Alice." Just build a MetaID transaction, point its parent node to the Info node, set nodeName to "name", and data to "Alice", as follows:
Avatar nodes store user avatar information, and the data format is fixed as binary. The construction can refer to the following:
Other nodes can be constructed in a similar manner. It should be noted that if some information such as phone node information wants to be encrypted, just set encrypt to 1, and then use the ECIES method to encrypt the relevant characters with the public key, so that the encrypted information can only be used by the user himself. Only the private key can be decrypted.
PROTOCOLS NODE
The Protocols node is to record the transactions of users using various third-party protocols. The child nodes under the Protocols node are third-party protocol nodes, and their nodeName should be the protocol name. The sub-nodes under the protocol node are the specific transactions generated by the user using the protocol. The structure is as follows:
Since the protocols of Protocols are open, all application parties can build their own protocols. Therefore, the number of sub-nodes under Protocols is unlimited, and the structure under each protocol is determined by the protocol maker/application side. However, it is necessary to ensure that the identification of the protocol node is unique.
MetaID PRIVACY MODEL
The privacy model of the protocol is formulated by the protocol maker/application side. If the user does not want their data to be disclosed, it can be handled as follows:
Set the node's encrypt to 1. This data can only be viewed by the user himself.
The data encryption method of this protocol adopts the way of ECDH negotiation password to deal with. The data can only be viewed by the user and the application, and the user can also authorize or entrust the application to authorize third parties to access.
Since MetaID is an open source and open protocol, all application parties organized through MetaID can join without permission. Although the data can be encrypted, the organizational relationship of the data is transparent. Some users do not want the information attached to the data relationship to be exposed. Correspondingly, we A schema for anonymous nodes is devised.
The protocol can point to another data set through one bridge node, and this data set can be another MetaID, or data from another organization. In this way, users can selectively use anonymous nodes and MetaID protocol nodes.
Last updated
