Да. Сиблинги так сортируются.
Там становится уже неважно, кто что раньше/ позже получил.

потому что я не нажимаю ссылки! :)

в описании RGA на replicated.cc ничонепонятно!

офигенно. RGA ето выглядит _очень_ просто

Скорее CT. В RGA не было ничего про дерево. Но само название более удачное, array.

А в чём принципиальная разница?

На первый взгляд эти все yarn и weft это просто представления атомов в CT. Yarn это атомы сгрупиррованые по site и отсортированые по времени внутри группы, weft фильтр поверх yarn.

Я вобщем перефразирую:

У меня есть виртуально бесконечное число распределенных append-only массивов, в которые другие участники могут асинхронно добавлять значения. Что будет проще реализовать и какие у этого будут сайд эффекты?

На всякий случай: терминология немного поменялась, атомы это теперь одно из INT, UUID, STRING, FLOAT.
То, что называлось в 2010 атомами, теперь опы (операции).

Опы состоят из атомов...

При частичном порядке, append only имеет некоторые нюансы

Довольно нетривиальные.

в данном случае append-only в том смысле что элементы только добавляются, но не удаляются или обновляются.  grow only? я так понимаю что строгий порядок слишком сложно гарантировать, но меня то как в CT порядок обеспечивается устроит

самое главное чтоб когданибудь у всех участников случилось одинаковое представление этого массива

Так, попытаюсь собрать в кучу:

1) Всё операция. Проиграв операции мы можем собрать виртуальное отображение массива

2) Есть структура Id, состоящие из двух частей: случайного числа Site и какого-то возрастающего числа Clock.

3) Есть структура Op, состоящая из трех частей: OpId сделанный из Id, CauseId сделайнный из Id и Value сделанный из чего угодно

4) Каждый участник имеет какой-то случайный Site и Clock который начинается с 1.

5) Каждый участник хранит операции в массивах, где в массиве могут быть только операции одного учатсника (OpId.Site == Site), он-же yarn

6) Когда участник совершает какую-то операцию с массивом, он собирает Op из OpId из своего Site и Clock + 1. В случае если это первая операция с массивом то CasueId == OpId, если это не первая операция с массивом, то CauseId будет равен самому старшему OpId из всех массивов операций (?). Clock становится clock + 1, Op добавляется в хвост своего yarn и рассылается остальным участникам

7) Когда участник получает операцию другого участика, он добавляет её в хвост соотвествующего yarn и по необходимости обновляет виртуальное отображение массива

Достаточно точно. Только в 6) cause (он же ref) это id предыдущего элемента на момент вставки (т.е. "вставить справа от ref")

а, точняк, да

в этом случае получается есть ещё какой-то глобальный yarn, где все операции упорядочены по [clock, site] и ref будет относительно операции там?

или в отображении у каждого элемента есть op который привёл к его появлению?

Ref не зависит от локальных порядков, это UUID.
Давайте приватно, а то отписываться сейчас начнут.

Чего уже там. Вы же по делу говорите :-)