Всем привет.

Какое-то время пилил self-hosted чат в стиле Discord и наконец довёл до состояния, которым не стыдно поделиться. Бесплатный, открытый исходный код (MIT).

Зачем вообще: большинство self-hosted чатов требуют Docker, инстанс Postgres, очередь сообщений и полдня жизни до того, как увидишь экран входа. Мне хотелось, чтобы моё сообщество могло общаться, не завися от чужих серверов, и без необходимости быть админом-девопсом. Поэтому тут всё наоборот — только PHP и один файл SQLite. Если ваш хостинг тянет блог на WordPress, он потянет и это.

Что умеет: серверы, текстовые каналы и личные сообщения с редактированием и реакциями; голосовые комнаты и звонки по WebRTC с демонстрацией экрана; обмен файлами (картинки сжимаются автоматически, лента грузит лёгкие миниатюры); устанавливается как PWA на компьютер и телефон без магазинов приложений; несколько тем и 4 языка с переключением на лету; есть API мини-приложений (в комплекте демо 3D-шашек). Весь брендинг и лимиты живут в одном config.json — код трогать не нужно.

Что нужно на сервере: PHP 7.3+ (рекомендуется 8.1+), PDO SQLite, опционально GD для миниатюр, Apache или Nginx с HTTPS. Никакого Node, Composer, отдельной БД и сборки. Установка по сути: залить файлы → дать права на папку uploads → отредактировать конфиг → открыть в браузере.

Проект ранний, делаю один, так что буду рад фидбэку — особенно по голосовому стеку и безопасности. Баг-репорты и комментарии в духе «вот чего мне не хватает, чтобы я реально это развернул» очень приветствуются.

Ссылки:

Исходники (MIT): https://github.com/MrZer0x0/trueCORD

Демо: https://morrowind.site
Демо: https://4tusa.site

Возможно кому то сократит время.

ссылки в письме не кликабельны, так как не имеют на домена, ни скрипта который их должен обрабатывать. Все из за отсутствия файла: (корень)pub/mail/consent.php

<?

include_once($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/urlrewrite.php');

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");

$APPLICATION->SetTitle("Согласие на рассылки");

?>

<div class="maxwidth-theme">

<div class="wrapper_inner">

<div class="container_inner">

<?php

$APPLICATION->IncludeComponent(

"bitrix:sender.consent",

".default",

array()

);

?>

</div>

</div>

</div>

<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>

- сравнить с похожими вариантами, с которыми его легко перепутать;

- разобрать, где решение нормальное, а где уже есть запахи.

Позже подключил ИИ как помощника именно для такой практики. Не чтобы он просто писал код за меня, а чтобы подкидывал задания, задавал новые вариации и помогал разбирать, где моя логика хромает. И вот тогда паттерны начали восприниматься не как абстрактная теория, а как повторяющиеся ходы, которые реально можно замечать в проектировании.

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

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

Вообще интересно, у кого как это было.

У вас паттерны тоже начали нормально укладываться только через практику?

Или, наоборот, книги по паттернам GoF сразу заходят без боли?

Кто сколько вложил денег?
Кто сколько реально работал?
Кто сколько должен получить с продаж?

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

• «Я вкладывал больше»

• «Я делал больше»

• «Я тащил проект»

• «Я вообще тогда работал бесплатно»

Наше решение: сделать динамическую систему расчёта долей (роялти) как в стартапах

Мы решили подойти к этому не “по дружбе”, а по-взрослому.

Сделали систему, которая рассчитывает процент доли каждого участника, учитывая:

• финансовые вложения (кто платил за что и сколько)

• потраченные человеко-часы (кто сколько работал)

• итоговую долю в проекте (динамическая ставка)

• будущий доход с продаж (Royalty)

То есть примерно как в стартапах: один вкладывает деньги, другой делает продукт — а итоговая доля рассчитывается справедливо, а не «на глаз».

Название дали простое: Studio

Мы не стали выдумывать пафосные названия и назвали систему просто — Studio.

Изначальная цель была максимально прагматичная:

• учитывать расходы по проекту

• фиксировать, кто и на что вкладывает деньги

• учитывать часы работы команды

• рассчитывать доли и будущие выплаты

• отображать статус игры, прогресс, отзывы в Steam и т.д.

Почему на чистом PHP?

Да, можно было сделать всё на Laravel, Symfony, Node.js или вообще на микросервисах.
Но мы выбрали путь попроще:

чистый PHP + MySQL, потому что:

• этого достаточно для такой системы

• разработка быстрее и дешевле

• поддержку можно вести без отдельного backend-разработчика

• проект не превращается в «платформу ради платформы»

Результат: разработка и контроль стали в разы проще

И вот тут самое интересное: мы реально почувствовали, что проект перестал быть «на энтузиазме» и стал управляемым.

Стало проще:

• видеть вклад каждого

• понимать, где горит по финансам

• оценивать, кто сколько реально сделал

• планировать разработку и бюджет

Следующим шагом мы начали делать то, что обычно подключают через сторонние сервисы — но нам захотелось встроить это в Studio.

Добавили мониторинг посещений официального сайта игры:

• учёт всех визитов

• проверка уникальности (visit_key, ip_hash и т.д.)

• отслеживание UTM-меток

• фиксация источников перехода (Яндекс, Google, прямые заходы и т.п.)

• корректное определение реферера

То есть теперь мы видим не только разработку, но и то, как аудитория реально реагирует на проект.

Если пост зайдёт — покажем, как всё устроено внутри: структура базы, логика уникальности, расчёт долей, интерфейс и какие выводы мы сделали по трафику.

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