Messaging, calling and a full escrow marketplace that keep working when the network doesn’t — and reconcile without duplicates when it comes back.
The challenge
Most apps treat the network as a requirement and offline as an error state. In much of the world that assumption is backwards: connectivity drops for minutes or hours as a matter of course. And the standard fix — a retry queue bolted onto one feature — falls apart the moment a second feature needs it, because a retried write that is not idempotent produces a duplicate, and a duplicate in a marketplace is a duplicate order.
What we built
A local-first client over a store-and-forward relay, built on the Python
standard library — http.server and sqlite3, no Node, no framework. The core
boots with nothing installed; web push, QR codes and the AI features are optional
packages that load only when present. Two clients (a zero-install web app and a
Flutter port) speak the same protocol to the same server.
One primitive carries everything. Chat messages, marketplace listings and
orders are all a record: an id, a timestamp, a JSON payload, distinguished only
by collection. Adding an entire transactional ecosystem — orders, escrow,
fulfilment — required a new collection value and some UI, and zero backend
changes. The client generates each record id, so replaying a queued write after
reconnect is a server-side no-op rather than a duplicate. A monotonic server_seq
cursor means each client pulls only what it has not seen.
Order state is append-only events, folded latest-wins, rather than in-place row edits. That is not a stylistic preference — it is the only way to mutate shared state safely when devices may be offline and reconnect in any order.
Authorization does not trust derivation. A direct-message room id is computed identically by both parties from their sorted names, so buyer and seller land in the same private room with no server-side room creation. But deriving that id is not permission to use it: there is no browsable user directory, you reach someone by redeeming a personal invite link or an accepted exact-match request, and the server re-checks that connection on every read, write, call and key lookup.
The marketplace is built like a payments product, because it is one. Escrow holds the buyer’s charge until delivery is confirmed and refunds on cancel or decline. Sellers pay an 8% commission; buyers pay sticker price. Both sides must be verified, opening a dispute stops the escrow moving, and escrow cannot hang forever on a buyer who never confirms. Transactions are screened against the OFAC SDN list from a refreshable dataset, with an age gate on top.
It is a full messenger, not a sync demo. One-to-one messages are end-to-end encrypted. Voice and video calls share the screen, meetings have a waiting room, updates disappear after 24 hours, and anyone can go live to their contacts or their shop’s followers, with guests on stage.
Where it stands
Whinchat is live at whinchat.app. Messaging, calls, meetings and live are the current focus. The marketplace’s sync engine, order state machine, escrow accounting, dispute flow and verification gates are built and tested. The Stripe integration is built too, but money movement still runs against a mock provider until the keys go in. A real marketplace carries money-transmission obligations, and that is a legal step, not a coding one.
Capabilities this demonstrates
- Secure Software Engineering — connection-gated authz, sanctions screening, idempotent writes, escrow integrity
- Cloud & DevOps — a dependency-free spine designed to lift to managed infrastructure unchanged
