mID On The Chip — Device Identity For The Distributed Cloud

🪩 The Disco Party is MATA's distributed cloud.

mID on the chip is device identity that does not rent a provisioning cloud. rusty_esp_mid gives an ESP32 a DID, a key that lives in encrypted NVS or eFuse, signed assertions the mesh can check locally, owner adoption as a signed grant, and a signed capability manifest. That is the whole replacement for "create a thing in the vendor console, download a cert, hope the factory script did not leak." Sign in with Sovereign ID is the same primitive on a website: verify a token in process, no OAuth, no MAU fee. This article is that primitive soldered down.

A distributed cloud that cannot name a device cannot grant it storage, cannot pay it, and cannot revoke it. Passwords on a server do not scale to a million doorbells. Device identity has to travel with the silicon. The Disco Party is the network that accepts those names. What Is A Distributed Cloud is the definition.

Why mID On The Chip Replaces Vendor Device Identity

Vendor provisioning is a product because it is a chokepoint. The factory talks to a cloud. The cloud issues a credential. The credential only works while the vendor still likes you. Brick-by-account is not a bug. It is the business model. mID on the chip cuts that wire. The device generates or receives a key in hardware-backed storage. The owner adopts it with a signed grant. Peers verify assertions without calling MATA. Device identity becomes a math problem, not a portal.

Trust is the Digital Freedom primitive that maps to identity. Security is encryption of the key material at rest — NVS encrypted, eFuse burned, not a PEM in a firmware partition that every teardown blog dumps. Incentive is payouts to the owner of a well-behaved node, not a fee to the vendor for the privilege of existing. The NIST Zero Trust Architecture says authenticate every device, every time, with no ambient LAN trust. mID on the chip is that sentence in firmware.

The Electronic Frontier Foundation has the case file on always-on device accounts. The Privacy Rights Clearinghouse has the breach list. Device identity that never left the chip cannot appear on either list as a vendor dump.

How mID On The Chip Issues Device Identity

rusty_esp_mid is the crate. It sits beside esp32 iroh (rusty_esp_iroh) so the mesh can ask "who are you" without a cloud IoT SDK. Iroh on the host is the same conversation at laptop scale.

Device DID And Keys In eFuse Or Encrypted NVS

The DID is the public name. The secret stays in eFuse or encrypted NVS so a reflash does not mint a new stranger unless you intend it. Device identity that changes every OTA is how you orphan capabilities. Device identity that lives in plaintext flash is how a $12 programmer becomes a cloning factory. mID on the chip picks the boring, correct store.

Owner Adoption Is A Signed Grant, Not A QR Into A Vendor App

Adoption is the moment a human says "this silicon is mine." On vendor stacks that moment is an account link. On mID on the chip it is a signed grant: the owner's Sovereign ID key signs a capability the device will honor. Lose the vendor. Keep the grant. Revoke the grant and the device is a paperweight to everyone except a new owner who presents a new signature. That is device identity with a delete key that you hold.

The Signed Capability Manifest Is The Device Identity ACL

A manifest lists what the chip may do: publish telemetry, accept rpc, store shards, spend a settlement budget. Peers read the signature. They do not read a dashboard. The NIST Secure Software Development Framework wants attested, reviewable software. A signed capability manifest is attested policy for a part that will never see a code review from the person hosting it. SpaceDB's KeyDirectory seam is mID at database scale. Same primitive, two altitudes.

Device Identity On The Chip Joins The Distributed Cloud

Without mID on the chip, Janus is a radio. With it, Janus is a peer. Remade With Rust is the catalog. The Importance of Remade With Rust is why the crate is not a C provisioning blob. Digital Freedom Era 2 is peers adopting peers. The Freedom Guide is how a person starts.

mID On The Chip Verifies Locally — No OAuth For Toasters

There is no /token endpoint for a sensor. Device identity checks happen on the verifier. That is the same local-verify rule as the website button, applied to a part with kilobytes of RAM. No MAU fee. No client ID. No "device shadow" of who you are.

Revoke Device Identity Without Bricking The Neighborhood

A leaked key is a grant you burn, not a fleet you recall. mID on the chip makes revocation a capability event. The Federal Trade Commission has a long memory for companies that could not revoke and so collected forever. Device identity with expiry and budgets is how a disco party stays a party.

Remade Primitives, Disco Party, Digital Freedom

rusty_esp_mid is a Remade-With-Rust primitive. It becomes a disco party when device identity lets chips join the peer-to-peer distributed cloud as first-class guests. It becomes Digital Freedom when Trust, Security, and Incentive — identity, encryption, payouts — are burned into the part, not leased from a console. Start at the Disco Party and What Is Digital Freedom. Put mID on the chip. Stop provisioning through a vendor.

Scoped grants instead of a password file are capability tokens. The radio that carries those assertions is esp32 iroh. The web button is Sign in with Sovereign ID.