As an analogical example, we could think of a Twetch post, which utilizes three protocols: B, AIP (Author Identity Protocol), and MAP (Magic Attribute Protocol). Using the analogy, we can think of this as:

class TwetchPost: B, AIP, MAP {

...

}

And once you instantiate the class into an object, you can create associations with them.

For example continuing on with the analogy, most apps have multiple views. So normally you create a view controller and create transitions between them. In the following example, we have two view instances, both of which implement the “UIViewController” and “UITableViewDataSource” in order to present a scrolling view.

We can think of Metanet as doing the same thing as creating a transition between view controllers. Just like we have created an app by instantiating two views and creating a meaningful link between the two, we can instantiate a data object using BitCom, and connect them using Metanet.

I hope this section helped you think about why it is powerful to have modular protocols instead of custom rolling your own protocol data schema. But there are more benefits I haven’t mentioned here, such as interoperability, etc. Think about it.

c. BitCom + Metanet

The chunked bytecode structure of MOM also gives developers the power to treat Metanet as an extension protocol. Basically you can treat Metanet as a higher layer protocol that sits on top of one or more BitCom protocols.

This layered architecture means:

You don’t have to build everything as a Metanet protocol from the beginning. You can build the BitCom stack first, and then later easily transition to BitCom + Metanet, simply by attaching Metanet to the existing protocol you designed (or even reusing 3rd party protocols), without having to worry about how that will change the way you’ll have to deal with data. If you already have a BitCom protocol, you can easily Meta-fy it.

To use an analogy, this is similar to how the Ruby on Rails community is using Devise gem as de facto standard for authentication because it makes it easy to plug-and-play. Often, rails developers start by building a single player auth-less CRUD app to get their proof of concept working. Then later on they add the devise gem to add authentication. This way developers can quickly prototype their core logic first to build a single user app, and then later turn it into a multi-user app by adding the devise gem.

Metanet is similar. Some apps will work fine without implementing Metanet. And some apps will benefit tremendously by implementing Metanet, especially those that have to do with authentication, authorization, or creating sophisticated data structures. In these cases you can start small with your data schema protocol first (or use existing protocols), and then later add Metanet.

For example, you could start by building pure BitCom apps and use BOB to parse them (similar to how you build a simple single-user CRUD app with core logic first). This should be enough for a lot of apps that don’t need complex data structure.

But if you want to add Metanet, the door is always open. You can easily transition to MOM. Nothing in terms of the bytecode queries will change since BOB and MOM share the same bytecode schema, MOM simply adds a data structure layer on top of BOB, enabling you to run graph queries as well.

You can even maintain both the raw BitCom app and the Meta-fied BitCom version simultaneously, using BOB for the former, and MOM for the latter.

d. OP_RETURN Backwards Compatibility

In 2020, all the protocol limits will be lifted on Bitcoin. While this will make Bitcoin extremely powerful, it also means developers need to be more careful about certain things. Because with great power comes great responsibility.

One such example is how the OP_RETURN opcode will “return” to its original role of acting as a return statement instead of simply being used as a data embedding hack. However, this feature means you need to take more care in how you use the OP_RETURN now. The Bitcoin SV node team recommends that you simply transition to using OP_0 OP_RETURN instead of OP_RETURN. Learn more:

Some people thought this meant a lot of headaches because this small change shifts the positional index of each push data by one, and breaks the fundamental model of which all public Planaria APIs are built on top.

But there’s always a solution to everything.

With BOB and MOM, the transition to OP_0 OP_RETURN in 2020 is a non-issue. Because it chunks all push data into groups, you can filter both the legacy OP_RETURN transactions as well as the new OP_0 OP_RETURN transactions with a single query. This article explains how this works:

e. Future proof (OP_PUSHDATA/OP_DROP and more)

If you read through the Metanet protocol spec, you may notice some advanced use cases where it supports multiple outputs, and even an OP_PUSHDATA + OP_DROP option.

The OP_PUSHDATA4 which will get re-enabled in 2020 will let you embed up to 4GB~ of data in a single transaction.

This is exciting, but just like the OP_RETURN to OP_0 OP_RETURN transition issue, without BOB/MOM, supporting these various other options would have been a great headache because developers would have had to worry about how to query all these different combinations in as simple way as possible.

Fortunately, this will also be simple too with BOB/MOM combo, because the schema ensures that the code is chunked up into call stack groups (tape/cell), each group with its own local scope of push data index as well as global index.

5. Conclusion

With the combination of BitCom and Metanet, developers have all the tools to build their own protocol operating systems.

MOM — through its simple graph data structure and its OP_RETURN bytecode data schema — makes it easy for developers to build sophisticated Metanet applications.