Picos are Internet-first actors that are well suited for use in building decentralized soutions on the Internet of Things. Here are a few resources for exploring the idea of picos and our ideas about they enable a decentralized IoT if you’re unfamiliar with the idea:

• Picos: Persistent Compute Objects—This brief introduction to picos and the components that make up the pico ecosystem is designed to make clear the high-level concepts necessary for understanding picos and how they are programmed. Over the last year, we've been replacing KRE, the engine picos run on, with a new, Node-based engine that is smaller and more flexible.
• Reactive Programming with Picos—This is an introduction to picos as a method for doing reactive programming. The article contains many links to other, more detailed articles about specific topics. You can thus consider this an index to a detailed look at how picos work and how they can be programmed.
• Promises and Communities of Things—Promise theory provides a tool for thinking about and structuring the code that implements communities in groups of social things. This blog post discusses some initial thinking about promises and picos.
• Social Things, Trustworthy Spaces, and the Internet of Things—Social things interacting in trustworthy spaces represent a model for an Internet of Things that is scalable to trillions of devices and still works. This post describes that concept and proposes picos as a platform for building social things.
• Market intelligence that flows both ways—Doc Searls talks about how pico-based shadows of products are useful in creating new customer service interaction patterns. The pico-based system he references, SquareTag, is no longer in active development, but we're replacing it with a new system called Manifold that reflects the community of things ideas I reference above.

The New Pico Engine

Picos run on an engine that provides the support they need for Internet services, persistent storage, and identity. Over the past year, we've been rebuilding the pico engine. The Classic Pico Engine was a big cloud service. The New Pico Engine is a small, nibble Node program.

We recently built several demos with the pico engine to show this. Both used the pico engine running on a Raspberry Pi in IoT scenarios. The first was a demo of a computer closet (here's a wrietup of an early version of that demo) that uses temperature sensors and several fans to show how picos can cooperate to achieve some goal (in this case keeping the closet sufficiently cool). The second was an overengineered Jack-in-the-Box that had a pico engine running internally to play music and spring the door.

A Mesh for Picos

Picos operate in a mesh, regardless of where they're hosted. Picos don't have to be running on the same pico engine in order to form relationships with each other and interoperate.

We've begun a program to more fully support this ideal by making the engine itself part of a larger mesh of engines, each capable of hosting any of the picos in that ecosystem. The vision is that someone using a pico doesn't need to know what engine it's hosted on and that picos can move easily from engine to engine, moving computation close to where it's needed.

There are two problems to solve in order to make this a reality:

1. Picos are addressed by URL, so the pico engine's host name becomes part of the pico's address
2. Picos have a persistence layer that is currently provided by the engine the picos is hosted on.

We propose to solve the first problem using the Sovrin identity platform. I wrote about that idea in some detail in Sovrin Use Cases: Portable Picos. The synopsis is that Sovrin allows us to find picos by name rather than location using the distributed ledger as a storage location for names based on decentralized identifiers (DIDs) that point to the current location of the pico.

We propose to solve the second problem by incorporating the Interplanetary File System (IPFS) into the engine as the persistence layer for picos. By using IPFS, the pico's persistent state would be available to it regardless of where it is being run.

With this two changes in place, we can create a mesh of pico engines. Individual pico engines can come or go as necessary without impacting the ability of the picos themselves to operate normally. The Classic Pico Engine was a child of the early 2000's and used all the tools and techniques we'd learned to create availbility and reliability including load balancing, primary and secondary databases, server farms, monitoring, and automated service configuration.

The new pico engine will be something much more decentralized, lightweight, and adaptable. Pico engines can join a pool to support additional computational needs without complicated configuration or management. I envision a world where IoT device shadows in the form of picos run on a global, secure mesh of pico engines. These meshes could be public or private and supply generalized computer resources on demand.