Infra & IntegrationsWeb SystemsIn progress

Sila

Peer-to-peer messaging with no internet, no servers and no SIM

Role: Sole architect and engineer — protocol, native layer, app and docs
Period: 2025 — Present
Stack: Flutter · Dart · Bluetooth Low Energy · Pigeon platform channels · Kotlin · Swift · Mesh routing

Dart source files: 69
Test files: 15
Architecture documents: 9; Including a security threat model and native BLE spec
Backend servers required: 0; By design — there is no backend to take down

The problem

When infrastructure fails, messaging apps fail with it. Every mainstream messenger assumes a reachable server, a working cell tower and an account tied to a phone number. Remove any one of those and the app is a blank screen — precisely at the moment people most need to reach each other.

Sila starts from the opposite assumption: there is no internet, no server, and no SIM. What there is, is a dense population of phones — and every one of them has a Bluetooth radio that works at close range without any network at all.

The product question was whether an ordinary phone could become part of a communications fabric rather than a client of one. The engineering question was whether Bluetooth Low Energy, designed for pairing headphones, could be pushed into carrying a multi-hop message network on consumer hardware.

Hard constraints

No servers of any kind. Not "self-hosted" — none. There must be nothing to seize, block or switch off.
No accounts, no phone numbers, no email. Identity has to work without a registry.
Battery is a hard budget. A relay that drains a phone in two hours is a relay nobody leaves running.
Runs on the phones people already own — no beacons, no dongles, no rooting, both Android and iOS.

Architecture

Each device runs simultaneously as a BLE peripheral (advertising and accepting connections) and a central (scanning and connecting out). That dual role is what makes the topology a mesh instead of a star: there are no gateway devices and no coordinator, so removing any handset degrades the network rather than partitioning it.

Messages are addressed to a recipient and relayed hop by hop. A device that cannot reach the destination directly stores the message and forwards it when a new peer comes into range, which is what lets the network span distances far greater than Bluetooth range and survive nodes that are never simultaneously connected.

Flutter owns the UI, storage and routing policy. The BLE work has to be native — background execution, advertising and connection lifecycles differ too much between Android and iOS to abstract away — so the native layer is written per platform and exposed to Dart through Pigeon-generated channels, giving a single type-checked interface instead of hand-written, stringly-typed method calls.

One device, top to bottom. Flutter owns routing and storage; the BLE radio work is native per platform behind a single generated interface. The peer link is the only transport — there is no server anywhere in this picture.

Flutter / DartUI, local store, routing policy, message lifecycle
Pigeon platform channelsType-safe, code-generated Dart ↔ native boundary
Kotlin (Android BLE)Advertising, scanning, GATT server and client, background execution
Swift (iOS BLE)CoreBluetooth peripheral and central roles under iOS background limits
Mesh relay layerMulti-hop forwarding with store-and-forward for absent peers

Design decisions

Bluetooth Low Energy over Wi-Fi Direct

ChoseBluetooth Low EnergyoverWi-Fi Direct / Wi-Fi Aware

Wi-Fi Direct offers far more bandwidth, which is tempting until you look at what the network is actually carrying: short text messages. Bandwidth was never the bottleneck.

What mattered was power draw, background behaviour and how many peers a device can hold at once. BLE wins on all three, and — critically — it is available and permitted on both platforms without the pairing prompts and vendor quirks that make Wi-Fi Direct unusable as invisible infrastructure.

Pigeon-generated channels over hand-written method channels

ChosePigeon code generationoverMethodChannel with manual serialisation

The Dart-to-native boundary here is not one or two calls. It carries connection state, peer discovery events, GATT read and write results, and error conditions, in both directions, on two platforms.

Hand-written method channels make every one of those a stringly-typed contract that only breaks at runtime, on a device, in the field. Pigeon turns the same contract into generated code on both sides, so a signature change becomes a compile error on all three surfaces at once. On a project whose whole value is reliability when nothing else works, moving failures from runtime to compile time was the highest-leverage decision made.

A written threat model before the first feature

ChoseDocumented threat model driving the designoverShipping features and hardening later

An anonymous relay network has adversaries a normal chat app does not: a hostile node that joins the mesh, an observer who cares about who is near whom rather than what was said, and a seized handset.

Those threats constrain the data model itself — what is stored, for how long, and what a relay is allowed to learn about traffic it forwards. They cannot be retrofitted. Writing the threat model as one of nine architecture documents, before the feature work, is what kept those constraints in the design rather than in a backlog.

Outcome

The application is 69 Dart source files with 15 test files, a per-platform native BLE implementation behind a single generated interface, and a nine-document architecture set covering the executive summary, architecture, threat model, native BLE spec, design system, UX flows, implementation status and roadmap.

It is the project on this site with no backend to point at — which is exactly the claim. Everything that would normally live on a server lives in the protocol instead.

What I'd carry forward

01Bluetooth background execution is where cross-platform abstractions go to die. Accepting two native implementations early cost less than fighting one abstraction for months.
02Writing the docs first was not process theatre. On a protocol-shaped problem, the document is the design — the code is downstream of it.

Next case studyWhatsApp-Native Commerce PlatformA multi-branch store where the entire storefront is a WhatsApp conversation

Key figures