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:

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:

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

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

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

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: