2f07b76fcb
We're using petgraph to encode an operation based CRDT (each graph node
is an operation) as a DAG, and one of the important things to ensure
is that the final state is not influenced by the order of concurrent
operations. In this case a concurrent operation would mean two potential
graph traversal orders, as there's no direct edge between the two
concurrent ops. This is essential a "partial order" of operations.
To be able to test this, we'd want some kind of control over how
neighbors are iterated over I guess, when there's more than one possible
sort order. Say we have a graph like this:
┌────────b◄─────┐
▼ │
a d
▲ │
└────────c◄─────┘
There are two possible topological traverse orders: [a, b, c, d] and [a,
c, b, d]. Having a way to go through these different orders would
be super handy.
One option would be to allow random order traversal. This would allow us
to test all orders by running the test enough times to likely test all
permutations.
Since petgraph doesn't support this, we implement our own simple DAG in
`radicle-dag`, which implements random-order topological orders.
For now, we don't make explicit use of these improvements, we simply
replace the underlying graph with our own.
|
||
|---|---|---|
| .github/workflows | ||
| .nix | ||
| radicle | ||
| radicle-cli | ||
| radicle-cob | ||
| radicle-crdt | ||
| radicle-crypto | ||
| radicle-dag | ||
| radicle-httpd | ||
| radicle-node | ||
| radicle-remote-helper | ||
| radicle-ssh | ||
| radicle-tools | ||
| .dockerignore | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| DCO | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| build.rs | ||
| docker-compose.yml | ||
| rust-toolchain | ||
README.md
❤️🪵
Radicle Heartwood Protocol & Stack