Во сколько биткоинов оцениваете вашу борду?

Буду строить поиск постов по сообщению, теме. Срок - до месяца.

Уже есть такое: заходишь на https://pissychan.oxore.net/?limit=88005553535 и делаешь поиск по странице.

Посмотрим, как ты это будешь делать при двух-трёхста тысяч постов.

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

Приношу извинения, если ты об этом способе и без того в курсе и я ничего нового не рассказал.

Рано или поздно мне придётся установить лимит на количество постов, возвращаемых фидом, т.к. в противном случае я перестану умещаться по памяти.

Изменения:

• Теперь при открытии т.н. "мета-доски", то есть когда вы конкатенируете доски примерно так scheoble.xyz/board/t+mod; так вот, в данном случае больше не будет отображаться форма создания треда. Она была нерабочей, а делать возможность запостить тред через селектор досок лень. Сходи на конкретную доску и создай!

• Если твой монитор достаточно широк - в правом углу Шизочана будет виджет с радиостанцией. Proof-of-concept, будет улучшаться.

Посты из радио-треда теперь исключаются к показу на фиде, что использует Писсичан.

Парсер youtube-ссылок улучшен, теперь он вырезает какой-то там добавляемый параметр si.

https://github.com/U-Me-Chan/umechan/commit/49d8bfbb44bbe0d818ba9bc15e9b99f6f0060f60

https://github.com/U-Me-Chan/umechan/commit/9127794dc32b6ab80a6ca0b7d928908ac3403faa

Когда улучшат постинг?

Что с ним не так?

Скоро появится openapi-спецификация -- я нашёл либу, которая умеет за меня её генерировать.

и че с ней делать?

Тебе - ничего.

мы дожили, чан!

Я хочу выпилить первую версию API в пользу второй. Что нам сейчас мешает это сделать? Кугиклабы, писсичаны и прочие клиенты - рассказывайте, почему не перешли полностью на /api/v2?

Потому и спрашиваю.

Скорее меня интересует: что отламывать нельзя, чего не хватает.

Хочу отломать всё, что на /api/.

⬛⬛⬛⬛⬛⬛⬛⬛⬛

Данные удалены по причине: Unrelated

Особенно /api/v2/

⬛⬛⬛⬛⬛⬛⬛⬛⬛

Данные удалены по причине: Unrelated

⬛⬛⬛⬛⬛⬛⬛⬛⬛

Данные удалены по причине: Unrelated

⬛⬛⬛⬛⬛⬛⬛⬛⬛

Данные удалены по причине: Unrelated

Отломаю первую версию, бекпортну удаление постов во вторую.

Будет:

• Много новых фильтров .

• OpenAPI-спека.

• Разуплотнён всякий кал в кодовой базе.

В целом фронтендам приготовиться перекатываться на /api/v2.

До конца месяца прошу всех перекатиться на вторую версию API.

Отламывай прям ща. Фиксы запушим по факту. Должно получиться фаново!

umechan-opti перекатился.

• Почему так долго ждать фич? Я сосредоточен на рефакторинге, и сложно быстро переключаться, не считая рабкоты.

• Что ожидать от рефакторинга? Более совершенную архитектуру, вдохновлённую Clean Architecture, Hexagonal Architecure, Domain Driven Design и Command and Query Responsibility Segregation. В планах завести больше транспортов, чем один HTTP, например. Привлечь участников проекта к контрибуциям в серверную часть без сопутствующей на данный момент боли.

• Как долго это будет продолжаться?! Я думаю, основной концепт будет готов к концу месяца.

• Как это скажется на работе чана? В ближайшее время - никак. На днях починю удаление постов для второй версии API, вырежу код для первой версии.

• Чем занят сейчас? По сути готова доменная часть, большая ебля сейчас со всякими shared-приколюхами.

• А можно посмотреть? Можно. В конце недели я заведу ветку, запощу её в этот тред.

Спасибо за ожидание.

https://github.com/U-Me-Chan/umechan/pull/41

Что изменилось:

• Теперь запросы к первой версии API недоступны. Использовать версию 2.

• Для версии API 2 реализовано удаление поста по паролю.

• Для обратной совместимости на некоторое время оставлен маршрут /api/board/all. Это не панацея, призываю владельца перекатиться на список тредов с последними реплаями вместо ленты постов.

• Любые сущности, использующие форматирование даты и времени, могут использовать заданный часовой пояс. Для этого к запросу следует добавлять параметр timezone вида Europe/Ulyanovsk.

• Система событий была заферакторена.

• Маршрут /api/v2/events в теле ответа возвращает свойство events заместо ошибочного posts.

• Теперь счётчики доски обновляются при событии PK\Events\Event\EventType::BoardUpdateTriggered. Дополнительной информации об этом в списке событий на данный момент нет. Первое время они будут нулевые, т.к. теперь их значение вынесено в отдельные поля схемы таблицы досок. Ранее они подсчитывались в рантайме на каждый запрос, что было крайне неудобно при реализации, и накладывало некоторые расходы.

Любые предложения и замечания прошу писать в этот PR, либо в тред писсикаки на чане.

Зачётно навалил!

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

Что я вижу:

• Можно залить готовый баннер.

• Можно получить случайный баннер.

• Баннеры можно тегать, чтобы получать случайный из конкретной коллекции.

Непонятно, как модерировать баннеры. Выдать всем владельцам фронтендов доступы в некую админку, где они смогут аппрувить либо удалять баннеры?

Да и вообще, нужно ли?

Делой. Ноооо, я не знаю. В том плане, это же статика, можно залить всякое на файлстор, и просто в коде указать урлы.

Да, но при добавлении нового баннера придётся эти урлы вписывать. А тут есть некий /banners/random, который можно дёргать.

в писсикаку встроить кмк норм?

В инфраструктуру - ага, можно. После введения в эксплуатацию фиксов к второй версии API попробую набросать концепт.

Реквестирую, крч, в писсикаку рефакторинг ссылок. Щас там регулярками вырезаются пикчи и ютубо-ссылки, я же предлагаю вкрутить AST под Markdown (смотреть пикрил). Можно будет ссылочки просто из древа брать и не поддерживать регулярочки. (я помню там были какие-то багульки)

Ты предлагаешь AST-дерево для каждого запроса телу поста строить?

А, бля, я забыл что в PHP нельзя в global закешить...

Вопрос вообще не про кеш, кеш можно нарулить как стандартными средствами, так и внешним хранилищем с шаблоном "Цепочка обязанностей".

Вопрос: мы хотим на сервере разбирать тело поста и считать такую разметку эталонной? Сейчас как бы у нас либерализм, и каждый разбирает как хочет. Писсичан, к примеру, вообще не пользуется ни медиа, ни транкатед-мессаджом - самостоятельно рендерит весь мракдаун.

Ну это, эталоном у всех клиентов является пихать пикрилы в текст, как MD-ссылки на оригинал, и с превьюшкой в ссылке. Я вот даже походил по исходникам, дабы проверить.

И тут дело не в сообщении, его я не предлагаю никак менять. Я про формирование поля media: если мы сообщение разбираем в AST-дерево, то формирование media и trunkated получается реализовать без регулярок. Вот, посмотри сам: https://github.com/kugimiya/epds/blob/main/src/core/dtos/PostDto/utils.ts#L14

Что ж, когда настанет момент и я разберусь с парсерами в AST. Не хочу тащить в писсикаку то, что не понимаю.

В ветке v2, посвящённой отламыванию первой версии API и патчам ко второй версии, начал описывать спецификацию в формате OpenAPI.

Что делать при удалении ОП-поста?

Сносить весь тред? Затирать ОП-пост?

Если мы сносим весь тред, требуется ли в событиях указывать тот факт, что ответы на ОП-пост тоже удалены?

Странный вопрос. Сейчас же все удаления - это затирка. Вот и решение, затирать.

Оке.

Последние изменения:

• Чан: API: При ответе в нить с верифицированным именем ОП-поста слетала метка верификации последнего, исправлено.

• Радио: Метрики: Зарефакторен код, увеличивающий оценку при прослушивании трека.

• Шизочан: Не работала сажа в тредах, исправлено.

• Шизочан: Радио-виджет: Теперь установленная громкость сохраняется в локальное хранилище браузера.

• Шизочан: Теперь введённое имя постера сохраняется для последующих постов.

• Шизочан: Форма постинга: Теперь в форме для файлов работают Drag-n-Drop и вставка из буфера обмена.

• Файлстор: Список доступных форматов файлов расширен следующими: MP4, WebM.

• Шизочан: Радио-виджет: Реализована возможность поиска и заказа композиции в очередь.

Забыл добавить: появилась возможность прикреплять треды к верху доски, работает на любом клиенте чана, использующим в качестве источника оригинальное API. Прикрепление осуществляется в ручном режиме.

• Появилась страница документации API Pissykaka - https://scheoble.xyz/api/v2/_/redoc.html

• Появилась OpenAPI-спецификация в формате JSON - https://scheoble.xyz/api/v2/_/openapi.json

• Добавлен признак достижения тредом бамплимита - https://github.com/U-Me-Chan/umechan/issues/39

• При запросе списка тредов для досок или при запросе треда теперь возвращается список досок - https://github.com/U-Me-Chan/umechan/issues/40

• Добавлен признак закреплённого треда - https://github.com/U-Me-Chan/umechan/issues/96

• Pissykaka была задеплоена с library/php:8.4-fpm.

По репортам проверенных комрадов были сделаны исправления:

• Список досок различался для разных маршрутов, приведено в единое состояние - https://github.com/U-Me-Chan/umechan/issues/101

Произошла борьба за производительность API чана.

• Было сокращено время выполнения запросов за счёт сокращения I/O операций.

• Было добавлено кеширование результатов запросов на чтение.

https://github.com/U-Me-Chan/umechan/commit/fbca6a0d8ced04e77cbb3e2c0953a9796cfe260a

https://github.com/U-Me-Chan/umechan/commit/035427a5d544ceec32e63501061abba89eda5230

Также почистил конфигурации nginx'ов, удалив ошибочные директивы.

https://github.com/U-Me-Chan/umechan/commit/fa08cfd7b87a9b3154d1e0e4839cd1a8d4900644

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

Продолжается битва за низкое время ответа сервера. Плюс выполнены минорные апдейты Шизочана.

• Устранил разности в наименовании методов и/или свойств - https://github.com/U-Me-Chan/umechan/commit/510249acd968ac5ab600fa000b43f9ad23ae9183

• Добавлена конфигурация для внешней отладки серверной части чана - https://github.com/U-Me-Chan/umechan/commit/f24f125a40f0f631a3046a2a77a9ec0c6ce79cf4

• Улучшено время отклика за счёт ещё большего сокращения операций I/O и добавления индекса для часто сортируемой колонки - https://github.com/U-Me-Chan/umechan/commit/718ee1bef3442c170b859e5b1be2b95f8c9f9fff

• Чуток порефакторил структуру клиентского приложения - https://github.com/U-Me-Chan/umechan/commit/a2ddc531e44d0742038a6248229b926d4ba91ebe

Багофиксы по горячим следам.

• Удалён лишний JOIN при запросе данных треда, что вызывало множественное копирование ОП-поста в треде - https://github.com/U-Me-Chan/umechan/commit/ceccdef62c0b39fecd0e8ea49451fa76689c80c7

Думаю, теперь я займусь плотнее производительностью процесса обновления БД радиостанции. Сейчас это происходит примерно за 1.5 часа при 40к треках, и хотелось бы быстрее.

Из вариантов перенести БД радиостанции на SSD, ибо сейчас вся библиотека лежит на HDD. Но, следует проверить, а точно ли я упираюсь в скорость доступа к диску? Сомнительно.

Слегка уменьшил время за счёт анализа запросов к БД и добавления индексов.

В планах, во-первых, сделать параллельные воркеры. Во-вторых, попробовать хранить last_modified хотя бы директорий, чтобы сканировать только изменённые.

Возможно, это и смысла не имеет, но дрочиться в графики приятно.

Никогда не стоит забывать о порядке сортировки в РСУБД!

• Липкие нити не прилипали к верху доски, исправлено - https://github.com/U-Me-Chan/umechan/commit/855e93816f72282fe9d143d7efa406809caa1400

Я не смог воспроизвести старую проблему, но добавил возможность указывать имя для превью ссылки медиа. Заодно прокачал парсеры медиа - теперь поддерживает Youtube Shorts, вырезая вездесущий параметр si и показывая превью.

https://github.com/U-Me-Chan/umechan/issues/28

https://github.com/U-Me-Chan/umechan/commit/1e4cbc2cc3a8dff51f0b6f8e61f8a61aecdc9f78

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

Я улучшил парсер, выпилив многоступенчатый replace.

https://github.com/U-Me-Chan/umechan/commit/a636fdbf308ab73d816a010981d8068a9ffe1879

Теперь сконфигурировать максимальный размер POST-запроса стало проще, есть единый источник информации в виде .env - https://github.com/U-Me-Chan/umechan/issues/103

Реализован механизм восстановления данных постов из дампа epds - https://github.com/U-Me-Chan/umechan/commit/c378c52af9096b94113f53b92a99bc2d38d6c1d2

Добавлена возможность ставить в очередь воспроизведения радио 10 псевдослучайных треков из определённого плейлиста, пока в тестовом виде - https://github.com/U-Me-Chan/umechan/commit/655c6e38c67fc721cf0701af10942ddc93d37b57

Улучшено визуальное отображение состояния нитей на досках - https://github.com/U-Me-Chan/umechan/commit/6ed31cf6702302acd44c709bb8e672c7a2a46a00

Добавлена консольная команда для закрепления треда вверху доски - https://github.com/U-Me-Chan/umechan/commit/aac8d3dc4f73ef9dd82a2f6f4769f1e0a5aa16c7

Код клиента чана был улучшен: добавлено больше переиспользуемости компонентов, исправлены визуальные недочёты, сепарированы компоненты и страницы - https://github.com/U-Me-Chan/umechan/commit/0e0ea324334b8e450ffce72d056e2a98c76ea3a6

Все сервисы теперь используют PHP 8.4.

Отображение информации о доске нити было сломано на странице просмотра нити, исправил - https://github.com/U-Me-Chan/umechan/issues/107

Кугичка, ответь на вопрос в ишью репо.

Так, сегодня хочу развернуть тестовую лабораторию с двумя IPFS-нодами, чтобы в ходе эксперимента выяснить, насколько данное решение подходит для реализации распределённого файлстора.

Как это могло бы работать в условиях хранения данных файлстора в IPFS, при условии, что у нас есть нода R и нода K:

• Пользователь заливает файл на ноду R. Этот файл закрепляется(pin) этой нодой.

• Файл уже доступен внутри сети любому клиенту IPFS.

• Файл уже доступен через публичные шлюзы или публичный шлюз R-ноды, равно как и публичный шлюз K-ноды может его отдать, если успеет найти за таймаут, хех.

• R-нода по какому-то каналу связи, те же очереди сообщений, уведомляет ноду K о новом файле с таким хешем.

• K-нода выкачивает данный файл к себе и закрепляет его.

• Теперь файл доступен на обоих нодах + некоторых публичных нодах, которые закешировали его.

Если нода R упала - дистрибуцией файла занимается нода K. Если наших обеих нод нет - файлы могут извлекаться из кеша публичных нод IPFS, но необязательно - т.к. со временем любая IPFS-нода очищает кеш передаваемых блоков, что этой нодой не закреплены.

Файл может удалить одна нода, но он будет доступен на другой аналогично кейсу с падением ноды/всех нод.

В принципе можно сделать private-ipfs хранищиле, если мы очистим bootstrap-список нод и добавим свои ноды. Тогда нам будет недоступен контент IPFS, её сеть для распределённого доступа и наши файлы не будут кешироваться публичными нодами, зато это меньше трафика, места на диске.

Размер блока, насколько я понял, фиксированный и составляет 256 кбайт + 4 байта, что для пользователей HDD звучит грустно.

В целом, поиск файла внутри сети больше минуты у меня не занимал.

Алсо, IPFS реализует дедупликацию заливаемых файлов, т.к. использует хеш содержимого как идентификатор.

Следует так же заметить, что CID это не именно хеш файла, и они совпадать не будут.

Нашёл PHP-либу к Kubo RPC API, которая умеет добавлять и получать файлы из IPFS-хранилища. Выглядит корявенько, работает, расширять достаточно легко, promise-based.

Попробую тогда сейчас реализовать кластер из нод с пруф-оф-концепт синхронизацией.

В IPFS есть разница между MFS и UnixFS. Если вы используете ipfs-webui, то он добавляет файлы в MFS, и именно её он показывает.

Но если добавлять файл через Kubo CLI как ipfs add file или с помощью Kugo RPC API /api/v0/add, то он не будет отображаться в вебне.

Чтобы он туда попал, необходимо сделать /api/v0/files/cp?arg=/ipfs/[hash]&arg=/, тогда будет создана ссылка в MFS и файл будет отображаться в вебне.

Хуйню написал. UnixFS тут вообще не причём, она про другое.

ЧСХ, не хуйню.

вебня кладёт в MFS

ipfs add кладёт в UnixFS структуру Merkle DAG, такой специальный граф блоков.

Почитал побольше за Merkle DAG и стало интересно по приколу поверх этого треды сделать. Но не буду.

Вроде смог перекатить идентификаторы постов на 16-значный формат(unixtime with microseconds), и оно работает при первых тестах.

Теперь надо бы решить, буду ли я конвертить старые идентификаторы в новый формат?

• Это решит проблему сквозной нумерации постов, при которой можно перебором узнать идентификатор поста со скрытодоски. С новым идентификатором это сложнее по времени.

• Это сломает существующие ссылки на посты. Алиасы? Ох...

• Оставить как есть и класть новые рядом? Тогда пункт 1.

Рассудите, если интересно.

Предлагаю не париться, поломав ссылки при перекоте на новый механизм id. Но, сохранить прежние рядом как legacy_id, чтобы в случае чего можно было прикрутить «алиасы».

Работает и ладно, смысл изобретать новый велосепек?

Чекай тред про распределенный чан.

Так-то идея.

Причём алиасы сделать только для публичных разделов, хуле.

Именно.

Я долго ебался с миграцией - и плюнул. Сделал вообще так: посты до обновления сохранят старый идентификатор, новые будут с новым. Как такая идея?

Ещё порефакторил шизочановый фронтенд, попутно попробовав запилить превью поста по ховеру на >>123-ссылку. Пока реализовано через компонент Modal от Buefy, и работает не совсем так, как хочу - модалка раскрывается по центру, и сходу спозиционировать её не выходит.

Алсо, ещё для превью видео-файлов внедрил синюю рамку заместо уродливой надписи. Пикрейлейтед. Рассудите. Добавлять какую-то иконку с помощью Imagick я не смог, да и нужно ли?

На всякий пожарный форкнул репо библиотеки для работы с MPD - сейчас она используется в радио-стеке, автор либы её забросил. Будет мне мотивация либо её вести самому, либо закончить реализацию своей вещалки для ICY-протокола.

https://github.com/ridouchire/MphpD

Не выйдет. CID треда будет меняться каждый раз, когда он будет обновляться. Сontent-addressed data в целом не про изменяемые данные.

Конечно, есть IPNS - но в таком случае Web3 снова упёрся в централизованный источник имён. Sad but true.

IPNS как хранитель индекса связей постов и досок.

Круто, но зачем?

Чтобы чан был готовым к web 3.

Изменения:

• У постов идентификатор имеет тип bigint и содержит текущую метку с микросекундами. Старые посты остались со старыми номерами.

• Вокруг превью видео-файлов теперь рисуется синяя рамка вместо корявой надписи "Video File".

• Добавлена поддержка файлов с mimetype video/quicktime.

• Небольшие косметические изменения на Шизочане.

Web 3 поверх коммерческих централизованных сетей обмена трафиком - это какой-то прикол.

Перекатил все PHP-сервисы на использование alpine-образов заместо ubuntu. Сократил конечные размеры примерно в 50-100%.

Плюс пришлось заюзать оффбилд library/composer:latest, чтобы оттуда добывать composer, ибо сайт getcomposer.org периодически недоступен по неизвестной причине окромя как через ДЫРку.

Смешной костыль для решения смешной проблемы - https://github.com/U-Me-Chan/umechan/commit/3478944f9386d70e0cb24f67f94e9cd6825faadc

Проблема выглядела так.

• Тред создан 10 числа.

• В него добавляют посты, созданные 3-7 числа.

• При извлечении треда и его реплаев из БД порядок сортировки был основан на колонке id по умолчанию, что приводило к бесконечной загрузке треда с Шизочана.

Планы на ближайшее время по чану:

• Починить парсер на Шизочане.

• Сделать блокировку тредов на ответ - для прикреплённых нитей с правилами, например. Уже занят.

• Разобраться с возвращаемыми сообщениями об ошибках, улучшить валидацию входящих параметров и всё такое.

• Оптимизировать потребление ОЗУ в кеше ответов, продолжать сокращать I/O-операции при запросах.

• Улучшить файлстор: БД файлов, дедупликация, удаление файлов без использования в посте(привет Хоме), теги.

• Сессионные токены.

• Система модерации относительно токенов.

С радио пока всё сложно, занят проектированием нового планировщика очереди, потому ничего конкретного обещать себе не могу. Но хотелось бы:

• Теги для файлов.

• Интерфейс управления файлами: редактирование ID3-тегов, назначение тегов, поиск дубликатов по ID3-тегам, имени и хешу, загрузка новых.

• Интерфейс управление очередью и расписанием.

• Улучшить генераторы треклистов: избавление от дубликатов, генерация по времени.

• Продолжить ковырять свою реализацию вещалки.

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

Фичи:

• Воспроизвести все медиа-файлы(кроме Youtube) из нити.

• Воспроизвести только видео/слайдшоу из изображений.

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

• Перемешать список воспроизведения.

• Повтор списка.

Скорее всего данная функциональность будет существовать как отдельная кнопочка "Начать воспроизведение". Я не хочу ломать годами устоявшийся UX "тыкнул на превью - открылась новая вкладка с оригиналом".

В каком-то виде оно существует и сейчас для внимательных. Осталось навайбкоженное обернуть в нормальный компонент и модалочку кастомную запилить. Последняя мне ещё пригодится для реализации карты ответов - всё-таки базовая фича современных чанов.

Недавние изменения:

• Нить можно блокировать к ответу, выполняется владельцем чана - https://github.com/U-Me-Chan/umechan/issues/132

• При использовании Шизочана пароль от поста теперь сохраняется в localStorage, что позволяет удалять пост отдельной кнопкой. При удалении нити владельцем удаляются и все её ответы.

• Теперь GIF-файлы являются изображениями в списке медиа, отдаваемых сервером.

Провёл нагрузочное тестирование веб-сервера чана при раздаче статики и при получении ответа от серверной части. Нагрузку подавал из локальной сети шириной в 1 Гбит/с с помощью утилиты siege.

Успешно отдаётся статика при нагрузке до 600-700 запросов/секунда. Дальше заканчиваются дескрипторы.

Успешно обрабатывается запрос к корню API при нагрузке до 1200-1300 запросов/секунда. Дальше заканчиваются воркеры.

Успешно обрабатывается запрос списка последних 100 тредов + 3 ответа со всех досок при нагрузке в 180-200 запросов/секунда. Дальше происходит упор в I/O-операции с БД.

Думаю, этого нам хватит навсегда. Скорее, будет упор в сетевой канал.

Когда формирование эвентов починишь? ;3

Когда разберусь с Apache Kafka в разрезе Распредача. Думаю, максимум через две недели выкачу прототип.

Порефакторил инфраструктуру чана:

• Вынес установку зависимостей для продакшена в отдельный шаг.

• Вынес установку зависимостей для разработки в отдельные runners(не смог подобрать термина на русском).

• Поправил использование ADD на COPY везде.

• В продакшен-образы теперь не попадает ничего лишнего - ни тестов, ни файла с зависимостями, ни пакетного менеджера.

Всё это планомерный путь по сокращению размера результирующих образов и снижение кол-ва векторов атаки изнутри контейнера при взломе жопы.

https://github.com/U-Me-Chan/umechan/commit/63a41c796c565b4312ef06d4064162816e3e1f1d

Прямо сейчас сел за события.