MOM

Metanet Object Model

Today I’m releasing MOM, a powerful new Planaria node for Metanet. MOM can be characterized as:

Metanet * BitCOM = MOM

Try here: https://mom.planaria.network

1. What is MOM?

2. Metanet, meet BitCom.

3. How does MOM work?

4. What does this all mean?

5. Conclusion

1. What is MOM?

We already have a Metanet Planaria endpoint. So how is MOM different?

To understand MOM, we need to first understand the problems it solves. Let’s take a look at an excerpt from the Metanet protocol spec:

The specification was probably written a while ago, so it doesn’t take into account all the madness (in a good way) that’s going on in Bitcoin today. To be specific, the spec includes only the “single subprotocol identifier” examples.

It probably didn’t expect that many people would start using a mashup of multiple protocols within a single transaction output:

Bitcom Unix Pipeline · Issue #2 · unwriter/Bitcom

And somehow, this pipeline based protocol mashup *has* become a thing. Many apps you hear about nowadays use a mashup of multiple protocols via protocol pipelining. It is really cool that this scheme has gained traction in such an organic way.

However, the problem was, this made it difficult to use the existing Planaria nodes like Genesis, Babel, etc. to query the data structure, because the protocol push data positional indexes are not fixed anymore. Some protocols have optional parameters (like B://), and some protocols have variable length specification (like MAP). And when you combine these, it becomes impossible to determine which push data should appear at which positional index within a transaction output.

This was an important problem for all Planaria endpoints, so I had to quickly come up with a solution called BOB (Bitcoin OP_RETURN Bytecode) which chunks transaction scripts into call stack chunks called “tapes” and “cells”. each with its own local scope as well as local positional index for the push data set:

Go read the BOB article if you haven’t yet:

Hello, BOB.

Now that you’ve understood why this is an important problem, you may realize why this problem becomes even more serious when we bring Metanet into the equation. Let’s look at the Metanet spec again.

As you can see, the Metanet protocol itself is very flexible too. There are 2 mandatory fields (Metanet Flag and Pnode), and you use the third field (TxIDparent) to create edges between nodes. And then there are even more optional parameters you can add. Really, the rest is left up to the developers, because Metanet is supposed to only handle data structures.

So if we combine this flexibility of Metanet and the flexibility of the BitCom pipeline scheme which has become prevalent, we end up with an explosion of flexibility. This sounds really cool but for me it was madness because I had to come up with a scheme to contain all these flexible combinations.

And I solved it with BOB (for non-metanet protocols). And now with MOM (for metanet protocols).

https://mom.planaria.network

MOM uses the same data serialization format as BOB, making it easy to deal with complex BitCom protocols

Also MOM implements the graph data structure provided by the Metanet protocol, making it easy to query the Metanet graph.

2. Metanet, meet BitCom.

With MOM it becomes easy to merge Metanet and Bitcom. This means you can:

1. Use existing Bitcom protocols within a Metanet node
2. Use multiple Bitcom protocols within a Metanet node, via BitCom pipeline.

There is one thing to remember:

Because MOM chunks the bytecode using the pipe symbol | — you need to remember to add the pipe symbol as a delimiter between the Metanet part and the Bitcom part as well. See below example:

Once you do this for your transactions, MOM automatically indexes your Metanet transactions using BitCom scheme!

3. How does MOM work?

MOM is a combination of the two:

1. Data Structure: Metanet Planaria
2. Data Schema: BOB Planaria

BOB + Metanet = MOM

This means MOM simultaneously supports the BOB’s OP_RETURN byte code queries, as well as Metanet graph queries. So, to learn how MOM works you just need to learn BOB and Metanet queries.

a. BOB

MOM’s data is indexed in the same way as BOB Planaria, which makes it easy to query the OP_RETURN bytecode. Learn more about BOB Planaria here:

Hello, BOB.

b. Metanet

MOM also indexes the Metanet data structure, in the same way the existing Metanet Planaria endpiont works. Learn more about Metanet Planaria here:

Part 1:

The Metanet Starts

Part 2:

Creating Time and Space on Bitcoin

Also here’s a really great article which goes into details about the graph structure of Metanet:

Edge Cases: The Metanet Blog

4. What does this all mean?

This match between Metanet and BitCom means an explosion of protocol combinations. BitCom was already growing like weed. When you multiply that with the flexibility of the Metanet protocol, we end up with all kinds of possibilities.

a. Plug and Play Modules

Up till now, I think most Metanet protocol developers have created their own custom protocol schema when implementing Metanet. But if we remember:

1. BitCom is data schema: BitCom lets you describe rules used to interpret a transaction. BitCom is for describing a node.
2. Metanet is data structure: Metanet lets you create data structures between transactions. Metanet is for describing an edge.

So if you’re coming up with your own custom schema for the purpose of implementing a Metanet graph, you are basically bundling the two features into one.

Sometimes this may be useful, but often you may want to simply “plug in” other generic protocols with proven track record. This way you don’t have to invest too much in schema design and reuse existing modules.

b. Multi-inheritance

In above tree diagram, you can see that each node can have one or more BitCom protocols. This is really powerful because now BitCom can work like modules you inherit from.

This is similar to a programming concept known as….guess what….“protocols”!

For example, when you build an iOS application, you implement a scrolling table view by implementing two modules: “UIViewController” and “UITableViewDataSource”. When you implement the callback methods required by the protocols, the app will start acting like a scrolling table view.

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:

1. 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.
2. 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:

The return of OP_RETURN - roadmap to Genesis part 4 - BitcoinSV

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:

Hello, BOB.

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.

Try MOM: https://mom.planaria.network

Ask questions and report bugs: https://bitdb.network/atlantis

Stay updated: https://twitter.com/_unwriter