Atomic over mesh #1137
Description
In the past few years I've been increasingly fascinated by local-first, p2p, CRDT protocols. At this point, Atomic is none of these things. But maybe it could be.
Right now Atomic relies heavily on HTTP. This is of course very fast and has insanely high coverage, but it's also very fragile. It only works if there is an active internet connection between the client and the server. If the user is offline, or the server has some issue, you can't use or edit the data. There is no way to fetch resources from peer clients (who might have the exact resource that you need), and there is no way to make changes to your data if your server is offline.
In an ideal world, you could ask any node in the area (even if the main internet is down) "hey do you have resource X?" and it could send that to you. We can't use HTTP urls for this, because the node could "lie" about what the resource is / make changes to it. This is why we could use content addressing, like IPFS. However, this leads to STATIC resources that can't change over time. I've got an idea that could fix this issue: use the first commit signature as the identifier. This 'root commit' contains information about the creator which can be used to verify who made the change. Since every subsequent commit contains a link to the previousCommit, we get a chain of edits, each one verifying the previous one. It's like a blockchain ledger without the crazy mining waste.
The question then is: how do you get data from other machines in a network? I'm exploring mesh technologies, and right now my main contender is:
Reticulum
This mesh transport layer works over wifi, lora, serial port and way more. There is a rust implementation. I'm playing around a bit right now.