В текущем 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 кода сразу работали. Какие-то для этой всей распределенной истории должны быть паттерны, что ли. А так в каждом протоколе делаешь по-разному, и непонятно, как лучше. Где сразу по событию что-то делаешь. Где накапливаешь информацию и обрабатываешь отложенно. Никак не пойму, как проще и надежнее. Жалко неделя короткая вышла из-за спортивных мероприятий, терпеть не могу недоделанное бросать на середине, неважно что.

Ладно выдвигаться надо не раньше 11, это ж 4 часа еще есть, вдруг прям щас оно заткнётся и заработает.

Вроде бы начало сходиться. Уф.

наш роадмап общий:

- починить git (косяк с локальными репо, не критичный)

- внедрить шифрование - кажется, заработало ?

- внедрить шифрование деревьев - хотя бы в рефчаны - там есть headblock, куда можно писать ключи - надо обсудить как лучше сделать

- MVP

- простой шаринг файлов ( мультипостинг, права на чтение через шифрование )

- простой шаринг каталогов ( мультипостинг, права на чтение через шифрование ) -
каждый каталог это полный стейт + все блобы на которые он ссылается + ссылка
на предыдущий. могут получаться DAG-и, что делать пока не знаю (можно онлайн консенсус
для согласования записи, но на другом этапе. или чёрт с ними с DAG, пусть будут)

- "имиджборда" - простой линейный блог, куда могут писать авторы (из головы), и там же ссылаться на контент (файлы)

- "имиджборда" с авторизацией - скриптик, который расшифровывает сообщения на основе ключа автора, ключ вводится онлайн или кладётся в local storage зашифрованный паролем

- коменты к сообщениям "имиджборды" - могут оставлять "авторы"

в связи с шарингом каталогов немедленно возникает вопрос: почему в гите сделано именно так, как там сделано.
почему стейтом каталога нельзя было просто держать плоский файл, где будет список записей (строк!), около каждой записи
написано что это - каталог или файл, и для каждого файла - его хэш. зачем было вводить сущность tree?
Какие в ней плюсы? Рекурсировать по ней можно? Сильно быстрее, чем по списку строк, которые надо еще распарсить?
Я вот не хочу повторять схему git, но может, в ней есть какой-то смысл, которого я не понимаю?

Не могу привыкнуть к какому-то генетическому идиотизму it-инфраструктур, например, платёжных. Вот езжу я по ЦКАД. У меня куплен транспондер. Есть аккаунт. Лежат деньги. Забиты номера ТC. В итоге, через месяц после проезда мне начинают сыпаться СМС и звонить роботы "зоплотите а ни то вам пздц! будем жаловаться в гаагу!". Вашу мать. Почему нельзя сделать артефакт типа "инвойс". В нём, сука, в json или yaml или key: value написать кому и за что я должен и ID платежа и подписать своим ключом сервиса в, сука, base16 или base58 добавить подпись в сообщение. Направить его на email адрес банка, который я скажу в сервисе. Банк его распарсит и мне покажет, и если я соглашусь — то просто оплачу инвойсы. Нет же. Какие-то системы. Веб-сервисы. СМС. Голосовые роботы. QR коды. Одно на другое ссылается, всё тормозит. Одно не работает через VPN. Другое не работает без VPN. Роботы голосом обзванивают. Сука. email. плейнтекст. кей-валюе. И в банке - вам пришол щот. Хотитие оплатить да/нет? Игнорировать такие счета в дальнейшем? оплачивать автоматом? Всё. Нет же. Надо, сука, устроить ДРАМУ с обзвонами с номеров, которые помечаются, как спам , и вот эти вот все миллион платежных систем, завязанных на онлайн-обработку и редиректы с смс подтверждениями. Дебилы.

Почему за двадцать или сколько там лет нельзя было просто сделать долбаный электронный инвойс? В виде текстового файла. Кому, от кого, сколько, за что. Если вам с подписью слишком сложно, можно ж без подписи - оплата ведь добровольная. Просто маленькое текстовое самодостаточное сообщение. А не вот это вот всё.

Не, ну не дебилы? Т.е слать письма и кошмарить ответственностью это они да. Прислать письмо с QR кодом на оплату - это они нет. Это при том, что у меня уже стоит их приложение, аккаунт и даже деньги там лежат. Т.е вот есть ЕГЭ, есть вступительные экзамены, курсовые, дипломы, вот это всё. А в IT в итоге сплошь умственно-отсталые

Стабильная версия hbs2 живёт на бранче stable-0.6

master теперь версия для разработки нового релиза, dev ветка, стабильность/совместимость не гарантируется