Обновить

Комментарии 16

Вот похожее, только без браузера, на скриптах и текстовых файлах.

Ну гит вообще как CRUD API недооценен.

прикольно, но предлагаю сразу оптимизацию - сообщения держать в текстах коммитов

файлы будут "тредами" и дописаватся в них будут хеш-суммы тела коммита, что бы контролировать целосность сообшений

а дальше все в рамках АПИ любого гит-сервера

економнее по ресурсам будет и доступнее для чтения - историю сообщений можно удобно смотреть "по треду" сразу с датами и прочим, в любом удобном визуализаторе или прямо в консоли.

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

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

файлы есть файлы. У меня вот сейчас рабочая репа 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, который будет работать под любую платформу, где можно запустить современные браузеры.

Web serial api конечно удобная штука для дебага ардуинок, но писать на этом промышленный hmi я бы в здравом уме не стал

Ждем, когда гитхаб выкатит новые лимиты на апи и забанит всю эту вечеринку за абьюз платформы

Бесплатный хостинг он такой, до первого массового наплыва халявщиков

Ну у гитхаба уже есть рейт лимиты, особенно публичные.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации