На всякий случай еще раз скажу — пресловутый double ratchet — это просто ключ шифрования новых сообщений выводится из известных данных и таким образом принудительно меняется, никакого рокет сайнса. Малосовместим с удобством использования (история на "сервере", пускай даже отсутствующем и являющимся просто распределенной структурой данных).
Вот на скорую руку написал про текущее хранилище по запросу @qnikst
Прицепил пока сюда:
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/ncq3
В теги, что бы preview отображалось пока не смог, надо шаблон править, позже может. @qnikst (и кто угодно) пиши сюда в коменты вопросы/замечания/предложения.
Что бы иметь это у себя на localhost, нужно запустить hbs2-peer и сказать:
Прицепил пока сюда:
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/ncq3
В теги, что бы preview отображалось пока не смог, надо шаблон править, позже может. @qnikst (и кто угодно) пиши сюда в коменты вопросы/замечания/предложения.
Что бы иметь это у себя на localhost, нужно запустить hbs2-peer и сказать:
hbs2-peer poll add 4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1 lwwref 11
Но есть и плохие новости: сейчас работают ноды с двумя разными типами хранилища, и нужно писать миграцию для двух случаев. К тому же непонятно, как её тестировать. К тому же на безопасную миграцию на самой жирной ноде не хватит места на диске, а небезопасная — небезопасна.
Как бы есть СРКН, а есть мировой СРКН. Надо это помнить всегда. Чот кажется, что в перспективе перспективнее иметь очень маленький девайс с экраном и спикером с обычным линуксом на борту, чем вот это всё андроид. Такое уже есть, но пока сильно хреновое, но сама идея, что кто-то центральный решает, какой софт тебе можно иметь на твоем терминале она какая-то нездоровая. Новости всё чудесатее, прямо мимо свистит. Кажется, непопулярность решения будет только на пользу, avoid success at all costs кажется играет новыми красками - чем менее популярное решение будет, тем дольше оно проработает без проблем.
Forwarded from Bitcoin
FYI: 🟠 Google Play will ban non-custodial wallets unless developers hold a FinCEN, state banking, or MiCA license.
In the EU, MiCA rules effectively block such wallets entirely from the store.
In the EU, MiCA rules effectively block such wallets entirely from the store.
RED 2014/53/EU и то, что будет дальше — как конец телефонов. в общем-то, мне и не нужен "телефон". мне нужно звонить.
то есть не звонить, а иногда поговорить голосом.
то есть не звонить, а иногда поговорить голосом.
Залёт. В текущем формате NCQ3 и предыдущем (NCQ) ссылки хранятся в том же неймспейсе, что и прочие значения, просто они солятся с некоей строкой, которую я, к тому же, сделал уникальной для инстанса хранилища и не сохранил исходное значение хэша.
Теперь: невозможно перечислить все ссылки при проходе файлов при миграции. По счастью, hbs2-peer держит множество ссылок еще в sqlite (brains, оперативный стейт — еще один исторический факап, ща напишу) —- можно оттуда выколупать несолёные хэши, и при проходе файлов спасти хотя бы те ссылки, на которые пир подписан. Ценой довольно значительного гемора.
Вывод: надо наряду с солёными хэшами ссылок хранить их оригинальное значение на случай, если будет очередная смена формата и миграция. Надеюсь, что не будет. Идея делать соль уникальной для инстанса хранилища была ОЧЕНЬ плохой. В NCQ3 это хардкод в коде. Соль вообще нужна что бы избежать коллизий (блок -> ссылка). Хорошо, что про хранение оригинальных хэшей я понял сейчас, до выкатки NCQ3. Очевидная же мысль, но почему-то только постфактум.
Хорошая новость в том, что на конверсию ссылок в случае N реплик можно вообще забить — если пиры не мигрировать одновременно, то ссылки восстановятся т.к. все ссылки или CRDT G-Set (refchan, reflog) или CRDT LWW ( lwwref ).
Но забивать стрёмно, т.к может найтись кто-то, кто не держит реплик. Несмотря на то, что пользователей очень мало — они всё равно есть, и придется всё делать по-настоящему.
А если бы сразу захардкодил соль для ссылок — то миграция NCQ -> NCQ3 была бы просто — в каждый файл дописать M-секцию в конец, переименовать файл, записать файл в стейт.
Теперь: невозможно перечислить все ссылки при проходе файлов при миграции. По счастью, hbs2-peer держит множество ссылок еще в sqlite (brains, оперативный стейт — еще один исторический факап, ща напишу) —- можно оттуда выколупать несолёные хэши, и при проходе файлов спасти хотя бы те ссылки, на которые пир подписан. Ценой довольно значительного гемора.
Вывод: надо наряду с солёными хэшами ссылок хранить их оригинальное значение на случай, если будет очередная смена формата и миграция. Надеюсь, что не будет. Идея делать соль уникальной для инстанса хранилища была ОЧЕНЬ плохой. В NCQ3 это хардкод в коде. Соль вообще нужна что бы избежать коллизий (блок -> ссылка). Хорошо, что про хранение оригинальных хэшей я понял сейчас, до выкатки NCQ3. Очевидная же мысль, но почему-то только постфактум.
Хорошая новость в том, что на конверсию ссылок в случае N реплик можно вообще забить — если пиры не мигрировать одновременно, то ссылки восстановятся т.к. все ссылки или CRDT G-Set (refchan, reflog) или CRDT LWW ( lwwref ).
Но забивать стрёмно, т.к может найтись кто-то, кто не держит реплик. Несмотря на то, что пользователей очень мало — они всё равно есть, и придется всё делать по-настоящему.
А если бы сразу захардкодил соль для ссылок — то миграция NCQ -> NCQ3 была бы просто — в каждый файл дописать M-секцию в конец, переименовать файл, записать файл в стейт.
Про sqlite. Я люблю sqlite, он своего рода произведение искусства на многих уровнях. но надо помнить, что он медленный. Нельзя его держать в fast path нигде (хоть соблазн велик, особенно в хаскелле — всё мутабельное согнать в in-memory sqlite) . Если работать с sqlite так, что бы он работал быстро — то по сути это кэшировать всё в памяти в других структурах, то есть уходит вся простота.
Один из самых хреновых по скорости паттернов работы с sqlite — это одновременное чтение/запись, и как раз он-то и нужен в типичном случае работы с объектами hbs2: смотрим, есть ли объект, если нет — то вставляем.
Многие проблемы hbs2 решились просто выпиливанием sqlite. И со скоростью, и с консистентностью.
После перепиливания hbs2-git со стейта в sqlite на самодельную БД (SD-журнал + LSM0 индекс + файлы - снапшоты состояния для ссылок) — проблемы hbs2-git рассосались сами собой и больше не появлялись. LSM0 (сортированный массив ключей одного уровня) появился потому, что в тот момент еще ничего не было другого.
Как-то так получается, что sqlite (т.е РСУБД) поощряет использовать самые плохие практики работы с данными, потому что их легче всего использовать — и ты такой — ну об остальном позаботится движок, умные люди писали, он всё оптимизирует. Так вот — нет, он вообще ничего не оптимизирует. Наверное, я не советую его использовать даже для прототипов.
Надо сказать, что это очередной раз "мутабельное vs иммутабельное" — т.е sqlite это как бы парадигма, когда у нас мутабельные данные, а противопроложный подход — это когда мы пишем данные один раз и больше не трогаем, а индексы и стейты каждый раз переписываем полностью. Мало того, что уходит куча головняка, так еще и почему-то в итоге быстрее.
После переписывания стейта hbs2-git3 в этом стиле — не проявилось пока ни одной проблемы исходного hbs2-git (протухший стейт, удалить, пересобрать, тормоза).
Один из самых хреновых по скорости паттернов работы с sqlite — это одновременное чтение/запись, и как раз он-то и нужен в типичном случае работы с объектами hbs2: смотрим, есть ли объект, если нет — то вставляем.
Многие проблемы hbs2 решились просто выпиливанием sqlite. И со скоростью, и с консистентностью.
После перепиливания hbs2-git со стейта в sqlite на самодельную БД (SD-журнал + LSM0 индекс + файлы - снапшоты состояния для ссылок) — проблемы hbs2-git рассосались сами собой и больше не появлялись. LSM0 (сортированный массив ключей одного уровня) появился потому, что в тот момент еще ничего не было другого.
Как-то так получается, что sqlite (т.е РСУБД) поощряет использовать самые плохие практики работы с данными, потому что их легче всего использовать — и ты такой — ну об остальном позаботится движок, умные люди писали, он всё оптимизирует. Так вот — нет, он вообще ничего не оптимизирует. Наверное, я не советую его использовать даже для прототипов.
Надо сказать, что это очередной раз "мутабельное vs иммутабельное" — т.е sqlite это как бы парадигма, когда у нас мутабельные данные, а противопроложный подход — это когда мы пишем данные один раз и больше не трогаем, а индексы и стейты каждый раз переписываем полностью. Мало того, что уходит куча головняка, так еще и почему-то в итоге быстрее.
После переписывания стейта hbs2-git3 в этом стиле — не проявилось пока ни одной проблемы исходного hbs2-git (протухший стейт, удалить, пересобрать, тормоза).
Какой есть наименее всратый клиент Matrix? Я с год назад просмотрел сколько-то, захотелось вырвать себе глаза, ни один не заработал хоть сколько-то удовлетворительно. И еще какие-то имейлы спрашивают при регистрации (регистрация!! это вообще что?). Но это ладно. Есть что-то хоть сколько-то юзабельное?
Эта неделя — endurance тесты для NCQ3. Никаких больше прыжков веры. Заодно смотрю, как оно себя ведёт при нагрузке примерно похожей на реальную, для этого специально перемежаю времена большой нагрузки с временами IDLE. Кажется, уже хочется ASAP освобождать memtable — т.е заменять там кэшированные значения на ммапнутые файлы по мере записи, но до индексации. Есть несколько способов это сделать, или медленные или опасные. Но всё равно
Forwarded from Лентач
В Европе готовят законопроект об обязательной проверке переписки в мессенджерах, включая защищённые чаты.
Инициативу уже поддержали 15 из 27 стран ЕС — всё ради «борьбы с детской порнографией».
Окончательное решение планируют принять 14 октября
А что ещё случилось?
Инициативу уже поддержали 15 из 27 стран ЕС — всё ради «борьбы с детской порнографией».
Окончательное решение планируют принять 14 октября
А что ещё случилось?
Смотрю этот ваш jj и как-то много всё равно там возни. Куча непривычных команд с кракозябрами.
Кмк, система контроля версий должна вообще состоять из двух, что ли частей 1) то, что локально (история изменений) 2) то, что публикуем — и что будет растить глобальный стейт, приводя к 130+ гигабайтам репо линукса.
Я теперь делая каждый коммит гита угрызаюсь, что оно будет потом вечно засорять эфир — т.е привязка кейса "бэкап" к кейсу "публикация изменений" она какая-то неправильная. наверняка в командах с монорепами бьют по рукам за коммиты с целью просто бэкепа текущей работы, да и никто так не делает.
т.е vcs должна работать так — просто как-то (inotify? таймер) + по явной команде сохраняет изменения. что нужно трекать решает настройка - никаких git add, stage и всей этой хни.
периодически можно сказать команду типа бранч/тег/mark/pin — что бы текущее место в DAG как-то пометить.
что куда публиковать — ну опять же, есть наверное бэкап на случай (кот обоссал ноутбук) — и публикация чего-то куда-то.
в общем-то, путём добавлений тегов/марок и манифестов делается из hbs2-sync.
что хочется — так это дешевого и легкого (бесплатного) перемещения по локальной истории, ну и прозрачной работы — просто редактируешь, а vcs сам собой обеспечивается, без каких либо команд вообще
Кмк, система контроля версий должна вообще состоять из двух, что ли частей 1) то, что локально (история изменений) 2) то, что публикуем — и что будет растить глобальный стейт, приводя к 130+ гигабайтам репо линукса.
Я теперь делая каждый коммит гита угрызаюсь, что оно будет потом вечно засорять эфир — т.е привязка кейса "бэкап" к кейсу "публикация изменений" она какая-то неправильная. наверняка в командах с монорепами бьют по рукам за коммиты с целью просто бэкепа текущей работы, да и никто так не делает.
т.е vcs должна работать так — просто как-то (inotify? таймер) + по явной команде сохраняет изменения. что нужно трекать решает настройка - никаких git add, stage и всей этой хни.
периодически можно сказать команду типа бранч/тег/mark/pin — что бы текущее место в DAG как-то пометить.
что куда публиковать — ну опять же, есть наверное бэкап на случай (кот обоссал ноутбук) — и публикация чего-то куда-то.
в общем-то, путём добавлений тегов/марок и манифестов делается из hbs2-sync.
что хочется — так это дешевого и легкого (бесплатного) перемещения по локальной истории, ну и прозрачной работы — просто редактируешь, а vcs сам собой обеспечивается, без каких либо команд вообще
Я, бывало, прыгал BASE c 72-метровой ЛЭП (и ломал руку), так вот ощущения когда там наверху перелезаешь ограждение и стараешься раньше времени не упасть вниз — сопоставимы с запуском hbs2-peer с новым сторейджем с только что написанной процедурой миграции. У меня ж тестовый стенд он же продакшн, как-то неудобно hbs2-peer в нескольких инстансах держать
Если жизнь посылает тебе лимон — сделай из него регрессионный тест. Д. Карнеги
У nix - и много чего еще — discource. У radicle и мнго чего еще — zulip. У fossil scm и sqlite — конечно же свой форум, уважаю чувака, он же всё это еще и на сях пилит. Фоссил-то на сях. Я к тому, что никто ж не делает коммьюнити в вацапах или facetime, это дичь. То, что мы это делаем это в телеге — нехорошо. Я к тому, что надо бы напилить что-то типа juick только распределенное.
Тем временем,
посмотрим, где теперь прострелит.
[dmz@expert:~/w/hbs2]$ hbs2-peer fetch -p HRDcFo2PwTQkEmPPECbZivdUf788s3GumhhqtgErHhfc && hbs2 cat HRDcFo2PwTQkEmPPECbZivdUf788s3GumhhqtgErHhfc
NCQ3-PREVED-20250822
посмотрим, где теперь прострелит.
Как вот так получается, что Snapgradon/ARM - по сути телефонный SoC, андроид — это линукс, а линукс на ноутах со Snapdragon практически не работает. Или винда или макбук. Винда нот ан опшн, а mac — зловещая долина. Там буквально ВСЁ по мелочам сделано так, что вызывает вопросы — в порядке авторы или нет. Незакрывающиеся терминалы, недонастроенный баш, хоткеи которые почти — но не совсем, т.е типа надо палец на одну кнопку сдвинуть и это почти невозможно. Мышиного копирования по умолчанию нет. Понятно, что всё можно настроить, но там надо настроить буквально прямо всё. А если комп поменяется — получится его раскатать, как из flake.nix что бы все эти настройки обратно заехали? Вопрос.
Опупея с новым сторейджем для CAS движется к концу. Даже на маке заработало. и тут удачно и погода не очень и лето заканчивается, так что можно что-то прикольное сделать.
У нас есть — концепт мессенджера, веб. E2E P2P вся фигня. Вроде работает, но подозреваю много проблем из-за несвоевременного вкорячивания UI.
Что бы работало нормально без локальной ноды — надо бы научиться делать cbor пакеты на клиенте и шифровать.
Можно сделать чисто консольный прототип. Если нашлось что-то, от чего было бы легко взять фронтенд и туда подсунуть hbs2 в качестве бэкенда — было бы отлично, но я ничего такого не нашёл.
Можно сделать local-first juick — т.е по сути мессадж борду по модели твиттера ( у каждого свой канал; каждый пишет к себе; те кто подписался — становятся новыми точками раздачи). Можно допустим шарить подписки, кроме того —- можно натренировать какую-то микросетку, что бы работала, как система рекомендаций.
Подмывает сделать vcs чисто поржать — по модели "все есть меркл дерево" и посмотреть, что получится. По сути она делается добавлением "манифестов" / "чекпойнтов" в hbs2-sync но надо подумать. Нафига её делать... Ну, получу time machine для проекта, который хотел + у меня есть кейс публикации подпроектов из монорепы; можно на уровне дизайна сделать "подпроект" и манипуляцию ими.
Морду для гита мне делать не хочется. Очень много UI, очень мало профита. По сути можно синкать через hbs2-git локальный git bare repo и натравить на него любую вебморду гита. Т.е основной вектор усилий будет смещен в сторону UI и веба, кажется, это просто трата времени. По факту лично мне вебморда для гита особо не нужна. Я даже lazygit ленюсь использовать. При таких вводных вряд ли получится хорошо.
Возможно продуктивнее просто взять движок hbs2.net - статический генератор с бэкендом в CAS — немного допилить + прикрутить шаблоны и выложить как средство для публикации своих проектов + сделать какой-то каталог.
Весь hbs2.net это просто небольшая обвязка на bf6 вокруг hbs2-cli — интерпретатора для вызова функций hbs2. ну там сохранить блок/дерево/ссылку и тп.
hbs2-sync + fuse вроде тоже пилится и синхронизирован со сторейджем. Будем мержить всё вместе. Для больших каталогов (файлопомоек) без нового сторейджа оно сдохнет, а с ним нет.
Мне хочется для поржать сделать vcs, но со сторейджем я тоже думал что приключение на пару недель, чо там - в файл пишешь, из файла читаешь, LSM, всё просто.
Кажется, что ввиду общего вот этого фона правильнее двигаться в сторону борды + чуть позже к ней прикрутить приватные сообщения + сделать некий аналог KeyBase возможно.
Есть мысли?
У нас есть — концепт мессенджера, веб. E2E P2P вся фигня. Вроде работает, но подозреваю много проблем из-за несвоевременного вкорячивания UI.
Что бы работало нормально без локальной ноды — надо бы научиться делать cbor пакеты на клиенте и шифровать.
Можно сделать чисто консольный прототип. Если нашлось что-то, от чего было бы легко взять фронтенд и туда подсунуть hbs2 в качестве бэкенда — было бы отлично, но я ничего такого не нашёл.
Можно сделать local-first juick — т.е по сути мессадж борду по модели твиттера ( у каждого свой канал; каждый пишет к себе; те кто подписался — становятся новыми точками раздачи). Можно допустим шарить подписки, кроме того —- можно натренировать какую-то микросетку, что бы работала, как система рекомендаций.
Подмывает сделать vcs чисто поржать — по модели "все есть меркл дерево" и посмотреть, что получится. По сути она делается добавлением "манифестов" / "чекпойнтов" в hbs2-sync но надо подумать. Нафига её делать... Ну, получу time machine для проекта, который хотел + у меня есть кейс публикации подпроектов из монорепы; можно на уровне дизайна сделать "подпроект" и манипуляцию ими.
Морду для гита мне делать не хочется. Очень много UI, очень мало профита. По сути можно синкать через hbs2-git локальный git bare repo и натравить на него любую вебморду гита. Т.е основной вектор усилий будет смещен в сторону UI и веба, кажется, это просто трата времени. По факту лично мне вебморда для гита особо не нужна. Я даже lazygit ленюсь использовать. При таких вводных вряд ли получится хорошо.
Возможно продуктивнее просто взять движок hbs2.net - статический генератор с бэкендом в CAS — немного допилить + прикрутить шаблоны и выложить как средство для публикации своих проектов + сделать какой-то каталог.
Весь hbs2.net это просто небольшая обвязка на bf6 вокруг hbs2-cli — интерпретатора для вызова функций hbs2. ну там сохранить блок/дерево/ссылку и тп.
hbs2-sync + fuse вроде тоже пилится и синхронизирован со сторейджем. Будем мержить всё вместе. Для больших каталогов (файлопомоек) без нового сторейджа оно сдохнет, а с ним нет.
Мне хочется для поржать сделать vcs, но со сторейджем я тоже думал что приключение на пару недель, чо там - в файл пишешь, из файла читаешь, LSM, всё просто.
Кажется, что ввиду общего вот этого фона правильнее двигаться в сторону борды + чуть позже к ней прикрутить приватные сообщения + сделать некий аналог KeyBase возможно.
Есть мысли?
Уверен, что протоколом mailbox никто кроме меня не пользовался, но если что —- миграция на новый сторейдж его поломала. То есть не его, а состояние сообщений (импортировано/нет).
Как раз за счёт того, что не сохранял исходные хэши посоленных хэшей ссылок.
Починябельно; из хороших новостей — оно в целом работает.
Как раз за счёт того, что не сохранял исходные хэши посоленных хэшей ссылок.
Починябельно; из хороших новостей — оно в целом работает.