The development team has been working on the Po.et node diligently over the last several months. Significant progress has been made behind the scenes reconstructing a more efficient node. We are excited to finally share our progress with the community.

As anyone who looked at our Github repository knows, the Po.et node project had many goals and responsibilities. It was intended to have a microservice architecture, in which different containers host different projects. These projects include:

A web server An application to read the blockchain and import any contained files An authentication API A system seeding and pulling in torrents A “Mock signer” for signing claims in dev/test mode A “trusted publisher” that will publish signed claims to the blockchain using its “authority” An explorer API to search works in the blockchain A notifications API

These goals were all interconnected, and when we tried to reason through the position of each new component, we had a very hard time doing so. We decided to spend a few days brainstorming a system that was more reasonable and logical. Today, we’re excited to describe that new system to our community members.

Po.et Node 2.0

Our new “Node” will have the following responsibilities:

Publish timestamped content to IPFS

Timestamp transactions to the blockchain

Ingest blockchains to build an internal database

Surface all of these functions via a simple API

This will be much simpler as there is no key management, minimal transaction wrangling and no authentication. All “Node” interactions are unauthenticated, meaning any transactions (such as those involving ownership or signing) will be done by external services.

This node — in conjunction with the blockchain we work on (presently bitcoin, but we have plans to be able to ingest other blockchains as well) and our distributed file system (IPFS) — make up the Po.et Protocol.

Po.et Applications

Following this development, we will then build out the first few Po.et applications. At the application level, we are dealing with identity, keys and signing. Eventually, we will add other applications that make decisions about the content (such as those involving validators or notaries) at this layer.

Frost

Frost is a service whose key concern is making it easier for existing systems that drive businesses to interact with the Po.et protocol layer. Frost functions in the following way:

Users will create accounts (likely an organization account) and will be provided with API credentials. Frost will create a keypair behind the scenes and secure it using industry best practices. Users will make posts (authenticated with their API credentials) that are standard JSON containing their content according to our published schema:`author`, `title`, `keywords`, `body`, `publication date`, `publication url`, etc. Users will not sign, compose the Po.et protocol “transaction,” or do any cryptographic functions. Frost will compose the Po.et protocol transaction, send it to the key management system for signing and then forward the transaction to a node API for publication to the blockchain and distribution on our file store.

We realized the pressing need for this system when we were working on a WordPress plugin. We envision that our WordPress plugin will interact with Frost; putting together a plugin that will just send the contents of a post to Frost is a project that should take mere hours.

Po.et Explorer

This application will initially be built out as the “block explorer,” similar to blockchain.info. Users will be able to browse the content currently in the Po.et network, search for works, and be routed to publishers who are currently displaying works of interest to the user. Essentially, the Po.et Explorer is a visualizer and search engine of works that are exposed by the Po.et API.

Initially this system will be completely public (with no authentication), but we envision an eventual authenticated mode for this application that will unlock more powerful features.

So we have a busy next few weeks! Fortunately, we are going to be able to reuse a lot of the key parts of the code around interacting with the blockchain, and the Po.et “protocol” will not change from our initial design. However, almost everything about its implementation will change. As of now, we have “de-risked” the main parts of the system that will be changing, and the remaining work is largely wiring existing (or nearly completed) components or components of very known and limited scope together.

While we’ve missed some of the dates outlined in our first roadmap proposal, we are extremely confident that after this batch of changes, we’ll have the momentum and capacity to reach our other milestones ahead of schedule. This proverbial backtrack is done in order to move faster.

Again, thank you to our community. We have been blown away by your passion and willingness to help. We’re eager to release the new node and Frost in early December.