Написал мурзилку про hbs2-git. Буду рад комментариям и вопросам, обновлю документ тогда

Прислали статью, как владельцев IPFS шлюзов атакуют через их провайдеров, жалуясь на размещение некоего "контента", якобы защищенного правом. Короче, пишут анонимки, а хостеры сносят, не разбираясь, само собой. Доносы, причем, в части случаев ложные, не будем говорить, что сам "закон" сомнительный.

Собственно, это же и hbs2 ждёт, т.к. я вот публикую документики в чате пока по той причине, что не дошли еще руки сделать те самые "шлюзы", что бы по ссылке были доступны данные тем людям, которые пока не хотят ничего ставить себе. Плюс в PDF я правлю опечатки, значит, надо не просто документ по ссылке на контент отдавать, а отдавать ссылку на мутабельный документ, т.е рефлог, где из транзакций будет выводиться последняя версия. Ну, собственно, тот же самый кейс что и в исходной ссылке.

Как бороться с беспределом пока непонятно — понятно, что даже если DNS будет резолвиться во множество IP - множество всё равно 1) очень ограниченное 2) будут атаковать через регистратора доменного имени. Т.е лучший вариант, что бы имя было гарантированно в мире не существующее и резолвящееся на локалхост или на ближайшую ноду. Что бы сделать последнее, нужен какой-то специфический DNS резолвер, который, опять же, человек должен будет поставить. Короче, пока непонятно, как с этим быть.

С другой стороны, может оставить "обычных людей" в покое? Захотят - подсуетятся, не захотят - ну, значит им не надо. У меня был кейс, я "обычных людей" научил забирать парашютное видео через торренты.

Потому что маразм с "закачали в облако - заплатили за облако - скачали из облака" ну реально достал. При том еще, что часть интересантов тусуется в рамках одного L2 сегмента, т.е на одном вайфае! Видео такого много, объемы большие, но при этом оно одноразовое. Когда все, кто хотел скачать - скачали, можно сносить (из облака. на диске-то пусть живёт, пока место есть). Т.е типично с облаком ты очень быстро начнёшь платить за место (видео много!), и должен будешь заниматься менеджментом (все скачали? я сношу!). Т.е неудобно и провоцирует на лишние ненужные расходы, как и гитхаб. Заметим, что создаётся искусственная потребность, за счёт подавления альтернативных технологий (торрент с DHT просто перестали работать в какой-то момент, а ведь работающие торренты были бы идеальным решением данной задачи).

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

Похоже на группу в телеге, но там сделано максимально неэргономично. 1. по умолчанию видео жмётся 2. нет такого, что бы сбросил пачку видосов и пошёл по своим делам, а дальше оно само всем доставится, был бы девайс онлайн.

https://torrentfreak.com/publishers-carpet-bomb-ipfs-gateway-operators-with-dmca-notices-230625/

по поводу того, как сделать стабильные веб-ссылки: видимо, только так: "лёгкая версия" ноды hbs2 компилируется в js/webasm и работает в браузере, отдаётся или с локалхоста или вообще лежит статическим html-ем на диске, а ссылка выглядит, как hbs2.html?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ну и исходя из того, что dns бутстрап с одной точкой в какой-то момент подавят, надо поднимать точек входа для него много, сидов для PEX тоже делать много, и запоминать их в локалсторейже! Т.е нода всё-таки должна быть с мутабельным стейтом, т.е хотя бы запоминать пиров, с которыми работала последний раз, и при рестарте начинать бутстрап и с них тоже

Все, кстати, поняли, какой ссаниной является текущий "интернет" ? Всё сделано максимально уязвимо (заговор?). Они, в принципе, не со зла, прост в моменте первое, что пришло в голову. Как языки Си и PHP — просто чувакам было очень надо в моменте. Если бы у создателей был бы правильный базис в голове — мы жили бы совсем в другом, прекрасном мире. А так имеем то, что имеем.

Например, при всей спорности такой вещи, как "блокчейн" — система доменных имён — идеальное для него применение! Вплоть до PoW. Хочешь красивое имя — майни его. Необходимость майнинга свела бы такую мерзость, как сквоттеров, до нуля. Ну то есть, захватывать-то имена можно, но это стоит, стало быть, не захватили, а нашли по праву. И да, ценную находку не грешно продать с аукциона. Сложность майнинга можно было бы сделать обратно пропорционально длине имени. Длинное - меньше, короткое — больше. Переход владения имён определялся бы транзакциями с подписями текущих владельцев, хрен отожмёшь. Да-да, namecoin. Где он, ваш namecoin? Принцип утёнка — закон индустрии. Кого первым увидело, то и мама. Поэтому имеем DNS и Си.

Или вот, ахаха, "сертификаты". "Удостоверяющие центры". "Авторити". Ахахахаха! аафторииитиии! Им можно доверять, они-то не обманут и их не скомпрометируют. Никогда такого не было, что бы серьезную корпорацию поимели или бы она продала пользователя за мелкий прайс кому-то!

ВНИМАНИЕ. Уведомляю, что после интеграции нового формата репозитория, которая случится вот прямо сейчас в течение 30 минут — старый формат поддерживаться не будет. Новый репозиторий построен на основе "логов операций" на каждый push, подробнее можно почитать в приложенном документе. Должен работать намного быстрее, чем старый формат и является расширяемым. Что делать. Создать новые ссылки, сообщить тем, кто пользовался вашей ссылкой. Старые ссылки удалить из репозитория, новые добавить и продолжать работать. Коммит в ссылку старого формата новым hbs2-git приведёт к поломке ссылки. Наоборот — тоже, но такие ошибки могут быть починены. Старый формат более не поддерживается.

Актуальная ссылка на hbs2 в hbs2:

TqieVxkwS9wDVXz5qDx7X648e2C7tvvnbNiVJfcdnap

Заняться ли приведением в порядок TCP PEX (сейчас не очень) или нарезанием лога операций git на сегменты, что бы он мог, наконец, прожевать большие репозитории? btw, добиться приемлемой скорости работы при импорте объектов в гит удалось крайне извращенным способом, который я вообще не имел ввиду. Я думал, что смогу генерировать дампы в формате fast-export, но нет. git, конечно, чудной. Есть команда, которая импортирует объект в гит в его нативном формате, git hash-object. так вот, у неё есть batch режим! но в нём ей в stdin можно пропихнуть только имя импортируемого файла, а не его контент. После разбития на сегменты, кстати, возникнет частичная дедупликация, хотя бы с на уровне сегментов и их частей. Остаётся подобрать размер сегмента. 10Mb? 50? 100?

Короче, чат гпт говорит, что надо hbs2-git допиливать, раз с кривым пексом всё работает, то глядишь, и еще поработает, всегда потом починишь. ну штош.

Вот что еще заметил: сейчас пишу в логи операции в порядке: (коммит, зависимости). Поскольку так удачно сложилось, что гит новые коммиты делает не дельтами, а все объекты целиком пишет, то что бы там разработчик не мутил - сквошил, мержил, ребейзил - итоговые блобы и деревья (снапшот проекта) — выглядят довольно константными. таким образом, если сначала в лог писать деревья и блобы, а в конец - коммиты, то есть шансы, что префикс лога будет более константным, что ли. т.е при последующем разбиении на сегменты есть шансы, что сегменты в начале лога будут лучше дедупиться.

Жуёт очень большой репозиторий nixpkgs. Около 4G в хорошо упакованном гитом виде, и очень много - в не особо хорошо упакованном. Жуём - в смысле успешно экспортировало в ссылку, а теперь делает git clone из неё

nixpkgs оказался очень классным стресс-тестом для hbs2-git и hbs2-peer, буду его и в дальнейшем использовать,
пока не станет всё хорошо. Вчера экспорт этого репозитория прошёл нормально и довольно быстро, а вот импорт (git clone)
поставил систему на колени (я не дождался и пристрелил, с течением времени скорость всё замедлялась). В частности потому,
что делается через файловую систему / tmpfs, и при распаковке миллиона
объектов на tmpfs - последней поплохело. Кроме того, написанный чатом гпт хаскельный кодик породил где-то мемори лики,
надо будет посмотреть. Правда, то при экспорте, и основным гадом оказывается haskell-language-server который жрёт 60% RAM,
если параллельно с тестами где-то у меня открыты редакторы. Что могу сказать по результатам. Кажется, логи hbs2-git ждёт
еще одно ломающее обновление. Но может быть, сделаю его неломающим. Сегментированный-то лог ничего не сломал, просто
порядок объектов поменялся на более правильный (блобы, деревья, коммиты) - всё примерно в топологическом порядке,
более поздние объекты ближе к концу. А вот целиковое сжатие потребует доп. обработки, но кажется, инфу о сжатии можно
добавить в метаданные и не делать изменение ломающим.

FIXME: mandatory-compress-whole-log
Эксперимент показал разницу в размере репозитория git и
соответствующего ему стейта hbs2-git приблизительно в 10 раз (!!).

Очевидно, что git сжимает даже лучше, чем мы бы просто сжали его
объекты архиватором, он проделывает еще некоторые дополнительные
манипуляции, к которым шёл годами.

Всё, что мы пока можем сделать --- это хотя бы сжимать секции лога
целиком.

Вопрос, ломать или не ломать при этом совместимость, т.е оставить ли
возможность несжатых логов.

Указывать ли информацию в аннотации дерева, либо же завести секцию
лога, указывающую, что за ней следуют сжатые данные.

Сжатие на уровне лога целиком нужно обязательно, т.к. сейчас мы
имеем стейт размера 36G вместо 3.5G на тестовом примере репозитория
nixpkgs.

Сжатие лога внутри секций неэффективно и, кажется, бесполезно.

Если его дропнуть, то поломается совместимость.

Если оставить, но поставить нулевую компрессию --- то будет
бесполезное замедление работы.

Сжимать на уровне лога целиком --- правильно.

Но если иметь несегментированный лог, или очень большой размер
сегмента, то это будет очень медленно, и чем больше файл, тем хуже
будет ситуация.

На сжатии в памяти, кроме того, мы можем исчерпать память.

#hbs2 @hbs2git

Извините, что к вам обращаюсь. Поделитесь ссылкой на гит на репозиторий мегабайт на 100 - 200, или хотя бы идей, что бы это могло быть. Как-то в гитхабе нету опции "найти любой проект мегов на двести"

Клонируем 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. У меня по нему ещё было два сертификата и худи с катышками