# Protocols Node

The Protocols node records the transactions of users using various third-party protocols. The sub-paths under the Protocols node represent the paths of third-party protocols, named after the protocols. Under these protocol paths are the specific transactions generated by users using those protocols. The structure is as follows:

<figure><img src="/files/hQrZE7wDpWhDwi32gPK6" alt=""><figcaption></figcaption></figure>

Since the protocols for Protocols are open, all application developers can construct their own protocols. The structure under each protocol is determined by the protocol creators or application developers but must ensure the uniqueness of the protocol node identifier.

#### **Protocol Naming Conventions**

When constructing a new protocol node, the sub-path after `/protocols` is the protocol name, `/protocols/{sub-protocol}`. There are no restrictions on protocol names, and application developers can create protocol names that are easy to read and understand according to their needs. Protocol names can be duplicated, and application developers can use their format to obtain the corresponding content.

#### **Structure and Conventions of Protocols**

The structure of each protocol is determined by the protocol creators or application developers. Each protocol can have a flat single-layer structure or a complex multi-layer structure. If the business allows, the structure and detailed description of the protocol should be made public by the protocol creators to facilitate calls and parsing by other application developers or data service providers.

It should be noted that although the structure of these nodes is decided by the protocol creators or application developers, the creation of the related nodes is done by the users and controlled by the users, who only record protocol data related to themselves.

#### **Protocol Transaction Nodes**

Each PIN under a sub-protocol represents a specific transaction generated by users using that protocol, referred to as protocol transaction nodes.

* `payload`: Storage for protocol data. The protocol data is parsed by the application developers according to the agreed protocol.
* `content-type`: Data type and encoding method. The application developers need to read the `payload` data according to the `content-type`.

The sub-path name of the protocol transaction nodes must be unique at the same hierarchical level in the domain tree to facilitate future URI-based searches. For example, the public key can be used as the sub-path name, or it can be set independently, provided it ensures a mapping relationship with the public key.

Assuming a MetaID transaction belongs to the SampleBuzz protocol, with the data format in JSON and the data content as follows:

```json
{"content": "This is a test","title": "Test-Title"}
```

The construction of this MetaID transaction can be referenced as follows:

```c
OP_FALSE
OP_IF
	metaid                         
	create                         
	/protocols/simplebuzz        
	0                              
	0                               
	application/json;utf-8         
	{"content":"This is a test","title":"Test-Title"} 
OP_ENDIF
```

or

```c
OP_0
OP_RETURN
	metaid                          
	create                        
	/protocols/simplebuzz       
	0                               
	0                            
	application/json;utf-8        
	{"content":"This is a test","title":"Test-Title"} 
```

It should be noted that the `version` value in the protocol transaction node represents the protocol version it follows. Different version numbers may indicate different `payload` contents. During data parsing, different `version` values require different parsing methods. The generated MetaID tree structure for the above example is as follows:

<figure><img src="/files/nYZZDvhQ4xmzwsICl20O" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.metaid.io/metaid-specification/metaid-tree/protocols-node.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.