Moving Picos from Mesh to Mesh
Software that can’t leave the machine it was born on isn’t really yours. Version 1.7 of the pico engine lets a pico and its subtree move between engines while its relationships keep working, because other picos follow its DID rather than its address. This post describes what moves, why identity is what makes it possible, and what’s still ahead.
Continue reading {Moving Picos from Mesh to Mesh}
Why Not SPIFFE for Pico Identity?
A pico is arguably just a workload, so why give it a DID instead of using SPIFFE, the standard workload identifier? The answer comes down to whether the identity is meant to last. SPIFFE derives a workload's identity from what it is and where it runs, so it's re-minted per environment; a pico's identity is long-lived and travels with it.
Continue reading {Why Not SPIFFE for Pico Identity?}
Pico-to-Pico Identity Arrives
Version 1.6 of the Pico Engine ships the pico-to-pico identity layer I promised but hadn't built. Every pico now carries two DIDs: a portable did:webvh that says who it is, and a private did:peer for each relationship it forms. This is the piece that lets a pico move between engines and lets two meshes create a relationship without a federation agreement set up in advance.
Continue reading {Pico-to-Pico Identity Arrives}
Secure Pico Channels with DIDs
Decentralized identifiers are a perfect complement to the event channels in picos and provide the means of performing secure messaging between picos with little effort on the developer's part.
Continue reading {Secure Pico Channels with DIDs}





