Braid 101— Call for Topics!

[Michael Toomim]

It's been a month!  I hope your winter rocked.  What have you been noodling on?  Want to present it?

https://braid.org/meeting-101

Braid happens Monday at 1:00pm Pacific!

[Michael Toomim]

Today (in 3 hours), Christian Tschudin will present on some of the surprising complexities that arise when implementing some basic CRDT features over append-only logs:

Management of Bilateral Session State Over Replicated Append-Only Logs

I will present on the protocol between two parties to create, run and destroy a shared CRDT object, over append-only logs. This requires establishing convergent session state between the parties. You would think that this should be simple. It can't be complex, right? Especially if you assume a network with reliable in-order delivery?

However, I will show how this simple requirement actually brings about a case of Finite-State Machine Vertigo. Specifically, the FSM needs at least 16 states—and has a surprisingly irregular graph.

We still have some room on the agenda. Reply here, or edit the page, if you'd like to discuss something.

Michael

[christian...@unibas.ch]

Thanks to all who attended or watched the recording!

One interesting point of Braid-101 was the "but hey, this is a CRDT - it
has no merge conflicts" moment.

I circled this back into my group and here is what we came up with, it's
mostly Erick Lavoie's assessments and I wanted to share it with you:

a) The presented shared session state management protocol is "just sync"

b) The consequence of a): because the session state mgmt protocol is
"just sync", it can't be a CRDT because CRDTs are meant to be sync-free.
Sync-free means that you can continue to work on your local replica of
the shared data without dependency on others' actions.

c) As a proof: with the presented shared session state, there is no way
for the initiator to go into "open" before the responder has accepted
the invite - the initiator is blocked on its peer (or can abandon the
invite, of course).

d) Another way of phrasing it: there are monotonic protocols, like the
presented session state sync, where progress always is in one direction
(e.g., invited->open->finished, invited->canceled->finished). But not
all monotonic protocols are CRDTs.

e) Still, the sync is not to be underestimated: it is needed to
establish consensus on the existance and destruction of a CRDT (i.e.,
game instance, editing session). All invariants that come with CRDTs
hold while there is consensus that a CRDT data structure exists, but
typically not before and not afterwards.

Best, c

> --
> You received this message because you are subscribed to the Google Groups "Braid" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> braid-http+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/braid-http/AF83B8C0-0C56-48FB-B03B-D8D26E76E151%40gmail.com.
>
>