Статья: Финальная стадия опердени как распределенная свёртка журнала транзакций. Сиквел и окончательное окончание историй про динамическую опердень и статическую опердень

А помните, был такой openstack. У меня по нему ещё было два сертификата и худи с катышками

Заставляем nix flake тащить исходники флейка из hbs2-git. И он тащит. Где мои цыгане с медведями?

тестируем шифрование. мы находимся здесь:
... -> Protocol Encryption -> Fast Large Git Repos -> Git Repo Encryption -> MVP

Введение: рефлоги это журналы транзакций, где идентификатором журнала является публичный ключ, а показательством права записи — подпись приватным ключом этого публичного ключа. Таким образом, писать в такой журнал может только владелец ключа. Мы можем раздать ключ всем, но тогда невозможно будет управлять метаинформацией.

Зарекалась же свинья. Не хотел делать "мультирефлоги", а именно такие, в которые могут постить несколько участников, т.е. с ACL и управлением ACL на текущем этапе. Но для решения проблемы рантайм консенсуса, который нужен, что бы можно было поднять несколько нод одновременно и они договаривались что делать, что, в свою очередь, нужно для текущего проекта, куда удалось впихнуть hbs2 при отсутствии сопротивления заказчика. И встал неприятный выбор: или сделать нормальные рефлоги с многими писателями и возможностью онлайн-консенсуса, или закостылить. Закостылить вроде бы можно, но тоже непросто. Т.е разница между закостыленным и нормальным решением будет дня три - четыре, короче неделя. Текущее решение с рефлогами в своём роде законченное, т.е то, что в них пишется - представляет собой подписанные владелцем рефлога записи, что даёт возможность даже взять плоский лог и проиграть его, выкидывая левые записи, даже если они туда попадут. Но там в транзах предусмотрен нонс, что бы они были гарантированно уникальными и подпись в каждой записи от известно чего (см. введение). Можно это обойти, и если транза типа A - то проверять так, а если B - то сяк (смотреть в ACL), но это начинает попахивать костылями, как раз. А если сделать полностью новый протокол и формат, где ответственность за уникальность транзакции возложить на клиента — то это попахивает большим дублированием кода, ведь обработка на 80% одинаковая. Неприятные вилы, надо сказать. Допстим, правильный путь это всё-таки добавление нового протокола и сущность нового формата, и обобщить дублицирующийся код, может, чат гпт сможет. Но я даже название для нового формата не могу придумать, так как рефлог было удачное и уже занято

а еще меня мучают два подозрения: 1) мало кто вообще в курсе, как устроен гит 2) судя по реакции, никто вообще не понимает, о чём я пишу. А ведь по сути сейчас такая захватывающая ведь происходит, как совмщение CRDT с онлайн консенсусом и распространение этого всего по P2P протоколу. 3) кажется, это особо никого не захватывает ахаха

(погода вроде сомнительная, никуда не еду (?), значит, пилим). #haskell есть такая статья "The ReaderT Design Pattern", Сноймана. "Суть такова", что если стейт разных частей программы делать как Reader, а внутри, если надо — мутабельные переменные, TVar или там IORef — то внезапно части программы начинают неплохо композиться. Например, если мы хотим запустить два вычисления в одном стейте, в разных непредсказуемых местах с любым рандомным монадным стектом в любом месте — то всегда можно запустить вычисление при помощи liftIO и пропихнуть туда актуальный стейт. Таким образом, глубина и особенности монадного стека в каждом конкретном месте перестают иметь значение, а нужные тебе вещи можно позвать в любом месте, просто дав контекст. Вот бы, блин, с людьми было так. Потому, что серию выводов и решений, к которым пришел в результате какой-то проделанной работы — никак не донести до других, особенно если это синтез практик из разных областей. Причем, хоть статью пиши. Хоть не пиши. Всё бесполезно. Ведь нужно не только понять, но и прочувствовать.

Вторая тема, которую донес то ли Снойман, то ли не Снойман — это про то, как писать код, который работает в любой монаде, а нужные ему вещи он объявляет через констрейнты, соответственно, если коду нужно что-то, мы это что-то втаскиваем через констрейнты и просто их реализуем для конкретной монады, если не хватает. Кажется, в той же статье. Я всю эту историю по широкой дуге обходил, RIO в частности. Но вот правда оказалось крайне полезным.

Или вот CRDT, например

В текущем hbs2 есть "рефлоги", так вот reflog это grow only set транзакций. Согласно литературе, grow only set является CRDT. А это значит, что за нас доказали все свойства, а структура это eventyally consistent при наличии gossip или другого способа обмена. Это хорошо работает, когда у нас один писатель и нам не надо управлять писателями (добавлять новых, отзывать права у старых). На таком можно сделать много - например, распределенный git когда у каждого свой форк, или вот твиттер, или вот каналы в телеграмме. Веселье начинается, когда нам нужно несколько писателей и добавить управление правами. Казалось бы: всё тот же grow-only set - CRDT + ACL - grow only set + сумма - казалось бы, тут CRDT, тут CRDT - все хорошо. На деле получается, что поскольку на транзакциях нет явного порядка (порядок приводит к DAG или требует рантайм консенсуса), мы не можем определить момент, в течение которого действовал "старый" набор ACL. ACL действуют только в "сейчас", Когда нода стартует с нуля - то читая лог, она никак не может понять, какие транзакции были валидны, а какие нет. Даже если сделать связь между ACL и транзакцией. Какая-то нода может остаться "в прошлом" и слать транзакции со старым ACL, например, в котором ей было можно. Таким образом, она не сможет портить view в настоящем, но может фальсифицировать историю. И что бы эту самую историю как-то зафиксировать - нужен либо онлайн консенсус какого-то рода, либо подход с trusted owner, который будет фиксировать историю при переходе на новый HEAD блок (который содержит ACL). Такие вот дела. Подход в принцие годный, кроме того, что на owner канала возложена теперь обязанность фиксировать историю при смене ACL. Предполагалось, что owner просто держит ключ в сейфе, раз в какой-то период достаёт, что бы добавить или убрать автора. А теперь ему придётся еще и историей управлять, ну вот ничего лучше не придумалось пока

А вопрос вот в чем: нельзя ли всё-таки найти sequence CRDT который бы дал возможность упорядочить транзакции хотя бы относительно операций добавления/удаления acl

Вот как так получилось, что в Ed25519 ключ подписи - отдельная сущность от ключа шифрования? И вместо одной пары ключей мы вынуждены развести какую-то дичь. И всё ради libnacl. Капец, как неудобно. теперь у нас есть
1) ключи подписи 2) кейринги - где ключ подписи это ID + N пар ключей шифрования - привязаны к ID и что бы не потерять 3) теперь еще актору надо представляться другим - и ему надо передать свой публичный ключ подписи И публичный ключ шифрования. Ну капец зоопарк. Кто в крипто шарит - там нельзя было как-то намутить, что бы был один ключ для этого всего? Я даже не знаю, как эту пару (подпись + шифрование) назвать-то. Id? Intro? Gimme ya intro file, dude, to add u to our private chat

последний раз меня так колбасило, когда делал новый формат репо для гита. заняло чуть ли не полтора месяца, правда, в овощном состоянии, т.е больше прокрастинировал. схема с динамическими рефлогами, keycard и шифрованием ключа рефлога ключами авторов в качестве ACL провалилась. мы в такой схеме не можем идентифицировать и адресовать конкретного автора - ну, без модификации протокола. а чем его модифицировать, лучше уж новый напилить. поехали опять заново. радует, что какие-то вещи не меняются, то есть фиксация истории владельцем канала остаётся, иначе требуется какой-то механизм консенсуса.

NOTE: on-refchans-tldr
CRDT с контролем прав доступа, но без полного онлайн-консенсуса.
Проблема: участники могут искажать историю после их удаления из
списка авторов.

Решение:

Транзакции требуют подтверждений от нескольких пиров.
Только авторизованные пиры могут подписывать и публиковать транзакции.
Транзакции подписываются автором и пиром, ссылаясь на актуальный ACL/HEAD.
Учитываем только транзакции, удовлетворяющие правилам HEAD.
Принимаем "запоздалые" записи в течение короткого периода после обновления HEAD.

Подход: комбинация CRDT и консенсуса. У нас есть PROPOSE и ACCEPT (VOTE),
решения делаются через интерпретацию журнала или дополнительные
транзакции. "Авторы" публикуют только валидные транзакции,
достигая валидности при помощи сообщений эмеферного протокола
(фазы VALIDATE/PRECOMMIT).

(сокращенная chatgpt версия большой простыни, которая порвала телегу)

Невозможно не видеть аналогии (чего угодно с чем угодно) того, что получается с сетью FIDO, разработанной, по легенде, собакой одного из основателей и названной именем разработчика. Т.е есть чётко прослеживается два уровня иерархии по одному измерению ( пир(нода) - автор (пойнт) ), и похожей по другому измерению ( владелец/автор). Вероятно, это просто минимально возможная иерархия —- для второго измерения можно наворотить много чего — owner/moderator/writer/reader, но это всё уже усложнения, которые можно пытаться делать, когда других дел не останется.

Про поддержку отечественного производителя. Вот, например, рынок скайдайверской электроники. На первый взгляд, кажется, что его (массового) нет -- по исследованию, проведенному несколько лет назад, парашютистов было человек десять тысяч на страну, и это с большой натяжкой. Однако, для этого отсутствия рынка понастроили аэротруб, например. И они не простаивают. Труба это капец какое дорогое сооружение, и CAPEX и OPEX. Даже маленькая труба. Времена, когда трубу можно было взять в ипотеку, давно закончились. Однако же, трубы появляются — и сюрприз, помимо прочего они еще и генерируют новых парашютистов, увеличивая свой рынок, т.е может и слабая, но точно есть положительная обратная связь. Теперь вот к рынку электроники — казалось бы, его нет, или он не массовый, т.к. массовый он только если в мировом масштабе. Казалось бы, он занят — достаточное количество производителей в мире, а какая-нибудь пищалка (звуковой сигнализаторо высоты) пусть и относительно дорогая, но покупается один раз на много лет, мне предыдущая служила лет пятнадцать, пока не сгнила. Ситуация, вроде бы, плохая, но есть и хорошие новости: 1) в отделе UI/UX западных брендов, спроектировавшие наиболее заметные на рынке приборы работали солевые наркоманы — т.е за годы использования я так и не смог выучить, как управляться с этим устройством, кроме пары функций, а другой их девайс я даже не пытаюсь использовать — настолько там всё дико, что проще забить. 2) как завещали деды — надо электронику резервировать, иначе может случиться всякое (см. мой видос с музыкой из Бенни Хилла) - 3) западные производители находятся на западе, запросы на улучшения они в лучшие времена не принимали, ну а сейчас и вовсе безнадёжная ситуация 4) стало дороговато. Маржинальность устройств можно оценить где-то в 30% - 45%, что с учётом проданных ~300 устройств даёт где-то около 3M на первый год. Вроде бы и мало, но — рынок далеко еще не заполнен, и это еще видимый маркетинг отсутствует. А можно ж еще запилить разные устройства на одной базе. Сделать онлайн-сервисы (журналы прыжков) — с подпиской. Протолкнуть, что бы ФПС признавало и эту всю бумажную канитель сократить. Сделать кобрендинг с ФПС ( :lol: ), что бы подписка на сервис была была одновременно членским взносом в ФПС или наоборот. Короче, если подумать не такая уж унылая ситуация-то. НИОКР всяких таких штук не такой уж дорогой, особенно если делать по фану и для себя

TL;DR - про "импортозамещение". Над ним принято глумиться, но надо понимать: захвативший рынок продукт не обязательно лучший. Ему надо просто быть первым и как-то работать ну и приемлемо стоить. Потом он становится брендом, и на глобальном рынке хрен что ты с этим брендом сделаешь. Т.е пользователя надо еще поставить в определенные условия, что бы он предпочёл известный бренд малоизвестному, даже если изделия от "бренда" — в принципе хрень. Поэтому огораживания на рынке вызывают новые условия, в которых что-то может действительно взлететь. Но как всегда, в одном случае из 99.

"Для себя" и "по фану", кажется, очень мощные факторы. hbs2 я делаю для себя и по фану, доделаю и буду пользоваться, неважно что. Мне надо репозитории гита держать, файло шарить, по возможности не платить всяким упырям (а если платить - то нормальным людям, а не охеревшим), шифровать всё вдоль и поперёк и не подвергаться цензуре. Положил файл, получил хэш — через годы нашёл файл по хэшу. Если бы syncthing или торренты так могли работать, использовал бы их. Нет — ну пришлось вот запилить. Я на серваке лог или дамп базы в hbs2 толкаю, на рабочем компе через секунду по хэшу выцепляю, и не вспоминаю, как (и откуда) scp файло скачать, куда какие ключи и какой где vpn включить. При желании вообще лог можно в hbs2 в почти риалтайме толкать и где надо выцеплять. Или клипбоард шарить. На ноуте на диване скопировал, дошел до десктопа, запейстил. Сейчас я это через телегу делаю. Линуксовая шарилка клипборда, которой я пользовался, стала платная! И небось мне не готовы сейчас продать даже за деньги, ну и пошли в жопу тогда.

Если не получится сделать так, что не выйдет заниматься только им и больше ничем — всё равно сделаю и буду использовать в работе. По факту мы его сейчас уже внедряем в один из проектов, как "блокчейн" (извините за это выражение). А что? Блоки есть? Есть. Хэш-ссылки есть? Есть. Стойкий к византийским атакам? Ну, примерно как и все прочие +-. PoW можно вкорячить? Можно, в пяток мест где он будет уместен.

Или вот парашютные видосы шарить. На ноут скинул, оставил, ушёл в подъем, оно тем временем по всем разъехалось, а файло лежит на моих нодах и нодах участников, ноль оплаты Яндексу. А места парашютные видосы жрут много, и счёт за диск в облаке хоть и небольшой, но постоянно увеличивается.

(всё, заканчиваю флудить на сегодня. будем считать, что это не флуд, а стендап и ретро в группе из одного человека) чувствую необходимость уже как-то шарить контент, причём на всех вообще, а не ранних адоптеров техологии, которые могут поднять ноду локально. Но не могу сообразить, как это лучше сделать без ссылки на конкретные домены. Домен могут отжать, ip адреса непостоянны, а хэш-ссылка указывает на конкретный, иммутабельный объект, неважно где он находится. Т.е сделать маленькую мульку для публикации текстового контента и код сниппетов, который/которые неуместно класть в телегу — это вопрос 1) pandoc 2) адаптивного css и... всё. но ссылка должна быть в куда-то, но куда? Локальный html, в котором код, который находит ближайшего пира, имеющего этот контент и скачивающий его? Уже не так просто это раз, запуск скриптов из неизвестного источника это два

интересный вроде бы факт - вернее "вроде бы факт" - т.е вроде бы, это факт. но не факт. но кажется, что факт. короче, если у нас есть "ссылки" (рефчаны) и над ссылкой есть половина консенсуса - т.е есть сообщения PROPOSE/ACCEPT и сбор кворума подписей из известного множества - то, вроде бы, из двух ссылок с полконсенсусом можно собрать целый консенсус. в ссылку один пишутся исходные данные, а в ссылку - два - валидированные данные и реакция на них. при этом предлагать исходные данные могут одни, а агрегировать данные / постить реакцию - могут другие. и в продакшон я сейчас запущу два раза по полконсенсуса, т.е две ссылки - в одни будут валиться сообщения, в другие - реакция на них. а и там и там будет собираться кворум. занимаюсь я этим в принципе потому (нету в роадмапе же) потому, что за внедрение этой хрени немного денег дадут, извиняюсь за прозу. по факту хочется, чот бы была пачка нод, одни гасим, другие вводим и что бы они автоматом снюхивались и без всякого лидера дело делали - одни инфу собирали, другие инфу обсчитывали

А имея штуку из поста выше, которая уже наполовину заработала (т.е нету пока механизма "догона" для отсталых нод), можно запиливать например всё, что похоже на чат с подпиской/отпиской владельцем чата. т.е до сих пор у нас был "твитер" - каналы с одним писателем. то теперь появляется "телеграм"

у меня есть ответ, почему Торвальдс, когда писал гит, не сделал его сразу распределенным. По той же причине, по которой он не стал делать микроядро. Типа, от распределенности можно кукухой поехать. Да, можно. Делал бы сразу по уму гит - то не через четыре дня смог бы им начать пользоваться, а через полгода. Это если бы у него был хаскель, ахаха. На сях хрен его знает вообще. Год?

Самое интересное, что эти "рефчаны" (мультиподписные каналы) мне прямо сейчас протребовались не сами по себе, а для того, что бы можно было в среде с gossip-ом (когда ноды беспорядочно доставляют друг другу сообщения, и мы не знаем откуда оно приедет, главное - куда (канал) и от кого (ключ подписи) - идентифицировать пиров, и сделать "эфемерные" транзакции, которые никуда не пишутся, но для которых можно сделать все те же самые проверки, что и для тех, что пишутся в журнал. Имея такое, можно вынести всю обработку вовне пира, просто сделав внешний процесс, который к нему присасывается по http или tcp, и может принимать-отправлять транзакции, подписывая ключом автора (собой), и делая с этими транзами что ему хочется — например, онлайн консенсус. Но с управлением правами доступа, т.е владелец может добавлять - исключать ключи. Grow only set с ACL для "перманентных" (пишутся в журнал) транзакций — это просто логичное завершенное состояние для этой штуки, не могу же я сделать только эфемерные транзы и так бросить. Сразу ничего конечно же не заработало на 100%, есть гонки и получается добиться ситуаций, когда журналы перестают сходиться. Ну а когда свежие 1K loc кода сразу работали. Какие-то для этой всей распределенной истории должны быть паттерны, что ли. А так в каждом протоколе делаешь по-разному, и непонятно, как лучше. Где сразу по событию что-то делаешь. Где накапливаешь информацию и обрабатываешь отложенно. Никак не пойму, как проще и надежнее. Жалко неделя короткая вышла из-за спортивных мероприятий, терпеть не могу недоделанное бросать на середине, неважно что.