go-ds-crdt VS Go IPFS

I forgot: key-value store using MD-CRDTs was implemented here: https://github.com/ipfs/go-ds-crdt

The trickiest part was not the CRDT, but the DAG traversal with multiple workers processing parallel updates on multiple branches and switching CRDT-DAG roots as they finish branches.

In https://github.com/ipfs/go-ds-crdt, every node in the Merkle DAG has a "Priority" field. When adding a new head, this is set to (maximum of the priorities of the children)+1.

Thus, this priority represents the current depth (or height) of the DAG at each node. It is sort of a timestamp and you could use a timestamp, or whatever helps you sort. In the case of concurrent writes, the write with highest priority wins. If we have concurrent writes of same priority, then things are sorted by CID.

The idea here is that in general, a node that is lagging behind or not syncing would have a dag with less depth, therefore its writes would have less priority when they conflict with writes from others that have built deeper DAGs. But this is after all an implementation choice, and the fact that a DAG is deeper does not mean that the last write on a key happened "later".

The idea of DAG-embedded CRDTs is far from new and was introduced here:

https://arxiv.org/abs/2004.00107 (I'm among the authors)

Unfortunately, the verification that the author proposes (not accepting new updates until the dag below is verified) will need a lot of caveats for real world usage.

Currently we use these CRDTs for a key value database of 40M+ keys in a deployment of ipfs-cluster, which uses https://github.com/ipfs/go-ds-crdt .

Not 100% the thing, but potentially related work in this area:

https://github.com/ipfs/go-ds-crdt

(See link to paper, and links to other projects in it, like OrbitDB).

nice/renice isn’t what it used to be[0].

Bandwidth limiting is not built in[1].

[0] - https://stackoverflow.com/questions/10342470/process-nicenes...

[1] - https://github.com/ipfs/go-ipfs/issues/3065

For me, https://github.com/ipfs/go-ipfs/issues/9044 is the main blocker atm and https://github.com/ipfs/go-ipfs/issues/2167 is still around and annoying.

It makes me wonder if you use the IPFS FUSE mount and symlink an IPNS address of files that you want to sync if it would be read by Dropbox.

I'm using the IPFS fuse mount to load mine into Plex/Jellyfin. It's nice that I can load a movie into a virtual directory on IPFS and my home and remote servers get updated automatically. (when I update my IPNS) So you could run an official solidaritycinema IPNS address that people load into their Plex as a library.

Maybe tangentially related, I've been interested in IPFS as a network medium. ( Using the IPFS fuse mount ) Rather than syncing the entire file it syncs the Library list. When the Plex server makes the request for the file, IPFS negotiates the download. It makes it more like Netflix.

I've been messing with Plex + IPFS and I think it's pretty cool. The IPFS FUSE Mount gives IPFS network access to Plex as just a regular filesystem. To keep it private within my family I'm using a Private Swarm.

"Implement bandwidth limiting" https://github.com/ipfs/go-ipfs/issues/3065

Going on six years now. You can use external tools (like "trickle") or your OS knobs.

So my plan is to setup plex on a relative's Raspberry Pi so that it works off the IPFS mounted network directories in the same way. They'll have a virtual library that takes basically no memory on their Pi unless they request a video, then it'll start caching to their machine.