Ну что же. Это случилось. 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-ы.

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

pull-request (он же патч) может быть сделан как git bundle, при этом всю необходимую информацию можно поместить в него же, в отдельную ссылку git, которую можно добавить в этот bundle. таким образом, pull request становится самодостаточным объектом, который имеет смысл даже отдельно от offgrid, а будучи добавленный в offgrid он получает уникальный хэш, на который можно ссылаться и по которому его можно вытащить. Тогда это будет работать как с офгридом, так и без него. Как по мне это win. #offgrid #offgridgit

JSON убог, но таков JSON

#offgrid Допустим, pull request это просто сообщение, в котором указано, где майнтейнеру взять изменения, которые смержить к себе. интересно,
как определять, что PR действительно смержен. Наличие коммита(ов) из PR на мастере(мастере?) ? Нет, ведь мейнтейнер мог сделать merge —squash —no-commit и взять всё одним коммитом. Наличием tree объекта на мастере (мастере?) идентичного тому tree, для которого делался PR? Ближе. Но на предыдущем шаге майнтенер мог добавить каких-то своих файлов, но делают так редко. Ок, допустим, наличие на мастере (мастере?) tree объекта, в который входят все блобы из tree объекта коммита PR. Хотя он майнтейнер в процессе мержа мог файлы не менять, а перетасовать их по каталогам, но обычно так не делают. Ну допустим, с некоторыми натяжками можно. Теперь про мастер. Всё еще смешнее. Название бранча в гите - это просто название файла в .git/refs/heads. Оно может совершенно произвольно меняться и это никак не трекается в самом гите. Но трекается в offgrid-git в силу его природы.

Таким образом, критерием приёмки PR можно считать тот факт, что в топике (репозитории), куда направлялся данный PR, существует commit, которому предшествует commit на который делался PR, и существует бранч, имя которого совпадает с тем, который указан в PR (допустим, master) и который существовал в какой-то момент после создания PR (это значит. что существует reference, name = master и в зависимостях того reference есть коммит, на который делался PR). Если всё это выполняется, можно сказать, что PR смержен. Наверное.

Пришла в голову мысль, что если скрипты создания базы развернуть в поток операций создания колонок ( ALTER TABLE X ADD COLUMN ... ); - то каждую такую операцию легко сделать идемпотентной, а процедуру миграции базы - тривиальной и вообще она типа становится CRDT но это не точно

Что-то я застрял с sql-ным dsl-е. Первоначальная идея была сделать маленький слой над sqlite-simple, что бы не писать руками бесконечные примитивные - запросы - сделать простой DSL для генерации.

DSL сделать на уровне типов, что бы интерпретаторы писать тайпклассами - ну, примерно, как в серванте. До определенной стадии получилось, особенно нравится то, что не нужно, как в persistent описывать "таблицы" - а только те поля, которые используешь завернуть в newtype и задать для них колонку таблицы через тайпкласс.

Для простых запросов работает отлично. Для постгреса этого и хватает - любой сложный запрос это, считай, view - pg отлично работает с view + это даёт еще дополнительных плюшек.

Для sqlite лучше бы уметь делать вложенные запросы - и как-то это надо уже композить на уровне типов. В sql-ных запросах полно опциональных вещей, и как вот их подпихнуть в ту конструкцию, что тут на картинке (в коменте, в пост не влезло)?

Оно мало того, что позволяет разные запросы разбирать разными тайпклассами, так оно еще и типизирует и колонки запроса, и возвращаемое значение. Бойлерплейта для простых запросов получается мало и вообще прослойка над raw sql получается очень тонкая.

Но не понимаю, как хорошо сделать этот DSL расширяемым. Добавить туда всякие там limit, order, group by и так далее.

К моноидальным и монадическим DSL здесь не хочется скатываться, получится очень шумно + некорректно. Но как сделать нормально не пойму.

Очень не хочется тащить в проект persistent, слишком много там всего ненужного делается. beam вообще шляпа какая-то. #haskell #sql #edsl