Клонируем openwrt из hbs2. 43M объектов, 57915 коммитов, размер до gc - 2.9Gb, после - 197M, клон (импорт) занял 4 минуты. Клон по https с гитхаба - 30 секунд. Ну то есть да, многое можно пооптимизировать, но надо учитывать, что когда git клонирует - он делает только свою работу. Когда clone по hbs2 - то там hbs2 делает работу, и git делает работу, т.е эти 30 секунд добавляются. С одной стороны — да, надо многое пооптимизировать. С другой стороны жить вроде уже можно.

FIDO ведь была DAG, вроде? можно прямо щас запиливать. Только решить - положить гипертекстовый векторный фидонет в гит. Или прямо поверх рефлогов делать

fixme: hbs2://Fujv1Uy4W5d9Z7REEArMxbXSJ8nLLn4dYuvaAs8b86hr

suckless-conf hbs2://JAuk1UJzZfbDGKVazSQU5yYQ3NGfk4gVeZzBCduf5TgQ

ссылка в новом формате: сжатие всего сегмента gzip + указание этого факта в метаданных. надеюсь, теперь надолго

hbs2://BTThPdHKF8XnEq4m6wzbKHKA6geLFK4ydYhBXAqBdHSP

Есть вопрос на подумать. Что бы зависимости проектов завести тоже на hbs2-git, нужно сделать http адаптер. существующие сервят с какого-то репозитория (что логично), но мне кажется прям как-то не очень круто - клонить репозиторий и из него раздавать файлы. В прошлой итерации, когда каждый объект гита соответствовал объекту в hbs2 - была тривиальная реализация http сервера для гита. Сейчас это сжатый лог объектов. То, что он сжат целиком - не даёт, например, возможность ссылаться на на объект по смещению в файле. Есть какие-то предложения, как можно аккуратно решить вопрос, желательно без избыточного использования диска (ну не тупо клонить репозитории и их отдавать - хотя можно и так)

пока мне не даёт покоя моя идея - скрестить CRDT и PBFT-подобнй подход + нашу терминологию (рефлоги).

1. раунд начинается по наступлению события - лучше всего времени, как в OTP. UPD: прошло N секунд с предыщуего раунда (или что? откуда мы знаем вообще, сколько времени прошло с прошлого раунда, если мы только что стартовали).

2. участники представляют свой мемпул (пишут в лог)

3. участники ждут, пока все или большинство из шага (2) - отпишутся в лог или наступит второй таймаут

4. по наступлению этой фазы мы вычисляем результат и пишем вердикт: (ссылка было, ссылка стало, ссылка на раунд голосования).

обновляем наш стейт. ждем события начала раунда

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

А помните, был такой 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: ), что бы подписка на сервис была была одновременно членским взносом в ФПС или наоборот. Короче, если подумать не такая уж унылая ситуация-то. НИОКР всяких таких штук не такой уж дорогой, особенно если делать по фану и для себя