#offgrid ссылка на репо offgrid-git (идут тяжелые работы!) 3CAaSFxhHVQZjeM2wEq1NXRQkZgK9Mccust8qzv6X1pC

Смотришь API иной библиотеки и понимаешь, что в этом бизнесе очень много умалишенных

Клонирует, пушит, фетчит из/в offgrid. Теперь можно его сделать self-hosted наконец. В процессе узнал много интересного про git, в частности есть вопросы к его инжинирингу, я бы даже назвал это в некотором роде провалами. Например, сломать в гите бранч вообще как нечего делать, так как ссылки-то в репо - мутабельные, а push объектом не является, это действие. С оффгридом же можно видеть всю историю изменений ссылок - когда, кто и как менял. И в принципе легко откатить к любому предыдущему состоянию. Не обязательно будет маниакально сохранять бранчи перед потенциально опасными операциями. Ну как бы там ни было, теперь хоть можно нормально совместно работать над оффгридом, без приседаний с настройками yggdrasil и т.п. Без гитхабов. Ну а посмотреть какой-то документ по его хэшу, с тем, что это просто файл, закоммиченный хоть куда-нибудь, лишь бы этот топик распространялся нодами - уже можно:
offgrid cat <hash>. Запушил в общий топик - блоб есть у всех.

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

Ну что же. Это случилось. offgrid теперь self-hosted

Первое, что нужно сделать сейчас - это механизм PR. Второе - тикеты.
PR это суть предложение замержить к себе изменения, сделанные кем-то
еще. В случае offgrid-git это будет просто блок (файл), в котором указан
бранч + git хэш откуда, бранч + git hash - куда, описание PR, возможно, какие-то
аттачменты (картинки?).

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

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

Т.е Боб фетчит ветку гита из какого-то репозитория (топика) себе. Работает-работает,
потом пушит в какой-то еще топик - может быть, даже свой.

Алиса тоже подписана на этот топик, все объекты к ней поэтому приедут.

Потом куда-то приедет и сам PR - либо в какой-то специальный топик, либо
вообще в любой — главное, если она знает хэш этого PR и у неё есть доступ
ко всем нужным объектам - она сможет его смержить.

Если она является майнтейнером какого-то апстрима - то потом туда и зальёт.

Побочным эффектом является то, что если не принимать специльных мер,
то PR приедет всем подписчикам и они могут его смержить и себе тоже.

Ну и пусть, в принципе.

Эта история с offgrid + "распределенный git" - нечто, что я хотел много лет. Может, десять. Ну т.е я не знал, как должен быть устроен именно offgrid, да и названия такого еще не было. Несколько раз подходил к снаряду, пытаясь сделать "распределенный гит". Отвергал, как что нечто, что слишком сложное (демоны, сеть, консенсус - казалось, что оно того не стоит). Но эта была та планка, которую надо было перепрыгнуть, что бы стало нормально. Писать это всё распределённое ради только гита рука не поднималось. Другое дело, когда вся эта сложная история вынесена в какую-то ноду с ручками, и есть набор подходящих примитивов, и с этим всем можно делать всякое. git-remote-offgrid до работающего состояния написан реально-то за неделю, при наличии этого всего. Удивительно, что набором примитивов является, на каком-то уровне, старая добрая фидошка - эхи и сообщения. Засунутая в торренты. С merkle деревьями и госсипом. Как же меня таращит от того, что я хотел много лет (распределенный багтрекер еще + PR-без гита) начинает воплощаться

Появился некий сервис sourcehut.org - типа, аналог гитхаба, только без (...) ? Интересен он тем, что его поддержку я обнаружил в nix, размышляя над тем, как туда воткнуть поддержку offgrid. Новый сервис это хорошо, но слишком поздно. Интернет развален говноедами, сетевая нейтральность не более, чем анекдот из прошлого. Если где-то у тебя спрашивают логин или там имейл - как правило, надо разворачиваться и уходить. Тем более, что имейл теперь это такой же сервис от корпораций. А где корпорации, там и говноеды, причем буквально - теперь же публичные комании обязаны иметь в составе директоров говноедов. Был такой анекдот —- "... пока это не стало обязательным". Так вот, стало.

Верно ли, что если понять, как устроено хранилище того же самого pine (свалка файлов в формате miltipart/mime) — то можно поиметь уже обмен сообщениями нахаляву? Пойду-ка посмотрю. Там, по моему, какой-то прям стандартный формат есть unix mailbox или что-то вроде того

А что на маке вместо FUSE ?

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

#offgrid пилим систему прав/подписок/криптоподписок. в offgrid-git + еще отдельная система прав

кстати, понял, что не знаю, как коротко охарактеризовать offgrid. Постблокчейновый торрент с паб/сабом? Распределенный CAS с подписками? новый фидонет?

С этой вот сложностью такая двоякая ситуация. Есть вот сервант (servant). Довольно сложный для первого раза или как отвыкнешь. Думаешь такой - возьму-ка я scotty что бы микровебню написать. Но тут есть реальный риск, что через какое-то время будешь плюясь перетаскивать все обратно на сервант. Тоже самое как документами/презентациями - латех подзабыл, дай-ка быстро нашлёпаю в Google Draw. Через несколько часов обнаруживаешь себя гуглящим настройки beamer и вспоминающим tikz. ПОТОМУ ЧТО В Draw не добавить в нужном месте коннектор к фигуре и стрелку к ней под неотвратительным углом не подвести или еще что.

git dumb http. теперь никсовые зависимости можно таскать из оффгрида тоже

твитор будет децентрализованным! тогда я в него вернусь

#offgrid работы по ACL пока задерживаются из-за работ по стабилизации. тем временем подпилил еще немного offgrid-git, ускорил вычисление зависимостей и сделал локальные ACL (пока что не публикуются в топик, думаю, как сделать лучше)

а вот были какие-то метавселенные. чо там как?

Оказалось, что offgrid-git вполне нормально работает с git-bug, bug tracker, который свою базу держит в формате репозиториев гита.

Сам git-bug устроен довольно спорно - по сути, на каждый bug он делает git reference, то есть файл, то есть мутабельный ключ.

Так-то может и норм, но если у вас миллион багов, то в каталоге .git/refs/bugs/ будет миллион файлов.

Плюсом git bug является то, что он жив - последние коммиты 4 дня назад.

Еще минус - там всё время надо отдельно делать git bug pull.

Если бы баги могли жить просто в топиках офгрида, то они бы и подъезжали бы сами.

Теперь вот непростая ситуация - простой багтрекер был в планах, git bug работает не совсем так, как хотелось бы. Но зато уже есть и работает.

Не, ну так-то надо брать, хотя бы для себя. Это же лучше, чем ничего, а мы баги сейчас в канале в телеграме трекаем.

Как они (git-bug) могли бы сделать лучше.

Один ref = один "канал", туда постятся "коммиты", "коммиты" представляют собой просто команды, изменяющие state: создать баг, выставить поле X бага в значение Y. Тогда история бранча = лог изменений.

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

История сканится, текущий стейт держится в sqlite, если его грохнуть - то всегда можно пересоздать из лога, ничего страшного, по сути это просто кэш.

С точки зрения UX пользователя ничего бы не поменялось: "не засоряет репозиторий" в еще большей степени, чем текущий дизайн.

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

Здесь же (в git-bug) вся мета хранится в формате базы git и пользователю не докучает, ну кроме того, что плодятся ref-ы.

Можно было лучше, в общем. Но лучше, чем было до того (и умерло, пока все такие системы помирают, хотя тикеты ведь логично держать вместе с кодом)