Commit Graph

10 Commits

Author SHA1 Message Date
Alexis Sellier 489370dcbd
cob: Add ability to add more parents to change
This allows change commits to have more than one parent that isn't
part of the DAG.

We can use this to create dependencies towards git objects such as
commits, in the case of patch actions.
2023-04-14 13:22:10 +02:00
Alexis Sellier e584bd6c1c
crypto: Use `ssh-key` crate for signatures 2023-02-17 11:53:46 +01:00
Alexis Sellier 86e56d2053
cob: Move graph sorting to `evaluate` function
This avoids passing the sorted items as an iterator.

Signed-off-by: Alexis Sellier <self@cloudhead.io>
2022-12-28 19:24:22 +01:00
Alexis Sellier 70260236b2
cob: Simplify graph builder
Since we use `Oid` as the primary graph index, there's no need to keep
a separate index.

Signed-off-by: Alexis Sellier <self@cloudhead.io>
2022-12-28 18:01:24 +01:00
Alexis Sellier 2f07b76fcb
Switch to our own DAG representation for COBs
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.
2022-12-28 13:34:17 +01:00
Alexis Sellier dd7052926a
cob: Remove `author` from `Entry`
It was no longer used.

Signed-off-by: Alexis Sellier <alexis@radicle.xyz>
2022-12-01 12:05:44 +01:00
Alexis Sellier 5a47023ac0
cob: Change history type to a string
Signed-off-by: Alexis Sellier <alexis@radicle.xyz>
2022-12-01 12:05:44 +01:00
Alexis Sellier e83d47ff45
cob: Compute implicit monotonic clock on changes
Signed-off-by: Alexis Sellier <alexis@radicle.xyz>
2022-12-01 12:05:44 +01:00
Alexis Sellier 1a5b68c2b3
cob: Parametrize `Change` with single signature
Signed-off-by: Alexis Sellier <alexis@radicle.xyz>
2022-12-01 12:05:44 +01:00
Fintan Halpenny f3c4a53e1e
radicle-cob: port collaborative objects
This is a minimal port of the collaborative objects code from
radicle-link[0].

A `CollaborativeObject` is made up of a `History` of `Change`s that
are expected to be stored in a `git` backend.

The library exposes a CRU series of functions `create`, `get`, `list`,
and `update`.

This implementation differs, to previous one, in that it does not
assume any kind of identity system -- its only assumption is that
identities have an identifier and can be addressed in the `git`
database. This means that it does not require an `author` to be passed
in and it only uses the `resource` (previously `authorizing_identity`)
to store its content-address in the `Change`.

It also foregoes any caching to simplify the port and not make any
early optimisation assumptions.

[0]: https://github.com/radicle-dev/radicle-link/tree/master/cob

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
2022-11-04 16:11:18 +00:00