cachapa / crdt Goto Github PK

Hi, I'd really love for this to become a generic CRDT package offering multiple types, not just maps.
What do you think about having a very generic Crdt interface that can be implemented by loads of types? This package could provide several default types, but over time, more types could be added and developers could create custom CRDTs.

For example, consider an interface like the following:

abstract class Crdt<T extends Crdt<T>> {
  const Crdt._();

  /// Merges [this] and an [other] instance of type [T].
  /// If there are instances a, b and c of type T, these conditions should hold true:
  /// - a.merge(a) == a
  /// - a.merge(b) == b.merge(a)
  /// - a..merge(b)..merge(c) == a..merge(c)..merge(b)
  void merge(CrdtContext context, T other);
}

// Implementing like this:
class SomeCrdtType extends Crdt<SomeCrdtType> {
  void merge(CrdtContext context, SomeCrdtType other) {
    ...
  }
}

The CrdtContext could contain global information shared by multiple CRDTs like a UUID of the current client and maybe UUIDs of other clients.

Several types could then implement this interface:

• a map-like type like the one already existing
• monotonically increasing counter
• set with supporting only adding items
• win over delete set
• BigSet
• Strings
• ordered lists
• …

I'd love to hear your opinion on this. 😊

Hi! Thanks for this library. I've got a question about this library's Hlc class.

From what I understand about HLCs, they can deal with the pathological case where one node sets the system time to point in the future. I was reading this article where the author states the following about the use of HLC in a CRDT:

[A HLC] does however make the following guarantees:

1. All events created on a single machine will be correctly ordered with respect to each other (even if the wall clock jumps back a second or is otherwise squirrely).

2. Once machine A sends events to machine B, all events subsequently created on machine B will be ordered as after those events from machine A. So if A sets their clock one day ahead, makes some changes, and sends them to B, B will still be able to make changes even though its own wall clock is 'behind'.

Using this library, I wrote the following code:

import 'package:crdt/crdt.dart';

void main(List<String> arguments) {
  final local = MapCrdt('local');
  local.put('name', 'Misha');

  final tomorrow = DateTime.now().add(Duration(days: 1));
  final hlc = Hlc.fromDate(tomorrow, 'remote');
  final futureRemoteJson = '{"a":{"hlc":"$hlc","name": "Daniel"}}';

  local.mergeJson(futureRemoteJson);
}

Which yields:

Unhandled exception:
Clock drift of 86399977 ms exceeds maximum (60000)
#0      new Hlc.recv (package:crdt/src/hlc.dart:95:7)

Upon closer inspection, the code in Hlc.recv does not appear to match the one in the blog post mentioned above, and thus cannot deal with the pathological case of a future clock. Is this an implementation error?

Please let me know if I misunderstood CRDTs, HLCs, or this library in any way. This is brand new territory for me.

Thanks for the package! I'm curious if you had any thoughts on adding other Shared Types, like Lists, Text, etc. I'd be happy to help contribute where possible as well!

Firstly, thanks for all your work on crdt, it's associated packages, and tudo. It's a rich tapestry of code to learn from as somebody exploring Flutter and Dart.

Is the API for crdt or any of the sub packages (hive_crdt, sqlite_crdt) documented somewhere?

I'm new to the whole Dart ecosystem so maybe I'm missing something obvious. I'm familiar with CRDTs but I'm struggling to see how all the pieces you've built fit together. I've checked out the examples that I can find, and spent some time looking into the tudo code. But I'm still not quite able to see the bigger picture.

What kind of crdt this repository implement?
Does it support json type like Automerge ?