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}
Moving My Sensor Network onto Manifold
I moved my working LoRaWAN sensor network onto the new Manifold framework and pointed Home Assistant at it as the interface. The port went smoothly until the OAuth protection on the mesh blocked the inbound webhooks Helium uses to deliver readings. The fix was to let a mesh owner scope access channel by channel, and the pico engine now supports it.
Continue reading {Moving My Sensor Network onto Manifold}
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}
A Map of the Manifold Environment
A reader asked for a map of the whole Manifold environment and the functional capabilities of each part. I have described this system across three posts, a piece at a time, but never in one picture.
Continue reading {A Map of the Manifold Environment}
Using Home Assistant with Manifold
Manifold is evolving into a proper framework for building meshes of picos, and Home Assistant gives those meshes an interface. A new Home Assistant integration proves out three pieces at once: an OAuth workflow on the pico-engine that lets outside software into the mesh on the owner's terms, a mature interface rather than a custom one, and a pattern that lets specialized communities extend the platform.
Continue reading {Using Home Assistant with Manifold}
Identity for the Pico Engine
Version 1.5 of the Pico Engine finally brings identity into the engine itself: passkeys for humans, and OAuth for external apps and webhooks. Here's the shape of the design, why identity is really three problems and not one, and why I shipped the human and third-party layers before the pico-to-pico layer.
Continue reading {Identity for the Pico Engine}
Manifold API and Sensor Network: Two New Repos
Cleaning up manifold-api as a prerequisite for the spring conversational interface Capstone turned into a complete platform update: Pico Engine 1.0 compatibility, automated bootstrap, centralized notifications, and a Docker-based integration test harness. Once the platform was solid, the old temperature-network had an obvious new home inside Manifold's community framework, so I rewrote it too as an example of how Manifold can be a framework for pico networks.
Continue reading {Manifold API and Sensor Network: Two New Repos}
Building a Conversational Interface for Manifold with MCP and Picos
GUIs are dead—at least for most user experiences. This post describes a BYU capstone project where five seniors built a conversational interface for Manifold using MCP and picos. The result shows how natural language can replace a GUI entirely, letting users create, tag, and manage digital things through dialogue instead of learning a standard graphical user interface.
Continue reading {Building a Conversational Interface for Manifold with MCP and Picos}





