-->
Peer to Peer Groceries
Peer to Peer Groceries
2026-08-06
:: 19 min read ::
View<br>Source
#Distributed Systems,<br>#No Coding,<br>#Rust
Table of Contents
Introduction
Background
Short Note on the Full Project
CRDTs
Resolution Strategies
A Bit of Code
Recap
Networking
Message Types
Message Handling
Lessons Learned
Future Changes
Closing
Footnotes
Introduction
For some time now I've been wanting to learn more about distributed systems and Conflict-free Replicated Data Types<br>(CRDTs) and even though I've read a bit about both of these, I never built anything that utilized them.
Thankfully in my infinite wisdom (and mostly boredom) over the summer, I found an excuse to build something that<br>uses both of these: a glorified todo list peer-to-peer grocery list tracker!
Background
Me and my sister have been doing grocery shopping together recently and in an effort to buy everything<br>we need faster, we usually split up and collect whatever we need in parallel.
The "problem" with this is that our<br>grocery lists so far have been WhatsApp messages we each optionally copy paste in our phones' pre-installed note apps.<br>Because we never actually plan out who should buy what, we waste precious seconds figuring out what items we each<br>collected and what we still have to buy. Technically we could use something like Microsoft's ToDo which from what<br>I remember does let you share the "tasks" with someone else but that is:
boring
has too many bells and whistles we don't need/want
very annoying to set up (probably takes like 5 whole seconds to share a list)
probably needs accounts
needs an internet connection
Not sure if this is a common occurrence but half the supermarkets I go to either have horrible reception, horrible WiFi<br>or both.<br>At one point last year I saw Bitchat and thought it was a cool idea so naturally I figured Bluetooth would solve my<br>connectivity issues.
The other 4 bullet points were easily solved by making a barely-functional mobile app over the<br>course of two weeks or so because engineers like nothing more than looking at a pretty decent wheel someone else<br>created and thinking "I could reinvent that but worse" and then doing just that!
At the time of writing this, I'm waiting on the maintainer of the BLE crate(s) I wanted to use to respond to<br>an issue I've been having (I think it might be on the crate's end but we'll see) so right now I am not actually<br>using BLE but mDNS!
This should be near-trivial to change in the code1 but it is worth pointing out because, though<br>I haven't tested this, I doubt that mDNS is allowed in public networks, like supermarket WiFi. So technically the<br>app is kinda useless at the moment, obviously I made it for fun so I don't care but yea.
Short Note on the Full Project
Even though this had to be a mobile app, I am actually very uninterested in UIs and as a result I ended up vibe coding<br>most of that. I don't think it is too interesting to talk about but the code is public if you want to take a look.
Hopefully by the time anyone reads this I'll have actually added READMEs explaining how to build and run it but if not,<br>this is what the app looks like now running on my Android phone.
You can add/edit/remove items and mark them as bought or not. The save button serializes your list to disk so you can<br>make it at home, close the app, then open it at the supermarket and be ready to go.
CRDTs
Before we talk about any of the networking, I think it makes sense to briefly talk about CRDTs.
I feel like a lot of people who might not know about CRDTs have probably heard of multi-threading and if you've<br>heard of multi-threading you probably know that mutating the same thing, at the same time, from multiple threads<br>is a big no-no.
I think, in some cases at least, it makes sense to think of distributed systems as a multi-threaded<br>program where instead of different threads, code is running on different devices. As such, it shouldn't be shocking<br>that you can't easily have two devices maintaining some shared state between them which they can both edit<br>concurrently. Unlike a thread-safe object, however, (think a concurrent hashmap), safety & correctness are not achieved<br>via locks but via eventual consistency, an Operation Log (oplog) and algorithms for "merging"/applying operations to<br>our state reliably.
For the oplog to make sense, it needs to follow some order. Naively, one might consider using time - if event A<br>happens earlier in time than event B then obviously A . The problem is that it is not actually that simple;<br>you've probably noticed clock drift, especially in offline devices such as a wristwatch. Even if we know<br>that all our peers' clocks are correctly set (and no one is "cheating" by rewinding theirs to gain precedence!),<br>clock drift can eventually still put events out of order.
Obviously this doesn't work, what we need is a causal relation (A causes B therefore, A proceeds B) and this is where<br>the Vector Clock comes in! Now although it sounds terribly fancy,...