One directory touches the protocol
The whole argument that this is a system rather than a bot rests on one real thing in the tree, and it is measurable.
What is actually enforced
The claim that this is a system rather than a bot rests on one real thing in the tree: a chat-adapter seam with a maintained contract. Every file that touches the chat SDK sits in one directory, and the rest of the system talks to the seam's own vocabulary of messages, scopes and roles instead. Capture, consent, moderation, erasure and onboarding all import that vocabulary rather than the protocol.
The contract states its own intent, and it is written as requirements on any implementation rather than as notes about the one that exists.
This is written as requirements on any implementation, not as notes about the SimpleX one, because its purpose is to let a second core be built against something firmer than guesswork.
| Value | Figure | How to reproduce | Gathered |
|---|---|---|---|
| 10 | runtime files additionally required to be free of the SDK | scripts/verify-adapter-seam.ts · the scheduler, router, ownership and state files, asserted SDK-free so the multi-bot routing layer is drivable with no core at all | 2026-08-30 · main @ 5044c83 |
| 1 | implementations of the ChatAdapter interface today, and it is the in-memory fake | grep for "implements ChatAdapter" in src/ · consumed by the demo routes and two harnesses · production drives the SDK directly inside src/bot/ | 2026-08-30 · main @ 5044c83 |
| 18 | files importing the SimpleX SDK, every one under src/bot/ | grep -rl "simplex-chat" src/ · all hits must sit under src/bot/ · held by scripts/verify-adapter-seam.ts | 2026-08-30 · main @ 5044c83 |
Linking the AGPL simplex-chat library binds Cinderella to AGPL… This is insurance, bought while it is cheap.
This is a specification, not a description.
Real at the seam, and not yet a socket
The sentence a page like this would usually soften. It is quoted instead, because softening it is the only way it could mislead.
The seam is real at the import level and the type level, with a maintained contract that audits its own portability clause by clause — and it is not yet a plug-in point a second adapter could be dropped behind; the contract itself says which clauses a second protocol would have to resolve first.
The interface runs ahead of the code
The interface runs ahead of the code on purpose. The types and the check that enforces them shipped; the phases behind them are deferred and recorded as such. Every clause of the contract is tagged either as one any protocol could satisfy or as one shaped by the protocol that exists, and the known leaks are listed unresolved rather than quietly fixed on paper.
There is one implementation of the adapter interface today and it is the in-memory fake. Production drives the SDK directly. A second protocol is a piece of work, not a configuration change, and this page will not draw it as one.
Several ways in, and not all of them exist
Each way in with the state it is actually in, using the same vocabulary the rest of this site uses for a claim.
| Way in | State | What is real in the tree |
|---|---|---|
| Over SimpleX | built | What runs today: the chat core embedded in-process, with no daemon and no exposed port, one directory as the only SDK importer, and one core hosting every enabled bot with commands serialized and events routed per profile |
| Over a web server, as an ordinary web assistant | started | More than nothing, honestly: a demo route drives the real interaction engine, consent logic and persistence over the fake adapter, with a deterministic rules layer, a 25 message budget and synthetic data. The admin console and the public archive are web surfaces rather than chat ways in |
| Over Matrix | announced | An operator decision on record, and first on the public roadmap. The adapter contract already pre-litigates two Matrix design questions and names its raw JSON leak as the prerequisite to resolve |
| Over Telegram, as a bridge | idea | Nothing in the tree beyond outbound share links on archive cards. The bridge machinery is real and running for SimpleX; Telegram is a direction it was shaped for, not a thing that exists |
| Locally, on the operator's own machine | idea | No local way in exists: no command line, no desktop entry, no plan document in the tree. What is real is that the substance of nothing leaving the machine already holds at the model layer, because the models run on local hardware behind every existing door |
The demo UI is not built. Backend, isolation guard and session handling are.
Nothing Matrix-related is designed or built yet.
Why WhatsApp is not on the list
declined
One line is stronger than silence here, so the reason is on the page rather than the absence. It is a commercial and licensing judgement rather than a technical one, and it is the operator's to revisit.
WhatsApp's terms make commercial use of this kind impractical, so it is not planned.
Three questions, three different answers
Asked together and answered separately, because two of them are guesses and one is enforced at boot.
Three questions get asked together and have three different answers, so they are answered separately. Two of them nobody has ever run, and averaging them into one reassuring sentence would overclaim the parts that are guesses and underclaim the part that is enforced at boot.
The model call stays localbuilt
The boot refuses any non-private AI endpoint and this runs in production. It holds under any front path.
SimpleX transport over onion routinginference
Onion-capable relays and SOCKS support are SimpleX's properties, in their clients and servers. This repository exposes none of it: the embedded core is started with no proxy or network configuration of any kind, so running behind Tor today means torifying the process at the operating system, which nothing in the tree configures, documents or has ever run. The only Tor in the tree is the lookup gate refusing .onion search requests.
An onion service in front of the consoleinference
One recorded fact cuts against treating it as a config flip. The console's passkeys are bound to their origin's RP ID and the boot refuses on a mismatch, precisely because moving the hostname once locked the operator out. An onion origin is exactly that class of move. The read-only public archive has no such binding and would front trivially, and trivially is still untested.
the product chat, quoted by the operator in briefing SITE-S2-028 · not in the design drop, which carries no Tor material
One recorded path, and one honest guess
The VPN answer is stronger than the onion ones because it carries a production data point. The case built on top of it does not.
Over a VPN, for the one recorded pathbuilt
The model call runs over WireGuard in the production arrangement, and the private-address enforcement admits tunnel ranges by design. Beyond that, nothing in the process cares about the network path, and no incompatibility is recorded anywhere in the tree.
The journalist and agency caseinference
No onion-fronted deployment has ever been run, and this page says so rather than letting the absence read as a quiet yes. What it would be an application of is real and citable: end-to-end transport with no inbound port on the bot's side, a console on loopback behind TLS and passkeys, the consent-first archive, the boot-enforced local model, content-free telemetry, and a design that declines to derive trust from addresses.
it would probably work, and it has never been run