Protocols 节点

Protocols节点为记录用户使用各种第三方协议的交易情况。Protocols节点下的子路径为第三方协议路径，其应为协议名称。协议路径下为用户使用该协议所产生的具体交易。结构如下

由于Protocols的协议是开放的，所有应用方都可以构建自己的协议。每个协议下的结构由协议制定方/应用方自己决定，但需保证协议节点的标识具有唯一性。

关于协议名字的约定

构建一个新协议节点时，/protocols之后的子路径其为协议名称， /protocols/{sub-protocol}。协议名称没有限制，应用方可根据自己的需要，构成一个方便阅读和理解的协议名称。协议名可以重名，应用方可以根据其格式来获取所对应的内容

关于协议的结构和约定

每个协议的结构由协议制定方/应用方约定，每个协议下可以是扁平的一层结构，也可以是复杂的多层结构。如果业务允许的话，该协议的的结构和详细说明，协议制定方应公开出来，以便其他应用方/数据服务方可以调用和解析。

需注意的是，这些节点的结构虽然为协议制定方/应用方决定，但相关的节点创建还是由用户创建，为用户所掌握，用户只记录和自己相关的协议数据。

协议交易节点

每个子协议下的PIN均为用户使用该协议下的产生的具体交易，每条具体的交易称为协议交易节点。

payload 为协议数据的存储处。协议数据由应用方根据约定的协议自行解析。

content-type 为数据类型和编码方式。应用方需根据content-type来读取payload数据。

协议交易节点的子路径名称需为域树中同一层级内是唯一的，以方便以后用URI方式查找。例如可以采用publickey作为子级路径名称，也可以自行设定，只需确定与publickey映射关系即可。

假设某一MetaID交易是属于SampleBuzz协议的，其数据格式采用Json，数据内容如下：

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

那么，该MetaID交易的构建参考如下：

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

或者

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

需注意的是，协议交易节点中的version值代表了其所遵循的协议版本，不同版本号代表其payload内容有可能不一样。数据解析时，需根据不同的version做不同的解析。上面例子中，生成的MetaID树结构参考如下：