Пока неохотно, но коммиты расползаются по нодам. Бесплатно получаем зачаток чата, чем gossip не чат. по сути чем сплетни отличаются от трёпа? Учитывая, что распределенный сторейдж идёт в комплекте, можно уже запиливать еще один распределенный мессенджер. И везде сплошное UDP!

code review с fixme:
делай раз:

cat .fixme/config
...
fixme-prefix     REVIEW:    review
...

делай два

cat .fixme/config
...
[ fixme-report review json
  (render builtin:microstache report-wip.tpl)
  (post builtin:columns | 10 10 8 12 _)
  (query tag:REVIEW:)
]
...

делай три

  -- REVIEW: no-time-to-die
    просто удаляй пира из вайтлиста,
    если он в блэклисте

  unless (Set.disjoint blkeys wlkeys) do
    die "whitelist and blacklist intersect"

делай четыре:

[dmz@expert:~/w/hbs2]$ fixme report review
Da2nChoaL9 []         REVIEW:               no-time-to-die

et voila:

Со ссылками не очень прикольная ситуация. Ссылка - это некая глобальная идентифицированная мутабельная переменная в распределенной системе, состояние которой определяется неким консенсусом. Ну, например, простой тип консенсуса - когда писатель только один и у ссылки есть версия. Тогда все участники сети просто сохраняют последнюю известную им версию ссылки и её же отдают, когда их попросят. Это один самый частный случай. В идеале, поскольку система просто представляет собой сетевой уровень, хочется, что бы состояние ссылки и тип консенсуса определялся внешним приложением. Для этого состояние ссылки надо просто пропихивать туда (во внешнее приложение), как есть. Если мы просто в онлайне просто слушаем и пересылаем эти самые ссылки, вернее, транзации об изменении их состояния - то всё просто работает — ссылку получили, пруфы (подпись, например) проверили, если ок - переслали. Вопрос, что делать если pull модель - т.е кто-то к нам приходит и говорит - дай лог для ссылки. Во первых, если ссылка нам не принадлежит - мы лог не можем подписать той же подписью — можем только переслать его как есть, т.е лог будет не содержимого транзакций, а самих (подписанных) транзакций. Неудобно, но, допустим, ок. Во вторых - лог может быть дюже здоровенный, а как-то фильтровать мы его не можем, мы же не знаем, что там внутри в транзах. Допустим, сделать запрос "дай N последних транз" - а что такое "последних" ? Последних принятных в хронологическом порядке? Последних N принятых в хронологическом порядке, упорядоченных по хэшам? Понятно, что можно сделать как-то. Но хочется сделать как-то логично и минимально, что бы несколько каких-то рандомных частных случаев на уровень протокола

Конкретно для гита с одним писателем - стейт это просто транзация с максимальным номером и ссылкой на merkle дерево состояния (head репозитория [состояние всех бранчей + транзитивное замыкание коммитов]). Вопрос в том, что для разных приложений понимание стейта может быть разным, вопрос какие примитивы должны быть в самой системе

Короче, для гита и случая, когда нода hbs2 в онлайне - всё работает с довольно общим механизмом. Теперь надо решить для случая, когда нода была в офлайне / стартует в начальный момент времени и ничего не знает про ссылку. Самое простое - попросить соседей переслать то, что у них есть. Конкретно это означает, что 1) рассылаем всем нодам запрос "проиграй свой лог транзакций 2) они плюют в ответ все транзы, которые у них есть - если есть сто, то сто. Если тысяча, то тысячу (UDP пакетов), если сто тысяч - то сто тысяч. Ну чот такое себе. Что же делать

Как работает git clone hbs2://...

#hbs2 @offgrid Удалось, кстати, это всё запустить на raspberri pi, что странно для хаскеля с TemplateHaskell. Видимо ноука шагнула за пять лет далеко вперёд. Неожиданно

push в пустую (новую) ссылку

фиг знает, стоит ли это постить сюда, но а куда еще, с другой стороны

Не бывает такого, что бы какой-то кусок софта взлетел. Он всегда всполз. Но тем не менее. Перед текущей фазой разработки от протоколов была откручена криптография. Соответственно, хочется понять, как бы её туда грамотно вкрутить обратно. Поскольку система не привязана ни к каким "доменам", сертификаты тоже отпадают. Пиры общаются между собой, подтверждают владение своими публичными ключами (подписи) и на этом этапе можно согласовать ключи шифрования и весь дальнейший обмен шифровать. Блоки еще сами по себе могут шифроваться, это сейчас есть. Вопрос вот в чем — незашифрованный протокол обмена ключами не палево ли это. Что можно делать: 1) запоминать где-то ключ пира и дальше использовать его 2) забить и оставить протокол согласования ключей незашифрованным. Запоминать ключи пира это в принципе появляется какой-то стейт, который надо обрабатывать, там будет что-то теряться, что-то пртухать и т.п. Неизящно. Какой можно изящный ход придумать?

README добавил
https://github.com/voidlizard/hbs2/blob/master/README.md

По поводу забора блоков по http. Их забор можно делать в общей очереди, тогда те ноды, которые поддерживают http будут по нему и отвечать (короткими блоками) и блоки эти будут запрашиваться у рандомных пиров. Это, типа, true. Сделать отдачу всей портянки одним вызовом - лехко, такая команда в cli уже есть - hbs2 cat хэш парсит объекты и отдаёт поток данных целиком. Но. Это ж нарушение децентрализации и способ абьюзить конкретного пира. Что же делать?

#fixme Сейчас в fixme собирает записи по всем известным объектам репозитория, а вот лог состояния берётся просто из файла. Раз появляется файл, то он может начинать меняться по бранчам, его надо мержить, периодически он ломается, у всех может быть разным. Короче, при большом количестве бранчей это будет неудобно, уже начало. Хотя и работает. Так вот. Его можно брать не из файла. Его можно брать из множества блобов для этого файла, упорядочивать по 1) id самого fixme 2) дате коммита - у нас получается линейная история для каждого fixme это раз, её можно хранить в merkle tree и не обрабататывать дважды это два 3) история становится глобальной это три и это удобно — теперь на каком бы ты бранче не поменял статус - у тебя и у всех, кто твой бранч стянул будет одинаковое состояние, и не надо никаких ограничений на формат накладывать - я хотел сделать fixme/log связным списком состояний, но пожалуй, это так себе была идея, можно лучше. Остаётся сам файл .fixme/log , конечно. Его хоть и можно обнулять время от времени, всё равно это будут забывать и будут писать туда разное, отчего в итоге будут мерж конфликты. Надо еще немного подумать, что с этим сделать. А кроме того, можно задействовать hbs2-core для меркл-деревьев, написать бэкенд для записи этих деревьев в sqlite и посмотреть, что из этого выйдет -- тут не критичное применение, больших блобов не будет, базу сильно не раздует

git это первый широко известный среди меня CAS, хотя, кажется, до гита мы использовали bzr, но я не помню, был уже гит на тот момент или нет. интересно, кто до dvcs применял CAS-ы и есть ли по этому поводу какие-то пейперы. У них же очень прикольные свойства, интересно бы их знать все, а не обнаруживать в процессе работы

#fixme обновил fixme. теперь он учитывает все версии файла-лога транзакций. со всех веток со всех версий. Поэтому первый раз будет работать долго. но теперь, даже если кто-то меняет статус fixme на отдельной ветке - то все, кто эту ветку видят - видят обновление статуса. Теперь так же .fixme/log можно обнулять и писать в него только свои локальные изменения. Это не повлияет на историю, т.к. учитываются все его версии со всех известных веток. Порядок обновлений вычисляется из порядка коммитов по времени. В том порядке, в котором гит выводит. Ну то есть если вы поставили часы в прошлое и закоммитили - да, история испортится, вероятно. Но на то и гит. Можно выяснить, кто это сделал и принять меры