HOM3 is local-first AI infrastructure: run capable AI on hardware you own, where your data and the record of what the system did stay yours -- verifiably, and without trusting a central authority.
Three layers, one project, Metal to app;
- Desktop app (shipping): the command center, source-viewable, mesh, nuetrino, silicon-salt. Install and runs offline/BT/wifi/mesh/airgap
- Custom OS: lean Buildroot system on a mainline kernel, own init/boot core (~2,660 lines 100% rust zero external crates), first boot achieved on RK3588 (OrangePi 5 Plus) - zero internet .
- Handheld: a carrier-free sovereign device -- RK3588 prototype, 8" DSI 1280 touch panel , ESP32 connectivity/communications.
Why it exists: provenance should be a property of the system, not a sticker on a file. The record lives on hardware the operator holds, chained and tamper-evident, checkable by anyone without a central referee. See Architecture file.
Follow the build: bring-up logs, the boot and the road to CS h
We have been busy making changes to our prototype aiming to finalize with CS. Moving toward a dual boot structure with cross is persistent data partition.
One booting all native hom3os boot, init to application. The other boot option being a custom armbian. More than just swapping boot logo (something I did in the 90’s), iv been making kernel edits to work with overlays for custom touchscreen, display and sound drivers. Having a Linux kernel based option is something we are adding upon suggestion.
I think the most exciting thing about this work is the rarity of metal to application integration with heavy sovereignty focus. While truly removing all vendored blobs and drivers is a tough feat if the goal is easily integrating to whatever users hardware is we think dual boot makes for a unique option. If a user wants maximum sovereignty go native hom3os with our flexible custom drivers . If you want something to run with vendored drivers then switch to the hom3linux and pull the drivers you want.
major challenges were around DSI/touchscreen drivers overlay which (for the moment due to goodix) seems to be behind us! Now working harder to integrate Hom3’s application layer, security, encryptionc compression and other functions more natively.
on the hardware side…
Finally pushing prototype into different encasements. Battling battery and voltage differences, efficiencies, thermal and sound/speakers. While everything is looking great at a prototype level trying to bring a level of detail and value that’s consistent with our software.
Big updates (and warstories) on hardware but today the biggest news is the software we are embedding. The application layer just dropped full source viewable and licensed free to natural persons. I did this because trust isnt trust me, its read me.
Honestly even with the help of AI auditing this masterpiece of cryptography, applications, secrets/trufflehog/gitleaks, etc. was almost a full week of work. Thousands of lines of code edited at the finish line. 1,700 false positive critical findings reviewed for 4 meaningful ones. But its done and I can say I am truly proud of it. Now i can get back to the hardware it will run on so i can deliver a full sovereign integrated stack this year!
Well today was the day to get the mesh network up for hom3. To be honest iv been sitting on the heltec devboard for a while now but have been busy on other things. Because our software has mesh wheels and encryption envelope etc for various functionality it had to be tested. Of course the chip came with some demo firmware that scanned for wifi so step one: hold program and reset to send to boot. Then we just had to connect to meshtastic and flash the current firmware. With that I realized my actual software connection was missing a link pending the actual firmware i used that i had left blank in code earlier and a couple other sections that needed backfilling. I also now have my codebase set to fallback/search/find connected device and backfill so users wont have that issue.
Anyways back to hardware. Got it up and has to set location, and other preferences. This normally would have been simpler but sticking to HOM3 ethos i kept it lean: pyserial plus vendored protobufs, nothing else. No meshtastic package, no BLE stack, no MQTT client (had to set off on device as well as firmware tried to override my backend call here). the way it works is HOM3 speaks the serial direcly 0x94 0xc3 magic, big-endian length, protobuf frames, want_config_id handhsake and transmits on private_app so it never tangles with the mesh. For the presence envelopes used ed25519 signed on host. radio carries opaque bytes and never holds a key. loose the radio, loose nothing but your hardware. No accounts. No servers. No internet. Just a signed "hello" on the radio band. HELLO WORLD FROM HOM3. Operator out. 1<3
So we have opensourced the boot-init 100% Rust MIT on github. We have a booting prototype and a kick@ss application. You can see the application on our website. Check out the architectural docs i just posted. The celestial witness is patent pending and very strong (exists and shipping right now on the software side). ESP ready both software and hardware with extra security layers. Embedded has always been fun added that even before hardware integration with the app writing a seed on silicon to mix in with the master keys. Hey every safe HOM3 needs KEYS! Working right now on secure init to app transition layers and kinks. debugging at 1500000 PUTTY of course since forever. Will post videos and more pictures soon or more updates/logs whatever youd like.