Skip to content

Atomic over mesh #1137

@joepio

Description

@joepio

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. Does pathfinding, E2EE. Has 3 types of connections (including direct and broadcast).

We'll need some dashboard / UI to manage the reticulum side of things. See the nodes, manage announces, maybe manage the mesh. I think adding a network or mesh settings panel on the left side. It should users show which interfaces are operational, which are not (e.g. Wifi, BTLE).

As of now Reticulum(-rs) doesn't support wifi halow I think, but I'm keen to find out of we can change that. (related message)

p2panda

Public key addressing, append-only log, built on iroh. Resources tightly linked to a user. Signatures like commits. Unclear to what extent it does support a true, large-scale mesh, since it uses gossip / broadcasting.

NextGraph

Although NG doesn't yet have p2p or mesh, @niko-ng has ambitions towards this and its architecture seems pretty well suited for a mesh network. We're still exploring if we can use NG in Atomic #1012. We could also explore using Reticulum underneath NG.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions