Po.et has a very basic goal: use cryptographically signed messages about a hash that have been secured to a public blockchain as the basis for building a new web. In this article, we’re going to give some clarity to the architectural decisions that make Po.et unique and explain how everything fits together.

The bulk of the Po.et Protocol defines a metadata schema along with methods for storing, retrieving and verifying metadata and its related data. Anyone who chooses to implement the protocol is able to generate claims (metadata) about any digital content (data) and store the claims and content in a highly distributed and immutable fashion.

Our engineering team has leveraged a number of decentralized technologies like Bitcoin, IPFS and JSON-LD, as well as creating some unique solutions with these technologies, to deliver a robust implementation of the Po.et protocol.

The basic description of how Po.et technically works

Decentralization

Since the commercialization of the web in the early 1990s, we’ve watched a network that was built for equality and equitability slowly start to consolidate in a way that has given rise to overwhelming influence by a small handful of organizations. For Po.et to reach its full potential, we must reverse the trend towards centralized systems by systematically creating new opportunities that reinforce the positive effects of decentralization. For this iteration of the protocol, we’re leveraging existing decentralized technologies wherever we can. Specifically, we’ve chosen to use Bitcoin network and IPFS protocol as the backbone for Po.et.

For our anchoring layer of Po.et, we’ve chosen to use the Bitcoin blockchain (BTC). The Bitcoin blockchain is already a widely decentralized network, running on thousands of computers around the world. Aside from Bitcoin’s primary use case as a payment network, it also can serve as a robust distributed database. Data written into the blockchain can be considered to be secure within an hour of being recorded in a block. Bitcoin has survived many large-scale attacks, and changing the information stored on blocks that are even just days old can be incredibly computationally expensive. We use Bitcoin as our main source of information security and coordination between nodes.

IPFS defines itself as a peer-to-peer hypermedia protocol to make the web faster, safer and more open. For Po.et, IPFS is a perfect fit because it satisfies three requirements: content addressability, file immutability and extreme durability. Content addressability enables us to refer to any piece of data by name as opposed to location. IPFS’s addressing system is based on a hash of the content which creates a unique address for every piece of content on the Po.et Network, including the claims. If a file is changed, the address will change, too. As for durability, as long as one IPFS server decides that it is willing to expend resources to keep a particular piece of data online, then the entire network has access to that data. By leveraging this decentralized storage model, users of the Po.et Network distribute their content and claims across a wide range of IPFS network participants, making the complete removal of those claims extremely difficult as long as the content is worth storing.

The Po.et core team is bootstrapping this process with a cloud-based IPFS infrastructure of its own, but we welcome all Po.et protocol implementers to provide IPFS storage as well to make the overall network more distributed and robust. For all data coming through our hosted API endpoint and applications, we are ensuring all of that information is pinned to our IPFS infrastructure and we are planning to support that infrastructure for a long time.

The Po.et team strongly suggests that you do not attempt to put personally identifiable information on Po.et. Because of the decentralized nature of the technologies used, you will not have any control over information that you want to keep secret. There is no way for the Po.et team to remove data from servers that we do not control. Cryptography has come a long way, but the entire industry is still working out kinks in managing sensitive information.

Node Architecture

In a previous post, we explained from a high level the architecture of the Po.et Node, including its main responsibilities:

Publish content and creative work claims to IPFS

Anchor claims to the Bitcoin blockchain via a claim-batching transaction

Ingest claim-batching transactions from the blockchain to build a database of claims

Surface all of these functions via a simple API for integration with other services

These responsibilities are carried out by several modules inside the node that serve various purposes during the registration of a claim in IPFS and on the blockchain. The work of the modules is orchestrated through a message queueing system (RabbitMQ), and an overview of intermodule communication is provided in the node’s GitHub repo.

The node receives verifiable claims through its API. Any well-formed claim will be accepted by the node and put into the next claim batch.

For example, when creating a new work claim, the claim and content are both stored in IPFS, which generates IPFS separate file hashes for each respective piece of information. A number of these IPFS file hashes are batched together and stored in a single IPFS directory, which also is identified by a unique hash. The IPFS directory hash identifies this claim batch and is anchored in the Bitcoin blockchain.

The node then monitors the Bitcoin network and looks for the transaction’s appearance in an upcoming block in the blockchain. Once it identifies the transaction in a newly formed block, the node records the details such as the block number (blockHeight) and the hash (blockHash) of the block. This information irrefutably links the claim batch to that block, thus “anchoring” all of those claims to that block in the blockchain and establishing the time period in which those claims were made. Also, each block has an associated timestamp which is accurate “to within an hour or two”, and thus proves that any anchored hash in that block existed around that time.

In order to track the state of a claim from its receipt up until its enshrinement in the blockchain, the node uses MongoDB to record each claim, a sample of which is shown here:

Storing and indexing claims in a local database enables every node to have quick and reliable searching and retrieval. Also, it sets the stage for “claims about claims” to be created in the future, where a number of separate claims can be made about a single claim (e.g., reviews about a book). Nodes can eventually be programmed to store specific types of “base claims” (i.e., a creative work claim for a book) along with any claims made about them (license claims, reviews, etc.).

Anyone can run a node and participate in the Po.et Network and we strongly encourage it in order to build a more decentralized network. The Po.et Node software is open source and the code is freely available for review and use (code contributions are also welcome 👍🎉).

Claim Batching

The Po.et Network is a system of claims that get anchored to the Bitcoin blockchain. Each claim has been cryptographically signed in a way that we can independently prove the authenticity of the information coming from a specific entity.

An issuer creates and signs a claim, which gets hashed — a hash is like a unique fingerprint for a piece of content — and placed into a batch by a Po.et Node (see Node Architecture above). That batch itself is hashed and submitted to the Bitcoin blockchain. When the batch is confirmed (which could take some time — Bitcoin mines a new block about once every 10 minutes), other Po.et Nodes detect the new batch hash, locate the batch and may verify the claims it contains.

Po.et’s protocol specifies that a claim batch is a connected tree of cryptographic claim hashes. The root of that tree is the Merkle root — a hash of all hashes in the batch. With the Merkle tree, all we need to record on the Bitcoin blockchain is the Merkle root hash. That anchors the whole tree because it proves that everything that was in the batch existed prior to mining the root hash transaction. There is no limit to the number of claims we can batch into a single anchor transaction.

Claim batching will take advantage of the immutability of the blockchain without being constrained by transaction frequency limitations (i.e., Bitcoin’s current scalability limit of no more than seven transactions per second, which puts a hard cap of daily transactions at roughly half a million per day). Batching any large volume of claims into a single reference is the key to that. By batching transactions and anchoring to the Bitcoin blockchain, the Po.et Network can potentially handle billions of transactions per day.

Protocol Updates

To make data in the Po.et protocol meaningful, we need consistent ways to describe that data so that its meaning and use can be interpreted by software. This is the purpose of metadata, as it is described in the Semantic Web or Web 3.0.

We are using JSON-LD to describe metadata for verifiable claims. Linked data is the method that makes data meaningful in the Po.et protocol. Combined with linked data signatures, which leverage well-known cryptographic practices like private key management, we can create verifiable proof about claims we have written to the Po.et Network.

Following up on what we explained in our September blog post:

“Po.et is a system of verifiable claims, which are JSON-LD documents that make a claim about a subject. The subjects and creators of claims each have their own digital identity in the Po.et ecosystem. Those identities are just hashes themselves. …When you hash a creative work with Po.et, you’re creating its digital identity: the fingerprint that other claims about that work will refer to.”

At this time, we have only one type of claim: a creative work claim. The attributes of the claim are fairly basic. We’re going to be expanding the work claim type to ensure that it can fit a variety of use cases. If you dig into an example claim, you’ll see that we’re using existing attribute names from schema.org and Dublin Core Metadata Initiative. We intend to continue to leverage the existing work done towards building the Semantic Web where possible.

Once the creative work has been established, we can start to record additional context for claims, including claims about claims. This linking of data is the foundation of the protocol and we hope will be a significant feature that drives the widespread adoption of Po.et.

We will also be expanding into completely new claim types. In future pieces in the “Breaking Down Po.et” series, we’ll lay down the foundations for how we categorize claim types. We intend to continue down the path of interoperability with commonly accepted standards and schemas. Most importantly, we want to work with established organizations that can help usher in a new era for media.