Комментарии 16
Вот похожее, только без браузера, на скриптах и текстовых файлах.
прикольно, но предлагаю сразу оптимизацию - сообщения держать в текстах коммитов
файлы будут "тредами" и дописаватся в них будут хеш-суммы тела коммита, что бы контролировать целосность сообшений
а дальше все в рамках АПИ любого гит-сервера
економнее по ресурсам будет и доступнее для чтения - историю сообщений можно удобно смотреть "по треду" сразу с датами и прочим, в любом удобном визуализаторе или прямо в консоли.
Но это все то еще извращение, так то можно и "чат" на базе тикетов или подобной фигни сделать что пропустит запросы с другого домена в рамках браузера
и вот это интересное направление в том плане что если было единого готовое решение, а "анонимусы" уже просто согласоывают канал и ключ шифрования - дальше все уже хранится в тех же коментариях на пикабу))
Изначально шутка была вообще "да мы прямо в репозитории гитхаба чат устроим в пулл реквесте", но это неудобно масштабировать. А файловая структура дает невероятную гибкость, и позволяет бесшовно переносить чат между репозиториями хоть форком, хоть копипастом.
файлы есть файлы. У меня вот сейчас рабочая репа 72гб просто потому что огромное количество кода годами лопатит сотни людей ежедневно
гит сам по себе "оптимально" складывает историю коммитов, а вот сами файлы при изменениях "копипастятся" если это не дозапись что бы держать горячие версии. Да там можно оптимизировать и сжимать но опять упираемся в файлы, а история коммитов вот она
а за миграцию - все уже давно создано для переноса и достаточно скачать себе *.git архив что бы получить репу со всей историей
к слову - для тех кому не нужна вся история, указываешь глубину в 1 тебе быстро грузит актуальное. А ведь еще сверху можно безшовно заполирвоать GPG, нормальные аватары и тд
единое что - гит историю можно править как угодно что является минусом для чат-движка, но в случае доверия ко всем сторонам обмена и без критичности этого самого обмена такое катит.
Но на гит как чат переходить это вообще за рамки - это должны забанить вообще все, но тогда и гит тоже забанят я более чем уверен, ведь он "не нужон"
Да, commit messages как storage — это красивая степень извращения, согласен.
Но я специально оставил сообщения файлами. Для Macaroni важнее не оптимальность git storage, а переносимость .macaroni/ как обычной структуры данных. Её можно форкнуть, скопировать, положить в другой repository, прочитать через Contents API, забрать архивом, перенести между GitHub/GitLab/Gitea/Forgejo/GitVerse — и сам protocol от этого не меняется.
Если сообщение живёт в commit message, commit становится сразу всем: envelope, storage unit, audit log, thread model и delivery mechanism. Это смешнее, но сильнее связывает чат с конкретным поведением git-host API и историей git. А главное — там уже начинает пропадать необходимость в прослойке в виде HTML-файла, и проект концептуально разваливается.
В текущей модели commit — просто транспортная история. Сегодня один message на commit, завтра batch, retry, squash, storage branch, другой provider — .macaroni/ всё равно остаётся .macaroni/.
Файлы тупее, зато эта тупость переносимая.
А вот идея “любой публичный CRUD с CORS как message bus” — да, это отдельная прекрасная бездна. Тут уже не git as chat, а “комментарии на чём угодно как transport layer”. И это, возможно, даже страшнее.
Я после реализации мессенджера уже несколько дней размышляю над сайд-эффектами, которые порождает такой класс приложений. Там натурально ящик Пандоры.
так в том и суть - можно и без html-прослойки, прямо в консоли красноглазить)))
вообще лучшее для такого это строить на базе торентов, вот там реалтайм чаты возможны (я даже видел что топохожее)
в наш век переносимость истории чатов это скорее минус чем плюс. Сохранить персонально для себя важно, но важнее переносимая "точка синхронизации" чем самосодержимое чатов, ведь для связи важнее возможность связатся, а не то что обсуждалось ранее (иначе бы емейлы были б вершиной)
а за сайд-еффекты - это все уже давно облизано и используется. Закладчики одно время пикабу использовали с коментариями в мертвых постах что бы публиковать доступ "в открытом виде" с возможностью "техподдержки вреальном времени".
потому вы не придумали ничего нового плюс ваше решение таки замороченное, есть проще способы "опасного общения" где не нужно вообще кодить
Да, если цель — "опасное общение", есть способы проще и старше: комментарии, pastebin, shared google docs, торренты, IRC и т.д. Фидонет тоже жив и отлично передаёт шифрованные сообщения.
Но Macaroni не про "самый практичный способ спрятать сообщения". Это про велосипед на коленке, который едет. И на него любой желающий может поставить треугольные колёса вместо квадратных, потому что архитектура позволяет. На экзистенциальный вопрос "зачем" у меня ответа нет.
Держать данные в коммитах это уже совсем наркомания. Ты потом эту репу даже склонировать нормально не сможешь из-за раздутой истории
Я не знаю зачем тебе это, но продолжай (☉.☉)
Browser API вообще вещь недооцененная. Там есть все, от доступа к com-порту до 3d графики и gpu-вычислениям. И это все кросс-платформенное из коробки. Т.е. теоретически можно например сделать панель управления каким-нибудь чпу-станком с отображением в реальном времени всех актуаторов и это все завернуть в HTML, который будет работать под любую платформу, где можно запустить современные браузеры.
Ждем, когда гитхаб выкатит новые лимиты на апи и забанит всю эту вечеринку за абьюз платформы
Бесплатный хостинг он такой, до первого массового наплыва халявщиков


Мессенджер в одном HTML-файле: Git как storage, browser как runtime