DEV Community: Mathéo Delbarre

Show us what you're building for people who actually need it

Mathéo Delbarre — Tue, 23 Jun 2026 21:14:50 +0000

By Mathéo Delbarre, 2nd year CS student at EPITECH Nancy, France

I've been publishing about ZamSync, a sync engine I built for district clinics in Bhutan that run on 2G and lose power mid-transfer. The response genuinely surprised me. Strangers from countries I've never visited opened pull requests. Someone took 30 seconds to write a message just to say the problem mattered. A developer forked the repo to build offline-first sync for password managers.

None of that was because I'm a great marketer. I'm a 19-year-old student with no following and no idea what I'm doing on that front. It happened because the problem was real.

That made me curious about something: what else is out there?

Not just projects. Problems too. The ones that don't have a solution yet, the ones where you've looked at the existing tools and thought "none of this actually fits." I want to hear about those just as much.

You don't need an idea to participate

This is the part I want to be clear about.

If you have a finished project, great. Share it.

If you have a half-finished prototype, share it.

If you have nothing built at all, but you work in a field where something is genuinely broken and you've spent years watching people work around it with spreadsheets, paper, or nothing at all... that is exactly what I want to read.

Describe the problem. Be specific. What breaks, when, for who, and why the existing tools don't fix it. Drop it in the comments or write a full article about it. That kind of description is not "less useful" than a GitHub link. It might be more useful, because someone reading it might have the technical background to actually build something.

The best open source projects I know of started as someone describing a problem clearly enough that another person thought "I know how to fix that."

What I mean by "real problem"

Not trying to gatekeep here, but there is a difference between:

"I want a better to-do app"
"District nurses in my region track patient visits on paper because the official system requires internet, and records get lost every monsoon season"

Both are real problems! But only the second one is what this thread is about.

The kind of problems I'm looking for share a few traits:

The people affected don't have the resources to buy a commercial solution
The existing tools are the wrong size, the wrong cost, or built for a different context
The constraint is physical: no internet, old hardware, no power, a language nobody built software for, a population nobody considers a "market"

Some directions to get you thinking:

Healthcare in low-bandwidth or low-resource environments
Education where connectivity isn't guaranteed
Agriculture, livestock, field data collection without cloud access
Accessibility tools for disabilities or languages that the big platforms ignore
Logistics in places where the infrastructure is unreliable
Local governance, civic tools, community record-keeping

If you've seen something like this up close, write about it. You don't need to have the solution. The problem alone is enough to start a conversation. 💡

What to share

If you have a project: write about it. Any language, any stage, any size. What problem does it solve, who does it solve it for, what constraints did you hit, what would you do differently.

If you have an idea or a sketch: write about it. Explain the problem, explain your thinking so far, explain where you're stuck. Maybe someone in the comments has already solved part of it.

If you have a problem and no solution: write about it. Be specific. What is broken, for who, and why. That is the most valuable starting point.

Then tag your article #realworld and drop a link in the comments here. Or just describe the problem directly in the comments. I'll read every one, and I think other people here will too. The goal is to discuss, debate, push back, suggest approaches, show off work finished or not started. Not to do AI slop ;)

My contribution to this thread

I'll start. ZamSync is a Rust sync engine for district clinics in Bhutan: WAL replication with Hybrid Logical Clocks, Version Vectors, mTLS, and ChaCha20-Poly1305 encryption at rest. It runs in under 10 MB of RAM on a Raspberry Pi. It survives mid-transfer power cuts. It syncs exactly the missing delta and nothing more, because 2G bandwidth is not something you waste.

The full story is here:

Mathéo Delbarre

Jun 15

Building software for places where the internet barely exists

#showdev #rust #opensource #discuss

13 min read

The problem that started it was simple: district clinics needed reliable synchronization in places where connectivity and power are unreliable. ZamSync is one attempt at solving part of that problem.

Why I'm doing this

I've spent months inside one problem. I know that problem well. But I have no idea what equivalent things other people are quietly working on, in other fields, in other countries.

I think there is a whole category of work happening at the margins of the industry that never shows up in the feeds. Not because it's not interesting, but because it's not being built by funded startups, it doesn't have a product launch, and the people doing it are too focused on the actual work to write about it. Or they assume nobody else would care.

I think people would care, and I more think this community specifically would care.

So let's find out. What are you building? What problem are you watching that nobody is fixing? What have you tried that didn't work and why?

Drop it below. 👇

-- Mathéo Delbarre

39 stars, my first open source contributor, and a message I keep re-reading

Mathéo Delbarre — Sun, 21 Jun 2026 19:52:51 +0000

A few weeks ago I published this article about ZamSync, a sync engine I built in Rust for district clinics in Bhutan that run on 2G and lose power mid-transfer:

Mathéo Delbarre

Jun 15

Building software for places where the internet barely exists

#showdev #rust #opensource #discuss

13 min read

I wasn't expecting much to be honest! I'm a 2nd-year CS student at EPITECH Nancy. I don't have a following, I don't know how to market things. I said as much in the original article, I just wanted to show the work and see if anyone cared about the problem.

I was not prepared for what came next haha!

The numbers, because people like numbers 💝

39 GitHub stars from people I've never met
2 external contributors who forked the repo, wrote code, and opened pull requests
1 message in the GitHub discussions that I keep coming back to re-read
128 tests passing across all platforms
6 forks from a developer building offline-first tools for password managers, finding out someone found your code useful enough to fork is a strange and wonderful feeling

These aren't big numbers, I know that :) . But this is my first open source project, ever. Before this, the only people who had read my code were my professors. Seeing a stranger from a different country open a pull request on something I built alone in my dorm room at 2am... I don't have a better word for it than surreal.

The contributor moment

A developer named KairosOps opened PR #93 to fix a bug: SQLite paths on Windows were getting a leading slash prepended, turning C:/path/db into /C:/path/db. It was a real bug, cleanly fixed with a #[cfg(windows)] guard and a unit test that covers both platforms.

I'm 19 years old and someone just contributed to my project! (I was so happy that someone saw my issue and added a fix 😭)

I merged it the same day.

The message that got me

Someone named per-oestergaard left this in the GitHub discussions:

"Hi. I read your article and just want to praise you for suggesting, and creating a solution for an important problem. I hope you manage to get it implemented. Unfortunately, I do not have any channels for supporting this."

That's it. That's the whole message. No technical feedback, no code, just a person who read about district clinics in Bhutan, thought the problem mattered, and took 30 seconds to say so.

I've been building ZamSync alone for weeks. The grind of writing tests, fixing edge cases at midnight, documenting things nobody might ever read, sometimes it's hard to remember why. That message reminded me. Someone out there thinks this problem is real and worth solving. That's enough to keep going.

What's new since the first article

I kept building. Here's what shipped:

Embedded status dashboard (Phase 20)

ZamSync now ships with a browser dashboard at /ui. No React, no build step, no CDN. Just a dark-themed HTML page served directly from the binary, showing live event counts, WAL size, uptime, and a real-time event stream via SSE.

The SSE reconnect logic was something I'm proud of: exponential backoff from 1s to 30s, Visibility API support so the tab stops hammering the server when you switch away, and dedup logic so reconnects never replay already-seen events.

Typed HTTP error codes (Phase 21)

The API now returns structured JSON errors with stable machine-readable codes:

{
  "error": "SCHEMA_VIOLATION",
  "message": "missing required field: patient_id"
}

Four codes: INVALID_JSON (400), SCHEMA_VIOLATION (422), WAL_UNAVAILABLE (503), INTERNAL_ERROR (500). The codes are additive and will never be renamed. Client code can safely switch on them.

Documentation site

ZamSync now has a real documentation site built with mdBook, the same tool used by the Rust book and rust-analyzer. Three pages: Introduction, REST API reference, and a full Error Codes guide with retry pattern examples. It deploys automatically to GitHub Pages on every push to main.

Where this is going

The technical goal hasn't changed: I want to propose ZamSync to the Bhutan Ministry of Health as infrastructure for their ePIS district sync problem. I'm a student, not a healthcare professional, and I have no connections there. I don't know exactly how to make that happen. But I'm going to keep building until the thing is undeniably ready, and then figure out the rest.

Next phases on the roadmap:

Async Tokio -- replace OS threads with green threads so ARM nodes with 512 MB RAM can serve dozens of peers concurrently
Conflict detection -- flag when two clinics edit the same patient record at the same time
Key rotation -- re-key a node without losing its event history

If you work in global health, low-resource IT, or have any connection to healthcare systems in low-bandwidth regions, I would genuinely love to talk. My email is matheo.delbarre@epitech.eu.

A personal note

I started this because I read about Bhutan's ePIS struggles and thought "I could try to fix that." I had never written a WAL. I had never implemented HLC or Version Vectors. I had never shipped a Rust binary to ARM. I just started and kept going.

Seeing strangers find the project, fork it, contribute to it, and take a moment to say it matters, it changed how I think about what I'm building. This isn't a side project anymore. It's the most serious thing I've ever made, and I want to see it through.

If you want to help:

Star the repo at github.com/Etoile-Bleu/ZamSync, it sounds small but it genuinely matters for visibility on lists like awesome-rust, which requires 50 stars. I'm at 39.
Contribute -- there are open good-first issues and I merge quickly
Share -- if you know someone working on offline-first systems, rural health tech, or Rust, send them the link
Like and comment -- it helps more people find this
Write to me at matheo.delbarre@epitech.eu, I'm a student, I have time, and I'd love to hear from anyone working on similar problems

Thank you for reading. Thank you for the stars, the messages, and the pull requests. And thank you to whoever you are if you just took 30 seconds to say this problem matters. It does.

-- Mathéo Delbarre

Building software for places where the internet barely exists

Mathéo Delbarre — Mon, 15 Jun 2026 22:15:57 +0000

By Mathéo Delbarre, 2nd year CS student at EPITECH Nancy, France

TL;DR

Problem: district health clinics in Bhutan need to sync patient data to a central hospital hub over 2G connections that drop constantly, with nodes that lose power mid-transfer.
Solution: a Rust sync engine built around an encrypted append-only log, delta sync via version vectors, hybrid logical clocks for clock-drift tolerance, and mTLS for identity.
Constraints: under 10 MB RAM on a Raspberry Pi 3, static binary, no stable connection required.
Result: 5,000 events replicated with zero loss across a simulated 2G link with a mid-transfer TCP cut.
Code: github.com/Etoile-Bleu/ZamSync

I want to tell you about a problem I discovered last year that I couldn't stop thinking about. Not a LeetCode problem, not a framework benchmark: a real situation where data gets lost, patients get hurt, and the existing software world has basically nothing useful to offer.

The problem, in one picture

Before anything else, here is the system we are talking about:

District clinic (Raspberry Pi 3, 1GB RAM)
  WAL: [event_1][event_2]...[event_N]   <- encrypted on disk
  |
  | 2G link: 23 kbps, 600ms latency, drops every few hours
  | (or offline for days during monsoon season)
  |
Hub hospital server
  WAL: [all events from all clinics]    <- encrypted, segregated by origin
  |
  REST API / dashboard / reporting

Each clinic writes events locally. When the link comes up, it syncs the delta to the hub. If the link drops mid-transfer, the next sync resumes exactly where it stopped. No re-transmission, no duplicates, no corrupted state.

That is ZamSync. Now let me explain why I built it.

The thing I found out about Bhutan

Bhutan is a landlocked kingdom in the Himalayas with about 750,000 people spread across terrain that is some of the most difficult on Earth. The country runs a fully free public healthcare system: every citizen, regardless of location, has the right to healthcare.

The problem is the word "location."

Bhutan is divided into 20 administrative districts called dzongkhags. Many district hospitals and Basic Health Units (BHUs) sit at altitude, accessible only by mountain roads that wash out in monsoon season. The government has been expanding its Rural Connectivity Programme: as of 2022, over 850 villages have 2G or 4G access. But "access" and "reliable connectivity" are not the same sentence.

In the highlands, the dominant backhaul option is satellite. Kacific-1, the high-throughput satellite serving Bhutan, delivers latency of around 600ms. In areas on 2G, the average rural broadband speed is 23 kilobits per second. That is not a typo. Twenty-three kbps. And it drops. Monsoons knock out towers. Terrain blocks signal. Power cuts happen.

Into this landscape, the Bhutanese government started rolling out the electronic Patient Information System, or ePIS.

What ePIS is, and what happened when it launched

ePIS is described as "a comprehensive, integrated Electronic Health Record system" managing patient demographics, diagnoses, medications, allergies, lab results, and imaging studies. It launched at the Jigme Dorji Wangchuck National Referral Hospital (JDWNRH) on April 18, 2023, as reported by The Bhutanese.

On launch day, when all staff logged in simultaneously, the network couldn't handle the load. People could not log in. Those who did were waiting to upload information on a single patient. The hospital leadership decided in real time: have every doctor see two or three patients through ePIS, and continue with paper prescriptions for the rest.

Thirty to forty patients had to repeat blood tests because the lab integration failed and the system couldn't capture their phone numbers to notify them.

This is a national referral hospital, in the capital, with the best connectivity in the country.

They fixed it. By early 2024, ePIS had expanded to 58 hospitals and 186 Primary Health Centres nationwide, with over 604,000 patient records and 6,400 registered health professionals. Real progress.

But the BBS article also says: "extreme weather conditions and challenging terrain affect reliable internet connectivity", and power and network issues continue to limit full utilization in remote areas. They are exploring Starlink. The previous system, BHMIS, used distributed MS Access databases where districts entered paper records and physically forwarded database files to the ministry for integration. No local analysis was possible.

ePIS is a generational improvement over that. But the underlying challenge has not disappeared: you still need to get data from a clinic node to a hub node, over a connection that may be slow, unreliable, or completely absent for stretches of time.

That is the problem I wanted to solve. I am a student, not the Ministry of Health. But the class of problem: reliable, efficient, low-footprint data sync between nodes where connectivity is a privilege, not a given.

Why I didn't just use an existing tool

Before writing a single line of Rust, I spent weeks looking at what already existed. The short version:

CouchDB / PouchDB replication is mature and battle-tested, but CouchDB carries ~150 MB of memory overhead and sends entire document revision trees. On a 23 kbps link, that tree overhead alone is unacceptable.

IPFS comes up often in "offline-first" conversations, and I want to address it directly because the mismatch with this use case runs deep:

IPFS is built around immutable content addressing. Updating a patient record means creating a new block, getting a new CID, and updating a mutable pointer. Significant overhead for a high-frequency append-only log.
The go-ipfs daemon consumes 200-400 MB at rest. A Raspberry Pi 3 with 1GB RAM cannot sustain that.
IPLD graph traversal requires many round-trips per sync. On 600ms satellite latency, this is noted in IPFS's own issue tracker as a bottleneck serious enough to consider "ditching the IPFS DAG sync" in favor of vector-clock-based protocols.
IPFS assumes a semi-open DHT network. A clinic-to-hospital topology is controlled: known nodes, fixed addresses, mTLS identity. DHT discovery is overhead you don't need and a security surface you don't want in a medical deployment.

SQLite with manual sync logic is closest, but it pushes the entire sync problem onto the application: no standard protocol, no connection-drop handling, no ordering guarantees across nodes with drifting clocks.

Here is the comparison across the axes that actually matter:

	ZamSync	CouchDB/PouchDB	IPFS	SQLite (manual)
Memory at rest	~4 MB	~150 MB	~200-400 MB	~2 MB
Offline-first native	Yes	Yes	Partial	No protocol
Delta sync	Version vectors	Partial (rev tree)	No (full DAG)	You build it
ARM static binary	Yes (~9 MB)	No	No	Yes
mTLS built-in	Yes	No	No	No
Connection drop resume	Exact position	Restarts	Restarts	You build it
Clock drift handling	HLC	NTP required	NTP required	You build it

How ZamSync works: the three core ideas

Before going deep, here is a quick map. ZamSync is built on three ideas that compound on each other. Each one solves a specific failure mode:

Failure mode                 Solution in ZamSync
--------------------------   -------------------
Data lost on power cut    -> Write-Ahead Log (WAL): encrypted, append-only, CRC32 per record
Clock drift across nodes  -> Hybrid Logical Clocks: stays near wall time but tolerates drift
Bandwidth wasted on resync -> Version Vectors: exact delta, zero re-transmission

Let me go through each one.

1. The Write-Ahead Log

An append-only log is one of the oldest ideas in databases. When you want durability without the cost of random-access writes, you write everything sequentially to a file. The WAL in ZamSync stores events as fixed-format binary records:

┌────────────────────────────────────────────────────────────────────────┐
│  Record wire format                                                    │
│                                                                        │
│  [4 bytes: magic]  [8 bytes: HLC timestamp]  [8 bytes: sequence]      │
│  [4 bytes: payload_len]  [PAYLOAD]  [4 bytes: CRC32]                  │
│                                                                        │
│  Nonce (96 bits, random per record) prepended when encryption enabled  │
└────────────────────────────────────────────────────────────────────────┘

Every record has a CRC32 integrity check. If the process dies mid-write, the partial record is detected on recovery and truncated. This is the same principle PostgreSQL's WAL uses, just much simpler because we don't need transactions or rollback.

Encryption is ChaCha20-Poly1305 with a fresh random 96-bit nonce per record. ChaCha20 was chosen over AES-GCM deliberately: it requires no hardware acceleration, which matters on ARMv7 Raspberry Pi 3s where AES-NI does not exist.

2. Hybrid Logical Clocks: solving the clock drift problem

Here is a thing that breaks almost every naive sync implementation: clocks drift.

A quick primer on the problem for those not deep in distributed systems: in a system where multiple nodes each generate events independently, you need a way to order those events globally. The obvious approach is to use the node's wall clock. The problem: clocks drift. A clinic offline for three days will have a clock that is slightly off from the hub's clock. Event A arrives with timestamp T+5, event B arrives with timestamp T+3, and now your log is out of order even though B happened after A.

Lamport clocks (Leslie Lamport, 1978) solve causality by using a logical counter that advances on every event and communication. But they lose all connection to physical time, making debugging and forensic analysis painful.

ZamSync uses Hybrid Logical Clocks (HLC), from the 2014 paper "Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases" by Kulkarni, Demirbas, Madeppa, and Avva. The idea: maintain a logical component like a Lamport clock, but keep it anchored close to physical time so values remain human-readable. The logical part only advances beyond physical time when the network requires it.

HLC = max(physical_now, last_seen_hlc) + ticks_if_collision

Normal case (clocks in sync):
  Wall clock:  |--T1-----T2--T3--------T4--|
  HLC:         |--T1-----T2--T3--------T4--|  <- stays near wall clock

Clock drift (clinic B is 2 seconds behind):
  Wall clock B:|--T1'----T2'------------|
  HLC B:       |--T1-----T2------------|  <- corrected by received HLC from A

A node offline for a week with a drifted clock will produce correctly ordered events when it reconnects. The HLC is monotonically increasing within a node and converges to global order across nodes.

3. Version Vectors: knowing exactly what you don't know

The sync protocol is built around Version Vectors. If you haven't encountered them before: a version vector is a map of node_id -> max_sequence_seen. Each node maintains one. When two nodes connect, they exchange vectors and compute the gap.

Hub vector:      { clinic_a: 847, clinic_b: 312, hub: 5001 }
Clinic A vector: { clinic_a: 923, clinic_b: 0,   hub: 4800 }

Gap analysis:
  Hub is missing:      clinic_a events 848..923
  Clinic A is missing: clinic_b events 1..312
                       hub events 4801..5001

The find_gaps function computes the exact missing ranges. Only those are transmitted. No full state transfer, no polling, no "did you get this?" handshakes. Bandwidth usage is proportional to the actual delta.

Here is what this means concretely on a constrained link:

5000-event backlog, 30 KB/s link:

Without delta sync:
  Full transfer: ~18 MB
  At 30 KB/s:   613 seconds = 10+ minutes
  On drop:      start over from zero

With ZamSync:
  Session 1 (cut at 8s): events 1-240 transferred, 24 KB
  Session 2 (resume):    gap vector shows 241-5000 missing
                         picks up at 241, zero re-transmission
  Total overhead:        0 bytes

mTLS and access control

In a health deployment, you cannot let arbitrary nodes connect to the hub. ZamSync uses mutual TLS: both sides present a certificate during the handshake.

The hub generates a CA certificate and signs node certificates for each clinic. If a clinic doesn't have a certificate signed by the hub's CA, the connection is rejected at the TLS layer before any data is read.

Hub CA (ECDSA P-256)
   |
   +-- hub node cert    (signed by CA)
   +-- clinic_a cert    (signed by CA, issued via: zamsync sign)
   +-- clinic_b cert    (signed by CA, issued via: zamsync sign)

clinic_c with a self-signed cert: rejected before any payload is read.

Beyond authentication, ZamSync implements --policy own: when Clinic A syncs, the hub only returns events that originate from Clinic A. Clinic B's data is at the hub but never disclosed to Clinic A. This is enforced at the protocol level, not middleware.

What running it actually looks like

# Hub: generate CA and hub cert, then serve
zamsync keygen /var/lib/zamsync/hub
zamsync serve --data-dir /var/lib/zamsync/hub --bind 0.0.0.0:7700 --policy own

# Clinic: generate keypair, get signed by hub
zamsync keygen /var/lib/zamsync/clinic_a
zamsync sign /var/lib/zamsync/clinic_a/tls/node.csr --ca /var/lib/zamsync/hub

# Push an event and sync
zamsync push --data-dir /var/lib/zamsync/clinic_a \
  --payload '{"patient_id":"BT-0042","event":"registration"}'

zamsync sync --data-dir /var/lib/zamsync/clinic_a --hub 192.168.1.10:7700

# Check status
zamsync status --data-dir /var/lib/zamsync/clinic_a

  Node ID:     clinic_a
  WAL records: 1247
  Last sync:   2 minutes ago  (hub: 192.168.1.10:7700)
  Pending:     0 events unsynced
  WAL size:    124 KB (encrypted)

The binary is a single static musl executable (~9 MB) with no shared library dependencies. Installation on a remote node is one curl command, no package manager, no dependency resolution.

The test that actually matters

I did not want to claim "this works on bad networks" based on localhost benchmarks.

The integration test suite uses Docker Compose and Toxiproxy, Shopify's network condition simulator. The setup:

Hub and clinic in separate containers, Toxiproxy between them.
Link configured: 600ms latency, 100ms jitter, 30 KB/s bandwidth cap.
5,000 events generated on the clinic.
Sync starts.
Mid-transfer: TCP connection cut for several seconds.
Reconnect, sync resumes.

Clinic                Toxiproxy (2G sim)           Hub
  |                        |                         |
  |------ connect -------->|------- connect -------->|
  |<-- version vectors ----|<-- version vectors ------|
  |--- events 1..240 ----->|---- events 1..240 ------>|
  |                        |                         |
  |      [TCP cut injected by Toxiproxy here]        |
  |                        |                         |
  |------ reconnect ------>|------- reconnect ------->|
  |<-- version vectors ----|<-- {clinic_a: 240} ------|
  |--- events 241..5000 -->|--- events 241..5000 ----->|
  |<---- sync complete ----|<----- 5000/5000. 0 dup ---|

Result: all 5,000 events replicated, zero loss, zero duplicates, no corrupted state.

git clone https://github.com/Etoile-Bleu/ZamSync
docker compose -f tests/docker-compose.test.yml up --build --abort-on-container-exit

Memory footprint

Phase 14 benchmark: 5-clinic simulation, all Toxiproxy constraints active.

Hub node:      ~7.8 MB RSS at peak   (5000 events, 5 concurrent clinic connections)
Clinic node:   ~4.2 MB RSS at peak   (1000 local events, 1 outbound sync)

For comparison:
  CouchDB:        ~150 MB at rest
  PostgreSQL:     ~120 MB at rest
  go-ipfs daemon: ~200-400 MB at rest

Under 10 MB is a hard design requirement, not an accident.

What I learned the hard way

Clock synchronization is weirder than you expect. Raspberry Pis that reconnect to a network after being offline sometimes have their clocks jump backward by several seconds when NTP kicks in. If the HLC does not handle the monotonicity invariant during that window, you produce events with timestamps lower than previously issued ones, and the version vector logic breaks silently. I found this the first time I ran the simulation on actual hardware, not on localhost.

Upstream library breaking changes are a real thing. The rcgen crate (TLS certificate generation) changed CertificateParams::signed_by from three arguments to two in version 0.14: instead of passing (node_key, ca_cert, ca_key) separately, you now construct an Issuer struct first with Issuer::from_params(&ca_params, ca_key), which moves the key. This means serializing the CA key PEM before the move, or losing access to it. Forty-line fix, not obvious, failed CI until I read the source.

Release automation and Cargo.lock. The release workflow bumped the version in Cargo.toml via sed, then tried to cargo publish. Failed every time with a "dirty working tree" error. The reason: sed updated Cargo.toml but never ran cargo, so Cargo.lock still had the old version. Fix: cargo generate-lockfile in the release job before committing. Obvious in hindsight.

Docker ARM emulation vs real hardware. QEMU's ARM emulation does not accurately represent CPU scheduling on real ARMv7 silicon. A race condition in the connection accept loop appeared only on real hardware under load and was masked by QEMU's single-threaded emulation. The Phase 14 test is designed to eventually run on real hardware, not just CI containers, for this reason.

Codebase structure

The project is a Rust workspace with four crates:

ZamSync/
├── crates/
│   ├── zamsync-core/       Pure logic: events, HLC, version vectors, port traits
│   │                       No I/O. Tested with fake backends.
│   ├── zamsync-storage/    WAL, SQLite metadata, encryption
│   ├── zamsync-network/    TCP transport, frame protocol, mTLS
│   └── zamsync-testing/    Shared test helpers, in-process test nodes
└── src/                    CLI: serve, sync, keygen, sign, status, push

The architecture is hexagonal: zamsync-core defines port traits, the other crates implement them. Core logic has zero I/O dependencies and can be fully tested without disk or network.

Where this is going

ZamSync is a sync engine, not an application. It does not know what a "patient" is. An application layer sits on top: the thing that renders a patient form, validates data, calls push_event(payload) and pull_events(). That layer is out of scope for me alone.

The vision is to present ZamSync to the Ministry of Health of Bhutan as a building block for exactly this: when a BHU loses connectivity for hours or days, local data survives and syncs cleanly when the link returns. That is a solved problem with ZamSync.

The roadmap:

Phase 15 (in progress): async Tokio runtime for better concurrency on single-core hardware.
Phase 16: mDNS peer discovery for local clinic networks.
Phase 17: conflict resolution primitives (last-write-wins default, application-level merge hooks).
Phase 18: bandwidth budgeting, sync_budget_kbps to leave capacity for actual clinical use.
Phase 21: structured error codes Z1xx-Z6xx with colored CLI output and JSON formatting.

Full roadmap: ROADMAP.md.

References

The core ideas in ZamSync are not mine. I implemented them:

Kulkarni, Demirbas, Madeppa, Avva. "Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases." OPODIS 2014. Springer. The HLC paper.
Mattern, F. "Virtual Time and Global States of Distributed Systems." 1989. Version vectors.
Dean & Ghemawat. "The Google File System." SOSP 2003. Append-only log design.
Rust crates: rustls, rcgen, rusqlite, zstd, tokio, chacha20poly1305. Production-grade, audited.
Shopify's Toxiproxy for network simulation.

Full citations: ACKNOWLEDGEMENTS.md.

Bhutan sources:

How you can help

I can write Rust. I cannot market a project. I want to be direct about what kind of help would actually move this forward.

If you want to give technical feedback:
The areas I am least confident about are the receive() fairness behavior under concurrent clinic connections and whether the Version Vector gap detection handles all edge cases. Open an issue, leave a comment, send a message. Code review is the most valuable thing anyone can offer right now.

If you want to contribute code:
Good First Issues are labeled. The current one is implementing the zamsync setup --hub interactive wizard: keygen, systemd unit installation, and setup checklist in a guided flow. Self-contained, no prior codebase knowledge required.

If you work in health tech, field data systems, or low-resource computing:
I would genuinely like to know if this kind of problem is something you have encountered in other contexts: humanitarian data collection, field research, rural logistics, anything that involves nodes that sync intermittently over constrained links. And if you have any idea how to get this in front of the people at health ministries who actually make infrastructure decisions, I would love to hear it.

A star on the repository also helps more than you might think.

GitHub: https://github.com/Etoile-Bleu/ZamSync

Thanks for reading.

Mathéo

Simulating 2G to build an offline-first sync engine in Rust for rural clinics

Mathéo Delbarre — Sun, 14 Jun 2026 16:11:46 +0000

hey dev.to,

so I am Mathéo, a 2nd year CS student at EPITECH Nancy (France). I want to share a project I have been building for the last few months: ZamSync.

Basically, it is a lightweight synchronization engine written in Rust. It is made for places where the internet is either extremely slow, drops every five minutes, or does not exist at all (think remote areas, Raspberry Pi nodes, offline-first apps).

The exact scenario I had in mind is the electronic Patient Information System (ePIS) of Bhutan. In rural Bhutan, district clinics need to register patients and sync the data back to central hospital hubs. The problem is the network: they often have 2G connections, 600ms latency, and constant cuts.

I looked at existing tools, but they either require a permanent stable connection or need a heavy database engine running on the client. I wanted to build something that:

Works over days of total disconnection.
Recover instantly if the network drops mid-sync (without duplicating data).
Runs on tiny hardware (under 10MB of RAM on a Raspberry Pi).
Keeps everything secure (encrypted at rest and in transit).

Here is the GitHub repository if you want to inspect the code:
https://github.com/Etoile-Bleu/ZamSync

How it works under the hood

The engine is built around a simple principle: append-only logs.

Instead of syncing a database state directly, ZamSync syncs events (which can carry JSON payloads, like patient check-ins).

Here is the technical stack:

Write-Ahead Log (WAL): Events are written locally to an encrypted, append-only file. Each record has a CRC32 integrity check to prevent corruption.
Hybrid Logical Clocks (HLC): Since clinics do not have reliable NTP servers to sync their system clocks, we use HLCs to order events deterministically across different nodes.
Version Vectors: When two nodes connect, they exchange their version vectors (essentially a map of who has seen what sequence number). They compare them, find the exact gaps, and only send the missing events.
WAL Encryption: The log file is encrypted at rest using ChaCha20-Poly1305. A random 96-bit nonce is generated for every single record, and keys can be rotated.
mTLS (mutual TLS): The network layer uses custom mTLS certificates signed by the hub CA. If a node does not have a valid signed certificate, it is rejected during the TLS handshake before any data can be read.

I also implemented a --policy own access control. If Clinic A and Clinic B both sync to the same Hospital Hub, Clinic A cannot download the events submitted by Clinic B. The hub keeps everything, but restricts sync replies based on the client certificate identity.

Simulating the 2G network with Toxiproxy

To verify if this actually works in real-world conditions, I did not want to just write standard unit tests on localhost.

I set up a test suite using Docker Compose and Toxiproxy (an awesome tool by Shopify to simulate network failure). The test setup does this:

Starts a hub node and a client node.
Interposes Toxiproxy between them.
Sets the link to emulate a bad rural 2G network: 600ms latency, 100ms jitter, 30 KB/s bandwidth cap.
Generates 5,000 events.
In the middle of the transfer, the test script cuts the connection completely for a few seconds.
Reconnects and runs the sync again.

In the end, all 5,000 events are replicated with zero loss, zero duplicates, and no corrupted states.

If you have Docker installed, you can run this test yourself:

docker compose -f tests/docker-compose.test.yml up --build --abort-on-container-exit

The codebase structure

The project uses a clean Rust workspace split into 4 crates:

zamsync-core: Pure state logic, events, HLCs, and ports. No I/O.
zamsync-storage: The engine implementation and the WAL filesystem code.
zamsync-network: The network layer, TCP transport, frame format, and mTLS logic.
zamsync-testing: Helper tools and integration tests.

I also cross-compile static musl binaries for x86_64, aarch64 (Raspberry Pi 4), and armv7 (Raspberry Pi 3) so that installing it on remote Linux machines is just a curl command with no library dependencies.

Next steps & feedback

This is my first time building a low-level sync engine in Rust, and I would love to get feedback from other systems engineers.

Does the WAL approach make sense for this use case? Are there edge cases in my Version Vector implementation that I might have missed?

If you want to check the architecture or play with the CLI, here is the link:
GitHub - Etoile-Bleu/ZamSync

Thanks for reading!

Mathéo