rusty_esp_mid Is a Pure Rust Alternative to a Vendor Account

rusty_esp_mid is a pure Rust alternative to a vendor account for an ESP32 you mean to keep. The market standard for "who owns this device" is an account on someone else's server: claim the device, renew a certificate, and hope the account still exists when you need it. Here the device mints its own key, and the household adopts it. This page is the comparison. The builder field note on rusty_esp_mid is the protocol record. It belongs to the Own vision.

What a vendor account is doing

A vendor account answers one question: who is allowed to talk to this camera. It answers it by holding a database. The device is a row. The password is yours until the terms change.

What you give that database

You give it the binding between a person and a device, and you give it the power to revoke that binding. That is convenient, and it is also a service that can disappear, leak, or resell the relationship. A pure Rust alternative to a vendor account keeps the binding on the device and on the owner's key. There is no cloud certificate to renew and no server that can quietly take the device back.

What did:mata is

Every device holds did:mata: plus the base58 encoding of a 33-byte compressed P-256 public key. Because the identifier is the key, it is self-certifying. The curve is fixed. mID, the identity system the MATA home computer already uses, is P-256 throughout, so this crate uses P-256 too: never ed25519, never secp256k1. Signatures match the reference signer byte for byte for the same key. A device-signed assertion verifies in the reference verifier, a replay is refused, and the capability check agrees with the reference on 144 of 144 cases.

How adoption works without an account

The owner signs an adoption record naming the device, the owner, and the capabilities granted. The device verifies it and pins the owner's key on first adoption, then refuses adoptions from anyone else. On silicon, a stranger presenting the owner's own record was refused, and so was an older roster version.

The key, and where it is not yet

On first boot the ESP32 draws the P-256 key from its hardware random generator and writes it to an identity partition that reflashes and Wi-Fi changes do not touch. Pure Rust, no C, no FFI, no_std by default. Current development firmware runs with flash encryption off and opts into a plaintext partition through a loudly named dev feature. Wrapping that key under an eFuse-held key, or moving it to a secure element, is planned and not what the measured boards are running. A pure Rust alternative to a vendor account does not get to imply a hardware vault it has not shipped.

Signing cost is measured. On a XIAO ESP32-S3 Sense at 240 MHz, a signature is about 95 ms and a verification about 151 ms. Janus signs a session, not every frame.

Updates the owner can refuse

The update path checks the owner, the device's ota capability, a trusted maker, the chip, the model, the size, and the maker's signature before reading a byte of the image. A maker-signed update has run on silicon. Refusal of a bad signature and rollback are tested on the host so far, not yet as a silicon row.

Where a vendor account still wins

Stay with an account when you want a password reset run by a company, a fleet dashboard you do not host, or a warranty process that requires their cloud. A pure Rust alternative to a vendor account assumes the household is the authority.

Honest limits

• The identity partition on current dev firmware is plaintext. Say so before you put a camera in a hallway.
• After adoption, one open defect remains: the device can still advertise itself as free to claim, because that record is composed once at boot. It is written down in rusty_esp_iroh, not hidden.
• Remote access from outside the house is a different question, covered in a smart home without the cloud. The relay path is written and not yet measured on a board.

The practical test is simple. Unplug the router from the wider internet and see whether the household can still tell the device who owns it. A pure Rust alternative to a vendor account has to pass that test, because the adoption record is signed by the owner and checked by the device. There is no round trip to a login server in the field note's handshake. A pure Rust alternative to a vendor account still needs you to keep the owner key, the way you keep a house key. Lose it and the device keeps the pin it already stored. A pure Rust alternative to a vendor account does not offer a "forgot password" link, and that absence is the feature, not a missing screen. A pure Rust alternative to a vendor account is the wrong promise if you wanted a helpdesk. A pure Rust alternative to a vendor account is the right promise if you wanted the helpdesk out of the trust path.

Where to start

Read the field note, then deploy an ESP32 at home in an afternoon and choose a board with enough flash to hold the identity partition. The Learn index and the Flash vision cover the tool that writes it.

The crate is Remade With Rust and speaks MATA. When an adoption log needs to become a retrieval corpus, the same house runs RAG Converter. The curve math is ordinary Rust, checked against the reference signer.