dldeploy Is Building a MATA Home Integration for Local ESP32 Devices

dldeploy is building a MATA Home integration so a local ESP32 can join the household computer and keep working without a vendor cloud in the loop. Home, on MATA, is the function that holds the house: the computer you own, the devices you adopt, and the view of those devices. The integration is the seam between that function and a board flashed from this site. It is being built. A finished switch that already places every ESP32 on the Home screen does not exist yet.

A local ESP32 in this family can already mint its own identity, accept an owner, and stream on the LAN. The MATA Home integration is the step after that: the device speaks a protocol the home computer already understands, so Home does not need a second cloud account to notice the board. The crates are Remade With Rust. The mesh they ride is iroh.

What the MATA Home integration is for

A vendor smart home sends the camera, the microphone, and the presence reading to someone else's server, then loans the view back through an app. A MATA Home integration keeps those bytes in the house. The computer that is supposed to hold them is the home computer described in the MATA freedom guide. The argument for refusing the vendor server is a smart home without the cloud.

The home computer, not a vendor account

Home is the household function on a machine you keep. Adoption is a signed record between that machine and the device, through rusty_esp_mid. The device mints a P-256 did:mata on first boot. The owner pins their key. On a real chip, a stranger presenting the owner's own record was refused, and an older record that a key rotation had replaced was refused too. That identity is the ownership half of a MATA Home integration. The Own vision is the longer form of the same rule: the device and the household decide, and no remote account can turn the board off by closing.

Direct, here, means the board does not detour through a claiming portal. The field note on rusty_esp_iroh names the seam: mata-oem-sidecar/rpc/1, the home computer's existing JSON protocol, so a device can appear in the owner's app without a change at the other end. A MATA Home integration is that seam, aimed at Home.

The protocol the integration speaks

An iroh connection is opened for a named protocol. A Janus node speaks a small fixed set. Liveness, manifest and adoption, media packets, and signed updates each have their own name. The sidecar name is the one the home computer already speaks. A MATA Home integration uses that name so the home computer can catalog a local ESP32 as a device it already knows how to list. Cataloging is the claim that sentence can carry. Playing the camera inside Home is a later sentence, and it is still open.

The node runs on the std track, Rust on ESP-IDF. There is no C in our crates. Track A still sits on Espressif's C, and every Wi-Fi radio runs Espressif's binary blob. A MATA Home integration that promised a C-free radio would be false while the radio is up.

What a local ESP32 can already do on the LAN

The measured afternoon is a board on your network, not a screenshot of Home. Deploy an ESP32 at home in an afternoon is the sequence that has a ledger behind it: flash a firmware from a short manifest, provision Wi-Fi into a settings partition, let the device mint its identity, and adopt it. On the verified mesh run, the subscriber was a laptop client. A camera page in the browser, an RTP player such as ffmpeg, or the iroh client can see the stream. A polished Home view cannot, yet.

The path that has been measured

On a Seeed XIAO ESP32-S3 Sense the node was up 3.2 seconds after boot and delivered 721 camera packets in 60 seconds, with none lost and none out of order. The camera page answers 403 without a token tied to the device identity. Sharing the Wi-Fi password with a guest is not the same as inviting them into the camera. Those rows are what a local ESP32 can do today. A MATA Home integration is meant to land the same rows on the home computer. Smart home access on your home computer is the shelf those jobs hang on, and that page says the same limit in its own words.

The first flash still starts on the laptop. espino reads a board record and a manifest, checks the image fits, and writes it. You do not edit GPIO numbers for a cell that has already run. Presence sensing is a different row: the radar and Wi-Fi channel builds compile, and they have not run as a verified device, so they are not part of this integration's measured claim.

Boards that join as a node, and boards that use a bridge

A local ESP32 is a family of chips, not one part. Boards with at least 8 MB of flash on the std track can run the node. The XIAO ESP32-S3 Sense is the board that has run it on silicon, on a Wi-Fi network the board hosted itself. The C6 firmware builds and has not had that run. A board with 4 MB of flash, such as the ESP32-CAM, never runs iroh. It reaches the mesh through a bridge: a std process on a neighbouring machine that fronts the smaller board and relays that board's own signed manifest. A bare-metal no_std chip takes the same path. The home computer verifies the neighbour. The bridge holds the session and does not hold the neighbour's key. Choosing an ESP32 board is where the flash size and the PSRAM split are written down.

That split is how "every local ESP32" can be an honest aim. Some boards are the node. Some boards stand behind a bridge. Both stay off a vendor cloud. A MATA Home integration that said every module runs the node itself would erase the 4 MB row, and this page will not do that.

What the MATA Home integration still owes you

Building is the status. Two rows are open on purpose, and the other pages already name them so this one cannot quietly close them.

The media view inside Home

The home computer's media controller is not wired to receive a Janus stream. The protocol seam is named. The wire from that seam into the Home picture is the work dldeploy is doing. Until the wire exists, "see it" means the LAN page, the RTP player, or the iroh client. It does not mean the Home screen. The Connect vision is where the mesh sits while that wire is still open. Saying the integration already enables every local ESP32 inside Home would turn this page into the vendor brochure the rest of the site refuses.

Reach from outside the house

A MATA Home integration on the LAN does not need the public internet. Turn the WAN off, leave the LAN up, and the measured page still has a path: the device is on the network it joined, and the owner is still the owner. The PSRAM tier can use a relay so a short ticket works from another network. That relay path is written, and no relay has been dialed from a board. The no-PSRAM tier is LAN-direct by design. Off-LAN reach stays out of the title until a board has done it.

A few limits sit beside those two, and they are the same limits the field notes already publish:

• The media controller inside Home is not wired to a Janus stream.
• Reach from outside the house is not a measured row.
• Only the XIAO ESP32-S3 Sense has run the mesh node on silicon.
• Development firmware can still store the identity key in a plaintext partition. The identity field note says so.
• After adoption, a device can still advertise itself as free to claim, because that record is composed once at boot.

Start with the afternoon guide, then the Learn index for how far each package is proven. A MATA Home integration grows by wiring the home computer to streams the LAN already carries.

The Home function this page is about is on MATA. The crates that speak the sidecar protocol are Remade With Rust. A MATA Home integration is those two, plus the LAN path you can run this afternoon, plus the Home view that is still being built.