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:
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 I didn't even know existed: SQLite paths on Windows were getting a leading slash prepended, turning C:/path/db into /C:/path/db. It was a real bug, properly diagnosed, cleanly fixed with a #[cfg(windows)] guard and a unit test that covers both platforms.
He found the bug. He traced it. He wrote the fix. He opened a pull request.
I'm 19 years old and someone just contributed to my project.
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
Top comments (0)