User-Agent: Cyrus-JMAP/3.3.0-248-gcd102cb-fm-20200901.001-gcd102cb9
Mime-Version: 1.0
Message-Id: <bab08df6-be8e-47bd-a254-7b86c41a9b47@www.fastmail.com>
In-Reply-To: <87pn75xtx4.fsf@euandre.org>
References: <d78064d2-5441-4275-96d9-463a08dfd7a9@www.fastmail.com>
 <87ft81zvi0.fsf@euandre.org>
 <9e513706-7ebc-4a40-8e5e-a5f94d84bc77@www.fastmail.com>
 <87pn75xtx4.fsf@euandre.org>
Date: Wed, 02 Sep 2020 08:12:45 +1000
From: "Seph Gentle" <me@josephg.com>
To: EuAndreh <eu@euandre.org>, ~euandreh/public-inbox@lists.sr.ht
Subject: Re: Making a database
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 2, 2020, at 3:56 AM, EuAndreh wrote:
> > You kinda gave a good description of them in your post already. They=

> > work by requiring all peers to resolve concurrent edits to an object=

> > the same way. That could be last-writer-wins (based on time stamps
> > like you said in your article). Or it could store all conflicting
> > versions together to be resolved by the next reader (Eg riak). Or it=

> > could do something more clever (like merge changes using automerge o=
r
> > y.js or the like). Git is sort of a CRDT - it=E2=80=99s just it=E2=80=
=99s 3 way merge
> > algorithm is a bit of a dogs breakfast as far as these things go.=20=

>=20
> My ignorace is really on the applicability of it. The "store all
> conflicting versions together or to be resolved by the next reader"
> sounds like what I'm thinking about, so maybe I'm trying to re-invent
> CRDTs after all.
>=20
> I've just bumped the priority of this topic to better understand those=

> nuances.=20

This is worth watching if you haven=E2=80=99t seen it. Martin is at the =
forefront of the field - but this gives you a sense of where the researc=
h tech is at:

https://martin.kleppmann.com/2020/07/06/crdt-hard-parts-hydra.html