DEV Community: Mathéo Delbarre

POC of a silent data-loss bug in Primero, UNICEF's child

Mathéo Delbarre — Fri, 17 Jul 2026 20:40:20 +0000

Two protection officers, one case. A child, unaccompanied, flagged for a possible trafficking risk near a border crossing. Neither officer has a signal. One of them updates the case's risk level. So does the other, a few days later, from a different village, not knowing the first one touched it.

Whichever update reaches the server second just wins. The first one isn't shown anywhere. Nobody gets an error, nobody gets a warning. The only way to know it happened is to go digging through an audit log you had no reason to open.

That's what I found in Primero, the case management system UNICEF uses for child protection and gender-based violence response in conflict zones and refugee camps. Here's how I found it, and where I got it wrong before I got it right.

I build ZamSync.

Primero runs offline in the browser. It queues your edits in IndexedDB and replays them as PATCH requests once you're back online. My first guess was that two people editing the same case offline at the same time would step on each other, full stop. I was wrong about that, and I'd rather say so than quietly bury my first draft.

The PATCH body is a real field-level diff:

export const compactValues = (values, initialValues) => difference(values, initialValues);

Two devices editing different fields on the same case merge fine. One updates a follow-up note, the other updates a risk level, both survive. That's the correct design, and I checked it carefully because I almost reported it as broken.

The gap only opens when two devices touch the same field while both offline. I went looking for the check I expected, something comparing the incoming value against whatever the server currently holds before writing it. There isn't one. Not in the client queue, not in the Rails controller either: the update action loads the record, applies the patch, saves it. No version check in between.

Last write wins. The earlier value isn't gone from the database, Primero logs a RecordHistory row on every save, so someone determined enough could dig it back out. But nothing merges the two edits, nothing flags the conflict, nothing tells either worker to go look. The case just quietly shows the second number, as if the first report never came in.

There's a second, separate problem, QUEUE_ALLOWED_RETRIES is hardcoded to 3. A queued edit that fails to sync three times gets dropped for good, and for anything that isn't an attachment, nothing tells you it happened. A field worker whose connection just won't cooperate for a few days, not a rare situation in the places this runs, can lose an edit with no error and no trace, because it never reached the server in the first place. There's no history row for something that was never saved.

I've read enough writeups where "I read the code and I think there's a bug" turned out to be wrong that I didn't want to stop there. So I built a small proof of concept: zamsync-primero-poc. It takes zamsync-core, unmodified, compiles it to WebAssembly, and runs it against both scenarios next to a faithful copy of Primero's real queue and update logic, built straight from their source. The difference showed up exactly where the code said it would. Same-field conflicts get preserved and ordered instead of overwritten. A sync attempt that fails doesn't get a strike counted against it, it just sits in a durable log until one succeeds, whether that's the fifth try or the five hundredth.

I opened an issue with both findings, the exact files and lines, and a link to the POC. I tried to be careful about two things. I'm not claiming Primero's offline mode is broken in general, only that these two scenarios behave this way, and I said that plainly. And if this turns out to be a known, accepted tradeoff, I said I'd rather understand why than assume I'd found something nobody had thought about. I haven't heard back yet.

The part worth admitting: my first draft of this claimed any two offline edits to the same case would conflict, not just edits to the same field. That's not what the code does. If I'd published that version I'd have been describing a bug next to one that doesn't exist, and muddying the one that does. Rereading the diffing logic narrowed the claim to something smaller and, I think, more useful, a precise report with a file and a line number is a lot harder to wave off than a vague one.

If you work on Primero, or on offline-first systems in general, I'd like to hear where I've got this wrong. And if this kind of thing is useful to you, ZamSync and MenSung are both open.

Mathéo

Checking drug interactions in places where the internet barely exists

Mathéo Delbarre — Thu, 16 Jul 2026 10:31:41 +0000

By Mathéo Delbarre, 3rd year CS student at EPITECH Nancy, France

TL;DR

Problem: medical workers in war zones, refugee camps, and rural clinics have to make drug interaction decisions with no internet, on hardware that predates most currently-supported software. A missed contraindication there is not a bug report, it is a patient at risk.
Solution: MenSung, an offline medication interaction checker in Rust. One static binary, one database file, every lookup fully local.
Constraints: runs on a 10-15 year old laptop (Core 2 Duo, 2-4 GB RAM, slow HDD), lookups under 5ms, database integrity verified on every open.
Data: DDInter interactions enriched with RxNorm, WHO ATC, PubChem, and openFDA drug labels. Every license checked directly, not assumed.
Code: github.com/Etoile-Bleu/MenSung

The last time I wrote here, I told you about ZamSync, a sync engine 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

And then I wrote about what happened after, because I genuinely was not prepared for it:

Mathéo Delbarre

Jun 21

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

#showdev #rust #opensource #beginners

5 min read

I need to start this article by talking about that, because without it, MenSung would not exist.

What your kindness actually did 💝

Since those articles: strangers starred the repo. People forked it to build things I never imagined, like offline-first sync for password managers. KairosOps opened a pull request that fixed a real Windows bug in my code, and I still remember sitting there staring at the notification (I was so happy that someone saw my issue and added a fix 😭). And per-oestergaard left that message in the discussions, the one I keep re-reading, just to say the problem mattered and he was sorry he couldn't help more. He apologized for only being kind. I still think about that.

I said in my last article that the message reminded me why I was building. What I didn't fully understand at the time is that it also changed what I would build next. When strangers from countries you've never visited tell you "this problem is real, keep going", the question stops being "should I keep doing this?" and becomes "okay, what else is broken out there?"

Also, some personal news: I passed my second year! 🎉 I'm now a third-year CS student at EPITECH Nancy. The exams happened somewhere between two pull requests, and honestly, the energy from you all carried me through more of that revision period than I'd like to admit haha.

So this is the next project. It stays in the same world as ZamSync, offline-first software for places where the internet barely exists, but it moves one step further down the chain: from moving medical data to using it at the moment of care.

The problem I couldn't stop thinking about (again)

While researching how clinics in low-connectivity regions actually work for ZamSync, I kept running into a moment in the workflow that scared me more than data loss did.

A patient in a field clinic is already taking one drug. A medical worker is about to give them a second one. The question is simple and brutal: is this combination safe?

If you have internet, this is a solved problem. Medscape, DrugBank, a dozen interaction checkers, all one search away. If you don't have internet, the answer is a paper reference book that may be years out of date, someone's memory at the end of a 14-hour shift, or nothing.

And this is not a small or hypothetical population. Here is what the numbers say:

The WHO estimates the global cost of medication errors at US$42 billion annually, and made reducing medication-related harm its third Global Patient Safety Challenge. Medication harm accounts for roughly half of all preventable harm in medical care.
Drug-drug interactions specifically are a major slice of that: a 2022 retrospective study of ten years of adverse drug reaction reports found that roughly one in six adverse drug reactions was correlated with a drug-drug interaction, and a descriptive analysis of the FDA's adverse event reporting system links DDIs to tens of thousands of emergency visits and around 195,000 hospitalizations per year in the US alone. That is a country with internet and with pharmacists at every corner.
Now move to the settings I actually care about. A study in Zaatari refugee camp in Jordan identified 3,572 drug-therapy problems across 1,533 patients, a mean of 2.33 problems per patient, driven by the lack of structured pharmaceutical care. A review of hospitalized patients in low-resource settings found potential drug-drug interactions in the majority of the patients studied, with the tools to catch them largely absent. And pharmacists working in humanitarian crises have been documenting for years that they are asked to do this job with almost no infrastructure.
Meanwhile, per the ITU's Facts and Figures 2024, 2.6 billion people are still offline, and in low-income countries only 27% of the population uses the internet at all. The places with the least connectivity and the oldest hardware are very often the same places with the least pharmaceutical support.

Read those side by side and the gap is hard to unsee. The best interaction data in the world is sitting on web servers, and the people who need it most are the ones who can't reach it.

Why I didn't just use an existing tool

Same discipline as last time: before writing a line of Rust, I looked hard at what already exists, because "I rebuilt something that already existed but in Rust" is not a contribution, it's a hobby (which is fine! but it's not this).

Web checkers (Medscape, DrugBank, Drugs.com) are excellent and free. They also require internet for every single query. Offline, they are worth exactly nothing.

Epocrates and UpToDate Lexidrug genuinely do offline: you download the database to your phone and query locally. These are serious, professional tools and I want to be fair to them. But look at the assumptions they carry: a reasonably modern smartphone, an app store account to install and update, and a paid subscription for the full feature set. In a refugee camp or a rural health post, the machine that's actually available is more often a donated 12-year-old laptop than a current iPhone with a Wolters Kluwer subscription. And neither is open source, so nobody can audit what the tool does with queries, adapt it, or redistribute it freely to a hundred clinics on USB sticks.

Open source? I searched. I found hospital-specific projects, academic prototypes, and APIs that wrap the same public datasets, all of which assume a server or a connection somewhere. I could not find a single tool that is simultaneously open source, fully offline, and built to run on genuinely old hardware.

	MenSung	Web checkers	Epocrates / Lexidrug
Works with zero connectivity	Yes	No	Yes (after setup)
Runs on a 15-year-old laptop	Yes	Browser-dependent	No (smartphone)
Open source, auditable	Yes	No	No
Free to redistribute (USB, LAN)	Yes	No	No
Cost	Free	Free (online)	Subscription

That empty corner of the table is where MenSung lives.

So I built MenSung 💊

The name keeps the thread from ZamSync: it comes from Dzongkha, the language of Bhutan. Men means medicine, sung means protection. A medical shield.

Before anything else, the disclaimer that also ships inside the tool itself, because in this domain it's not legal boilerplate, it's the truth: MenSung is an offline informational aid. It does not replace professional medical judgement, clinical protocols, or qualified healthcare decisions.

What it is: one statically linked Rust binary, one database file sitting next to it. No server, no cloud, no GPU, no installation procedure beyond copying two files. You type two or more drug names, it tells you every known interaction between them, most severe first:

Between Warfarin & Ibuprofen:

Warfarin information:

The two rules everything else obeys

Before writing much code, I wrote a medical data policy. Two rules came out of it, and honestly they have vetoed more of my ideas than any technical constraint has.

Zero false negatives. If an interaction exists in the data, it is shown. Recall beats precision, every time. An extra warning costs the worker a moment of attention. A missed interaction can cost a patient's life. So there is no clever noise filtering, no "hide minor results", no pagination that quietly drops entries. Code that would remove a true interaction from the output does not get merged, period.

No silent correction. Drug names are hard to spell, and MenSung only accepts International Nonproprietary Names, no brand names, because brands change across borders and INN doesn't. When a typed name doesn't match exactly, the tool refuses to guess:

Ranked candidates, similarity scores, and it waits. There is no code path anywhere in the project where the software substitutes its own guess for what the human typed. In most software, autocorrect is a convenience. In this one, it would be a way to hurt someone.

The .men file

The database is a custom binary format. SQLite would have been reasonable, but I wanted three things it doesn't give me for free: zero-copy reads, a layout I fully control, and a file that verifies itself.

The first version of the format weighed about 28 MB. Then I noticed how absurdly repetitive medical interaction text is: the same risk descriptions reused thousands of times across drug pairs. Version 2 deduplicates every string into a shared string table. Same data, 9.3 MB. The reader maps the file and reads records in place, no deserialization, no intermediate allocations, which is how lookups stay under the 5ms budget on Core 2 Duo class hardware.

The header also embeds a SHA-256 checksum of the payload, verified on every single open. That sounds paranoid until you picture how this file actually travels: on a USB stick, laptop to laptop, through machines nobody maintains. A corrupted medical database that loads anyway is precisely the failure this project exists to prevent. Checksum mismatch, file refuses to open, end of story.

The architecture is the same hexagonal discipline as ZamSync (a workspace of five crates, dependencies pointing one way, the domain crate knowing nothing about files or networks or terminals), just enforced more strictly this time, because on ZamSync I let a couple of boundaries blur early on and paid for it for weeks.

Performance budgets, treated as bugs when violated: startup under 100ms, lookup under 5ms, memory under 50 MB, binary under 10 MB.

Where the data comes from, and the licensing rabbit hole

Interactions come from DDInter, a curated academic drug-drug interaction database. On top of it, a build pipeline enriches every drug from four more sources: RxNorm for standard identifiers, WHO ATC classification, PubChem for chemical properties, and openFDA for the drug's own label facts: boxed warnings, contraindications, pregnancy warnings.

Here is something I learned that I wish someone had told me earlier: check every data license yourself, directly, before you ship anything. I spent an entire evening reading terms-of-service pages instead of assuming, and it genuinely changed the project. DDInter is CC BY-NC-SA 4.0, which means the installed database carries a non-commercial license completely separate from the code's MIT/Apache-2.0 license, and the docs have to say so in plain words. WHO ATC data carries its own restrictions. PubChem is not the blanket public domain everyone on the internet assumes it is (their own site policy says so). openFDA, mercifully, is CC0. All of it is written down in the data policy with sources, because "I think it's fine" is not a licensing strategy for a medical tool.

The enriched database weighs about 27 MB and lives on a GitHub release. First run, MenSung asks permission, downloads it over verified HTTPS with a little progress bar, and that is the last time it ever touches the network. If the download fails mid-way (more on that below...), it falls back to fetching DDInter's public CSV export and compiling a smaller database locally, so even a half-broken connection still ends in a working tool. And you can always skip the network entirely by copying a pre-built .men file next to the binary by hand.

Small things I learned the hard way

Keyboard shortcuts are a real question. The drug-info screen was on F1. Turns out F1 is intercepted by half the terminals and operating systems on Earth for their own help screens, so for many users the key just... did nothing, silently or open Edge's help. Fine, use the letter i then. Except users are typing drug names into a text field, and "Ibuprofen" contains an i. The answer was Alt+I, and the lesson was that even a one-key decision deserves five minutes of thinking about whose hands are actually on the keyboard.

Unit tests don't look at the screen. All my TUI tests were green while the real interface was happily truncating long warning texts at the edge of the box, invisible unless you actually ran it. I found more real bugs driving the binary in a deliberately tiny tmux pane than in any test file. Tests matter, but nothing replaces looking at the thing with your own eyes.

Write the policy before the code. The medical data policy has vetoed shortcuts I absolutely would have taken at 1am. Past me, writing rules in a calm state, keeps protecting the project from tired me. I can't recommend this enough for any project where correctness has stakes.

Where this is going

The honest status: MenSung works today. Releases are built for Linux, Windows, and macOS, the database installs itself on first run, and within the limits of its data and with clinical judgement on top, it answers the question it was built to answer.

What I'm exploring next, carefully: a second, independent interaction source, so important interactions can be cross-confirmed instead of resting on one database alone. The data model already supports multiple sources per claim, that part is built and tested. The hard part turned out to be entirely non-technical.

The dataset I keep coming back to is TwoSIDES, from the Tatonetti Lab. Nicholas Tatonetti is a researcher who now directs his lab at Cedars-Sinai, and back when he was at Stanford he and Russ Altman published a now-classic 2012 paper in Science Translational Medicine on mining the FDA's adverse event reporting system for drug effects nobody had catalogued. TwoSIDES came out of that work: over 3,300 drugs and 63,000 combinations connected to millions of potential adverse reactions, all derived from real-world reports rather than curated literature. It's a genuinely different lens on interactions than DDInter, which is exactly why cross-confirming against it would mean something.

The problem is that I could not determine the license. The lab says the resources are free and open for academic use, which is lovely, but "academic use" and "an open source tool redistributing a compiled database to clinics" are not obviously the same thing, and I found different statements in different places. And the site itself notes the data is quite a bit out of date. So instead of guessing, which is precisely the mistake I already promised myself I would never make with medical data, I wrote to Nicholas Tatonetti directly to ask him what the license actually permits. I'm waiting to hear back. I'd rather ship one clean, well-licensed source than three legally ambiguous ones, even if it means the feature waits.

Further out: dosage support, and possibly translations of the clinical texts, since INN names are already international but the warnings are currently English-only.

How you can help

Same honesty as always: I can write Rust, I cannot market a project, and this one needs different kinds of eyes.

If you're a pharmacist, doctor, nurse, or have done medical work in a low-resource setting: you are the person I most want to hear from. Does the severity display make sense? Is the name-confirmation flow safe enough? What would you never trust a tool like this to do? Ten minutes of your criticism is worth more than a hundred stars to me. My email is matheo.delbarre@epitech.eu and I answer everything.

If you write Rust: the repo is open, the architecture docs are real, and I merge quickly. The fuzzy matcher and the binary format reader are the areas where a second pair of eyes would matter most.

If you know an interaction dataset with a clear, redistributable license: please, please tell me. This is currently my biggest bottleneck and it's not even a technical one.

And if you just want to help in 5 seconds: a star on github.com/Etoile-Bleu/MenSung genuinely matters, it's how the next stranger decides the project is worth their five minutes. I learned that from all of you last time.

References

Problem sources:

Data sources used by MenSung, with licenses documented in MEDICAL_DATA_POLICY.md:

DDInter (CC BY-NC-SA 4.0)
RxNorm, US National Library of Medicine
WHO ATC classification (via RxClass)
PubChem
openFDA (CC0 1.0)

Thank you for reading. And thank you, really, to everyone who starred, forked, fixed, commented, and wrote after the last articles. I said the response changed how I think about what I'm building. Here is the proof: it built the next project. 💙

-- 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