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

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

Самое интересное, что эти "рефчаны" (мультиподписные каналы) мне прямо сейчас протребовались не сами по себе, а для того, что бы можно было в среде с 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 ветка, стабильность/совместимость не гарантируется

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

... -> 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