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

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

- починить 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 ветка, стабильность/совместимость не гарантируется

Шифрование протокола работает уже около недели

... -> Protocol Encryption (test) -> Fast Large Git Repos -> Git Repo Encryption -> MVP

работаем поверх него. пока что занимаюсь refchans - там получается таки помесь рантайм консенсуса и CRDT (grow only set) c
ACL, собственно для ACL и нужно подобие рантайм консенсуса. Из хороших новостей — кажется, оно может так сходиться
без лишних раундов, и кажется, выбор пропозера можно делать, а можно и не делать, а можно делать отдельно

Когда-то мы делали проект gps мониторинга школьных автобусов. Эпичная история, но не суть. Там каталось около 300 автобусов, с каждым был GLONASS трекер и с каждым - какая-то своя история + охота за ними по тамбовской области, которая больше многих стран. С тех пор мне кажется, что меня преследуют машины из региона 68, а так же многие числа кажутся знакомыми - ведь это номер какого-то автобуса, с которым была какая-то история. 608, 219, вот это всё. К чему это я. Мне теперь кажется, что каждый хэш Blake256 в кодировке Base58 я уже где-то видел.

юникс-сокеты, кстати, оказались отличной штукой. думал внешние приложения как цеплять - по TCP, по HTTPS/вебсокетам. Но вот юникс-сокеты оказалось сделать просто, быстро и без засорения пространства номеров портов, прям доволен

Каждый раз, когда изобретаешь что-то, чувствуешь себя неловко. Вроде бы в области ничего нового быть не может, потому, что люди из академии уже двадцать четыре года мусолят PBFT, а если считать PBFT "лампортом", как это делают на некоторых факультетах, то это вообще 1982-ой год. 1982 (!! ). Вроде бы и понятно, как работает академия в целом: взяли базу (PBFT), добавили что-то вполне очевидное, дальше проводим ИСЛЕДОВАНИЯ, делаем ПУБЛИКАЦИИ, потом рождаем супер-дупер алгоритм, который на 8% эффективнее в определенных обстоятельствах, потом учёный насилует журналиста, а авторы 8% улучшения превышают скорость света и отгребают миллионов 30 на свой стартап на волне общего безумия. В принципе, я внутри такой волны побывал два раза. Проблема в том, что надо быть не внутри волны, а на ней сёрфить, что бы было совсем хорошо - лучше бы её поднять (вспомним Nicira и их софтсвич). Так вот, по идее с этими алгоритмами как - если общий принцип понял, то вроде бы можно разобрать и собрать, с нужными параметрами (отсутствие лидеров и тп). Понятно, что потом надо бы исследовать, позвать математика и что-то там доказать. Понятно, что доказательство само по себе ничего не доказывает еще — как оно может содержать ошибки, так и реализация. Все это утрясается за годы использования в режиме неуловимого Джо. Посмотрим вот на IOTA. Первое, что мы находим про IOTA — "алгоритм часто критикуют за то, что хрен знает, он вообще работает или нет" и второе "в настоящий момент, что бы вся эта хрень на графах точно работала, есть специальный узел-координатор, который фиксирует стейт время от времени" —- ну вон оно чо! Но так-то каждый может. Я это к чему? Вот понадобилось мне алгоритм без лидера запилить, который будет сходиться и делать то, что надо (распределенно объединять множества без лидера) - и вроде бы он есть. Вроде бы сходится. Вроде бы похож на все PBFT-подобные. Вроде бы все нормально, не хуже, чем у других. А всё равно — неловко как-то. Был бы готовый, взял бы готовый. Но прям готовых-готовых я не вижу, а вот IOTA брать и тупо запиливать - стрёмно, потому, что делать, не понимая что, и никто не понимает что - ну такое себе.

Есть такой негативный паттерн - когда только свежеизобретенная НЁХ является ключевой фичей для продакшена.
Регулярно, раз в несколько лет в него попадаю, что делать, что бы такого не было - в принципе не совсем понятно.
Причины каждый раз примерно такие - "нет такого, что бы взял из коробки и воткнул, куда надо и заработало" или
"вроде бы это должно быть несложно" или их суперпозиция. Так-то в норме, этим занимаются где-нибудь в R&D или универах,
пишут много пейперов и прототипов, и потом, когда этого всего накопилось достаточно, можно пытаться тащить это в прод.
С одной стороны. С другой стороны — ну если нет реально готового, что что? Отказываться?

Что делать, что бы этого не возникало — непонятно, в целом, делать, знаешь что - каждый может. А ты вот попробуй сделать
неизвестно что. Думаю, что если назвался HEXResearch, то нужно просто смириться с этой ситуацией. Что иногда будет дольше,
чем планировалось, а иногда может и вовсе не получиться, хорошо бы, правда, иметь план Б на этот случай.

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

Помните, до всего этого блокчейна - PAXOS и RAFT казались сложными?

Да, новый алгоритм консенсуса придумать (а он новый - прямо такого не вижу) - это не поле перейти. Не работает, гад. Тупо клонировать PBFT-like не хочется, и хочется, что бы был без лидера. И вроде бы должен работать. Но пока нет. Из готовых без лидера нашёл HoneyBadgerBFT, и это что-то такая лютая наркомания, что тащить такое к себе я не готов. IOTA и Avalanche - аналогично. IOTA понятная, но сомнительная, аваланч - непонятный и сомнительный. Распределенные алгоритмы с лидерами - какие-то и не распределенные особо, на мой взгляд

Не знаю где еще спросить - надо бы построить модель распределенного алгоритма на каком-нибудь из фреймворков. Алгоритм вроде бы простой, но я инструментарием для подобного плана моделирования вообще не владею, и не представляю, сколько это (построение модели) займет времени. Есть ли где-то тусовки по этим инструментам (spin, tla+) или есть кто-то, кто готов приватно пообщаться на эту тему, что бы тут эфир не засорять?

курс лекций Лампорта (тот самый Лампорт!) по tla+ https://lamport.azurewebsites.net/video/videos.html

Вообще не собирался в это лезть, если честно, но как всегда — стало надо. Есть ли, интересно, какой-то КМБ по формальной верификации и модел-чекингу (как оно по русски-то хоть)?

консенсус qblf делает вид, что работает на нескольких хостах. какой-то тут должен быть подвох, конечно. отлаживать это всё дико. две реплики расходятся, надо минимум три и желательно с сетью - т.к. что бы блоки подъезжали с задержкой

Внимательный читатель конечно спросит, на кой чёрт тут в hbs2 понадобился вообще консенсус. Суть такова, что есть еще те проекты, за которые деньги платят, и там нужен какой-то "блокчейн", я извиняюсь. У нас был один, но там легче застрелиться, чем на нём делать это вот всё. Честно говоря думалось, что имея в hbs2-peer gossip + pex + библиотеку для реализации протоколов + merkle деревья + подписи + распространение блоков, как-то можно намутить "блокчейн" малой кровью, ну там, CRDT какое-нибудь с подписями, типа такого. Но нет, просто это не решается. Впиливать какой-то прямо tendermint поверх этого всего... Ну такое. Была идея, что можно такие вещи делать внешними процессами, если от hbs2-peer провесить какие-то удобные ручки, и в общем-то, такие ручки нашлись - это unix socket-ы, на них исключительно удобно делать двухстороннюю коммуникацию, без всяких заморочек, как с вебсокетами бы было. Т.е в hbs2-peer решает вопрос организации сети, а FSM крутится во внешнем процессе. Ну и вроде как оно работает. Была еще идея, что множества идемпотентных транзакций можно как-то проще приводить к общему знаменателю, чем вот это вот всё prevote/vote/precommit/commit c лидером, и, вроде, так оно и есть. Еще в библиотеку Raft запиливаем на всякий случай, пусть будет.

Что даёт консенсус в отличие от CRDT: нам не надо вообще заморачиваться структурой, пиры за несколько раундов договорятся и согласуют любые данные, т.е например, блоб репозитория гита. мы можем не париться порядком транзакций в нём, а можем тупо дописывать новые объекты в конец, и новый стейт будет хэшом нового получившегося файла, который будет эффективно расходиться по hbs2 меркл-деревьями (будут докачиваться только отсутствующие блоки). Минус в том, что какое-то количество пиров должно быть всегда онлайн. Причем, пока что это совершенно конкретное количество - типа 2/3 от всех пиров, указанных в настройках канала. Для рефлогов/рефчанов такое необязательно, пира загасил, хоть всех, поднял, они засинкаются. Вот и думай теперь, как с этим быть