❮ Entrixy controllers

Open architecture

The protocol, the firmware and the server side are open. You are not tied to a single supplier: the system works offline, can be audited and, if you need it to, runs on your own infrastructure.

Anyone building a product or a business on Entrixy needs more than a promise of reliability — they need a guarantee built into the system itself: an open protocol with test vectors, opening that works without our server, and a server side you can deploy yourself. Independence comes from the design, not from assurances.

What is already done

»An open protocol done
Full specifications BLE and socket — byte-level layout, the cryptography and test vectors to check your own implementation against. You build it on your board from the documentation, with nothing to reverse engineer.
»Reference firmware, MIT licensed done
ESP32, ESP8266, Raspberry Pi and Node.js — working code for both sides, ready to take and port.
»BLE works with no server at all done
Opening runs straight from phone to controller over Bluetooth, with no internet and no call to our server. Controllers ship empty and are bound locally.
»The server never sees your keys and cannot open anything for you done
Commands are signed on the phone and the server only relays them. A guest key travels in an envelope whose key never passes through the server. Even a compromised server can do nothing (see below).
»Device provisioning for production done
Devices are produced in batches belonging to nobody; the buyer binds them with the code on the case.

The trust model — what the server can and cannot do

Openings are signed on the client (end-to-end encrypted) and the secrets are encrypted around the server. Hence:

The server CANNOT	The server can
read your keys (the guest key, the owner secret)	deny service (be unavailable)
forge a gate opening	see metadata: who, what, when, and IP addresses
escalate its own privileges	—

So the server — ours or your own — only affects availability: it cannot open anything on your behalf. Run the server yourself and you hide the metadata as well.

Roadmap

●Stage 1 — any host in the app done
The app can be pointed at your own Entrixy server: connections and the guest links it generates go there. A guest who opens a link from another server connects to that server automatically.
○Stage 2 — the server as a distribution planned
A Docker image of the server side: the WebSocket server, the database schema and instructions. Availability is then in your hands and our outages do not touch you.
○Stage 3 — open source for the app planned
So the client can be audited and rebuilt by anyone — complete independence from someone else's infrastructure and from app stores.

Who this is for

Makers of barriers, locks, intercoms and controllers who need their product to keep working independently of us rather than depend on one company. And anyone building a controller themselves who wants to stay independent of a single supplier. To discuss integration and OEM terms, write to hello@entrixy.com. Protocols: BLE, socket. Reference code and configurator: controllers.