Domain Structure

It is a simple extension of the ideas we have just discussed to see how hierarchical domain-like structure naturally emerges by simple application of the Metanet-protocol rules.

Consider a simple binary hierarchy as shown in the three ordered figures below. From what we have just established, we know that there is a clear permissioning hierarchy that defines the write-access for the tree. We can follow the flow of permissions through the tree in the following steps:

Only the owner of P(0) can create children of the root node:

2. Only the owner of P(1) can create children of the left child node:

3. Only the owner of P(2) can create children of the right child node:

We can see that, for any given node in the tree defined by two data elements (P(node), TxID(node)), the permission to create a child of the same node lies solely with whoever (or whatever) has the ability to sign using the key pair associated with P(node).

Herein lies the key innovation of the Metanet protocol. That the ability to create a Metanet-valid child of a node rests with the burden of being able to produce a signature on that child is precisely how the Metanet protocol achieves its permissioning hierarchy and, indeed, domain structure.

In fact, for those familiar with the architecture of the Domain Name System (DNS), and in particular the DNSSEC, the permissions flow that I have described as dependent on the ability to sign over a child may be starting to sound familiar. Indeed, there is a strong analogy to be made between the permissioning hierarchy of the Metanet protocol and the chain-of-trust model used in the infrastructure of the DNSSEC.

In this model, domains are effectively secured by a sequence of certificate authorities (CAs) successively signing over one another to create a hierarchy until an end-point certificate is reached. It is no great leap, then, to see how we can begin to map and implement domain structure within the Metanet protocol.

Domains

Now that we have a good understanding of the hierarchical graph structures that can be created with the Metanet protocol, and we know how such structures look in terms of transactions and signatures, we can demonstrate mapping a domain structure to them.

The reason I said that there was an analogy between the DNSSEC and Metanet graphs is that I wanted to make clear the point about a chain-of-trust model, which is common to both. The precise function of the DNSSEC, and CAs in general, may differ from what can be done in a given Metanet tree — although the concept of actually implementing such CAs on-chain is something worth its own discussion, one which my other colleagues at nChain may be best suited to facilitate properly.

But, the key point to take away from today’s post is that the fact that a chain-of-trust model exists as part of the Metanet protocol allows for the representation of structures akin to websites and other online domain types.

Consider the simplest example, whereby we want to implement a fully-fledged on-chain website using only blockchain transactions that follow the Metanet protocol. Using our discussion from the previous section, doing so can be as simple as representing the entire website in a hierarchical fashion as a Metanet tree, and treating the root node of the tree like a top-level domain (such as ‘.org’).

By treating the root node as our top-level domain, we can further define sub-domains by simply treating children (and grand-children etc.) as subsequent sub-domains (such as .wikipedia or .nchain) as shown in the diagram below:

Based on our understanding now, we can say that the domain, as defined by a node, corresponding to ID(node) is the set of all descendant nodes for which the node is an ancestor. In other words, we introduce the following definition for a domain in the Metanet protocol:

A domain defined by ID(node) is the set of descendants of ID(node).

We see immediately that this definition of a domain in the Metanet protocol not only defines a domain according to a particular node in the graph, but because we defined ID(node) to be dependent on P(node) earlier, it also encodes the permission to make changes (i.e. write access) to the domain.

The diagram below shows how the paradigm of defining a domain as the set of all descendants of a particular node effectively means that each sub-tree in a Metanet structure can be used to define a new sub-domain.

To put it more formally:

A sub-tree in a Metanet structure defines a sub-domain.

Now that we have a clear understanding of how rich domain-like structure can be realised by simple application of the Metanet-protocol rules, we need to ask ourselves a significant question: what about identity?

Anchoring to Identities

It should be clear at this point in today’s post, and particularly if you’ve been reading the rest of the series, that:

The Metanet protocol does not solve ‘the identity problem.’

The problem we are referring to here is of course that of being able to safely, securely and robustly manage and utilise our identity in the context of digital activity, e-commerce and social interactions online. As I’ve mentioned on many occasions, the Metanet protocol’s primary function is to allow structure and permissioning for on-chain data and utility. As such, the Metanet protocol should be a beneficiary of any such solution that addresses the identity problem to a satisfactory degree.

In the technical summary of the Metanet protocol, we made this clear by assuming that a robust mapping exists between real-world identities and their Metanet-protocol counterparts. In reality, such counterparts are the nodes of Metanet structures themselves — in particular root nodes. For example, consider a root node representing an on-chain blog written by Bob that is defined using the Metanet protocol by:

ID(root) = ID(bobsblog)=H(P(bobsblog)||TxID(bobsblog))

In the technical summary, we made the assumption that a reliable and robust mapping exists between Bob’s real-world identity ‘bobsblog’ and the root-node ID of his on-chain blogging website. Such a map would functionally look like the following:

Mapping from real-world identity ‘bobsblog’ to a node ID.

It is clear, then, that the Metanet protocol is not a catch-all solution for every aspect of achieving the goals and vision of the Metanet as a fully-fledged, blockchain-based value network. Instead, the Metanet protocol has been designed to make the best use of such a solution to on-chain identity management. In other words, once a suitable map between real-world identities and on-chain data exists — an identity management system — the Metanet protocol allows creators and users to apply such a system to their Metanet graph structures.

Anchoring an identity to a Metanet root node.

The diagram above illustrates the simplest and most straightforward example of how the Metanet protocol can utilise such a solution for identity handling and management. We have simply anchored a root node to the real-world identity. It is a simple yet powerful example of how the Metanet protocol can be combined with such a solution to implement websites, document management, and much, much more on the Metanet.

The Metanet protocol + identity management = ownership of data.

The above statement may seem like a bold one, and of course there are implementation details that it inevitably simplifies, but we can see that the combination of structured on-chain data and proper identity management is one of the fundamental pillars required to realise the aims of users reclaiming sovereignty over their online data.

The good news is, there is already significant proof of work that is going into finding the best solution for handling on-chain identity.

We have seen a number of projects and developments working hard to see the same goal realised, including:

LegallyChained;

Paymail;

protocols such as AIP, BAP, MAP, etc.; and

whatever magic may emerge from CambrianSV!

The use of the Metanet protocol is far from contingent upon such a solution to identity management. But, we can see that some of its true power will be realised once we can safely consider the issue resolved — watch this space.

Naming & Locating

Once we have established our domain-like on-chain structures, and been able to map real-world identity to them, we can begin playing around with the meaning we ascribe to each node in a graph.

In the simplest example, we can begin to assign ‘names’ to our Metanet nodes, which may in practice be in the form of a flag, raw text, or some other format — depending upon the particular use case. More generally, by ‘name’ we simply mean an element(s) that tells us something interesting about the node. We could call it ‘metadata,’ but that might get confusing to read and write about very quickly for obvious reasons…

We instead call such elements ‘attributes,’ which are additions to the fundamental four elements that we stipulated a Metanet node must always have and which we detailed in the last post.

A hypothetical MURL (MetanetURL) indicating a particular node.

The diagram above shows a node now identified by a MetanetURL (MURL), which is simply a conceptual model for some resource locator to find Metanet nodes.

I would stress here that the idea of a MURL is a conceptual one. It allows us to consider how the process of traversing a Metanet graph is closely related to the way in which Uniform Resource Locators (URLs) are used to traverse content resources in the existing web.

The diagram below shows our conceptual definition and model for a MURL, the Metanet analogue of a URL:

The conceptual model for a MURL.

We see that, like a standard URL, it is largely made up of four main components:

Protocol identifier — a way of specifying which protocol we are using to resolve the MURL.

— a way of specifying which protocol we are using to resolve the MURL. Domain — a domain, which has been (or can be) mapped to a real-world identity.

— a domain, which has been (or can be) mapped to a real-world identity. Path — a path through different nodes in the graph, expressed by an ‘attribute’ of each node.

— a path through different nodes in the graph, expressed by an ‘attribute’ of each node. Name — the ‘attribute’ of the target node.

What I have just outlined will make much more sense (as always) when shown visually, as we see how such a MURL demonstrates a process of graph traversal for Metanet structures:

A MURL shown as a graph traversal.

In this diagram, the target node is named ‘tennis’ using an attribute. The path to the target has been expressed in terms of the attributes of the nodes that lead to the target, and the domain has been defined by mapping the real-world identity (or domain space) to the unique identifier ID(node) of the root node.

So really, a MURL as described here can be viewed either in its abstracted form — as it should appear to a user in a browser — or in its lower-level form, where we understand what each part of the MURL refers to in terms of Metanet graph components.

Abstracted: mnp://bobsblog/sport/tennis Low-level: mnp://ID(node)/attribute(path)/attribute(target)

The key concept to take away from here is that we can construct resource locators for the Metanet that allow us to leverage the intrinsically efficient searchability of traversing DAG structures.

We have already seen novel approaches to URLs implemented to find content by TxID reference (B:// protocol) and by content hash (C:// protocol). It is an extension of such paradigms — the desire to find on-chain content using new URL types — that we would aim to encode a graph traversal in such a blockchain-oriented URL schema.

I have been involved in a number of conversations along these lines already, and I hope that in the near future we will start to see implementations of resource locators for blockchain data that do so. Schemes that are able to leverage the ability to traverse Metanet graphs (in addition to identity management) in order to unlock the potential of the Metanet protocol for on-chain content.

Mapping Keys to Domain Structures

As a final thought for today’s post, I want to draw your attention to the utility of domain structures in the Metanet protocol for implementing complex functionality involving hierarchical key management.

In a Metanet tree, each node (excluding multiple versions of the same node) is assigned its own key pair, denoted by P(node). As we have already detailed, the key pair associated with P(node) defines the write-access to create a subsequent child of the node.

It follows, then, that we can aim to map entire hierarchical key structures, such as those used in hierarchical deterministic (HD) wallets, to to Metanet trees. We can picture something like the following: