Breaking Down Po.et is a series of articles that will break down specific pieces or concepts around Po.et in detail.

The vision for Po.et set out in the original white paper is extensive, but simple at its core: use cryptographically signed messages about a hash that have been secured to a public blockchain as the basic building block for a better web. If this sounds pretty similar to the concept known as “Proof of Existence”, then you’re completely correct. In fact, Po.et stands for “Proof of Existence 2.0”.

There are four high-level stages to how we describe the Po.et Protocol: describe, record, listen, and curate. Each of these represent a logical grouping of technologies and functionalities that make up our protocol. All of the work from the latest milestone fits within the “describe” and “record” stages. While the engineering team continues to build enhancements on our updated protocol, we are laying the foundation for the next phase of our project.

Describe

“Claims” are the core building blocks of Po.et. These are the permissionless, well-formed signed messages that we record in a completely decentralized way.

This stage is “describe” because we’re creating standard ways to format claims. If you’re familiar with other Proof of Existence-type projects, they typically allow for any type of structure or format for whatever is being hashed. However, when the Po.et Node looks for data to ingest into its internal database, it requires the data to be formatted in a known way. This coordination opens up new opportunities to link data together, hence why we say this is our building block.

Po.et requires the original file to be accessible to anyone making a claim about the content and requires the file be stored in an immutable way. If all we had was a hash and no file, we wouldn’t be sure that our claims are all referencing the same thing, therefore making our claims less valuable. However, for private systems, content can be encrypted before publishing which allows the ability to make claims about sensitive information. The identities making claims about the content would have to coordinate the decryption outside of Po.et right now, though. We’ve made the choice to build Po.et to work for building out a better web for information that should be public, but still want to ensure that it can be used for information that requires privacy.

Where we are today:

“Work claims” are our first type of claim meant to represent a creative work. The attributes we can make claims about are basic, such as, “author” or “datePublished”.

We rebuilt the core of the protocol to use JSON-LD serialization (as opposed to vanilla JSON) with LD-Signatures. We explored a few other options and we’ll potentially elaborate on the process in future posts.

JSON-LD allows us to “link data” together in a way that gives us a ton of flexibility towards working with existing standards. For instance, we’re already using definitions from the W3C’s schema.org and Dublin Core Metadata Initiative in our first claim types.

What we’re exploring:

Claims about identity and relationships between identities.

Claims that are sufficient for licensing, rights management, and protection of intellectual property.

Claims that represent some type of service rendered, like fact checking, where there are additional steps required to provide enough information for validation.

Record

Because Po.et doesn’t rely on our own blockchain, we use the power of combining Bitcoin (BTC) and IPFS as our sources of decentralization.

We use the BTC blockchain as our public blockchain in which to record the hashes that reference IPFS directories. Those IPFS directories contain a batch of claims, also written to IPFS. Each claim is cryptographically signed by a private key so that we have an immutable history of who’s claiming what about content on the Po.et Network.

Now, we’ve got a well-structured document that is accessible to anyone via BTC and IPFS. Batching claims together significantly lowers the cost of securing information on Bitcoin. Technically, anyone could manually follow these steps for writing claims and they would become part of the Po.et Network. We’re not putting up transaction fees that artificially limit who can and can’t use Po.et.

The Po.et Node software that has been built by the core team implements a package we’ve named Frost. Frost is a custodial wallet solution that allows for interfacing via API. Each node can chose whether or not to implement Frost as it may not be necessary for each implementation. With Po.et run nodes, we’ve made the decision to focus on promoting the API-based interface to everyone that has no need for running a node today. This dramatically simplifies our ability to get other applications integrating our technology before they have to commit to running a node themselves and allows normal consumers a super simple way to get content on the network. For those that want to have their own node, we’ve made everything fairly painless to get running via Docker and recently revamped all of our documentation.

Also, in order to increase initial adoption, the Po.et core team will be building out a few applications for managing content and claims, including content and claim storage. At first, we’ll impose a few limits to ensure we’re stable and fight off any threats, but in no way does this affect the decentralization of the actual Protocol or Network. We also recognize that in the early days of Po.et, there won’t be very many other options being built outside of the core team and we’re going to work as hard as possible to get other development teams on board so that this isn’t the case.

Where we are today:

Decentralization from day zero through trusted protocols.

Content must be publicly accessible and hosted on IPFS. If you want to conceal the contents of a particular piece of content, you only need to encrypt the file before using it.

The nodes that the Po.et core team runs and makes available through our domains leverage a custodial key system we’ve named Frost. Each node can choose whether or not to use Frost as it was built as a standalone project.

What we’re exploring:

Allowing for other decentralized file storage protocols, especially ones that allow enterprise users to leverage existing systems.

Expanding to other types of blockchains for additional security.

More options around privacy, including zero-knowledge proofs.

Flexibility with additional identity providers, including both centralized and decentralized.

Listen and Curate

We have to take our immutable, well-structured claims and decide which claims we believe to be true in order to construct our independent view of the content those claims reference. Once we’ve decided which claims to believe, we can then start to sort, rank, and file content in meaningful ways.

Up to this point, our work on these stages has been mostly theoretical and we have not implemented these concepts in production yet. As Jarrod says, incentives drive behavior and behavior creates culture, so we want to be extremely mindful and thorough as we move forward with any type of incentive-driven protocol development.

There are few assumptions we’ve made:

Anyone can make claims

There is no assumption of truth in a claim

Claims have to be cryptographically signed

We have the right to choose which claims to believe

Making individual choices about every claim will be extremely difficult

Truth must be cheap to ascertain; lies should be expensive to maintain

The future of Po.et depends on our ability to extend the protocol to provide incentivized ways to make sense of all of this information. Otherwise, the value of the content on the network will be extremely localized to each individual piece of content. As an additional goal, we hope that investing into validated, truthful claims about your content will increase the opportunities content creators have in front of them, especially compared with content on the normal web that doesn’t have established context associated with it.

Where we are today:

Working with teams currently using Po.et to understand their needs around reputation. We’re working on their private systems to help test out some theories first.

The private systems have focused on collecting claims made by some type of trusted authority that they already are aware of. We don’t have the scale yet to establish reputation histories that we can programmatically trust.

We’ve built out some basic Ethereum-based smart contracts to begin curating content. We are not sure if these will be the basis for our production contracts at this point.

What we’re exploring:

We want to deliver incremental improvements to the protocol that layer in new functionalities around reputation and choice. That might require building out some hybrid system that includes off-chain transactions.

A multitude of super early stage smart contract concepts that we’re not ready to share any concrete information about just yet. This is a major chunk of work that we’re just getting started on and there is no timeline for when it will be ready. We’re actively engaged with the broader curation community to observe patterns of best practices and failures.

Tying It All Together

Po.et is building the decentralized protocol for content ownership, discovery, and monetization in media. Closing out our “Road to Mainnet” milestone is giving us the foundation for us to improve on the first two stages, “describe” and “record”, but the work will never be done in those stages. We have to continue to support them while also pushing to get clarity on what comes next.

If you look hard enough, you’ll see Po.et at the beginning of a spectacular journey that enables completely new stories that will shape the decentralized web: