IAMEvent

Около трёх лет я хотел сделать такой проект. Первым стал desktop-софт DERB. До него аудиоконкурс проводили редко: требовались навыки диджея и работа в аудиоредакторе. Приложение собрало необходимые действия в игровой процесс, доступный в том числе для домашнего использования.

Следующей задачей стали лицензирование, выдача доступа, продажа лицензий и ограничение их бесконтрольной раздачи. Для этого появилась IAM Console — общая серверная часть и панель управления приложениями, пользователями, тарифами, лицензиями и продажами.

При развитии линейки я поговорил с десятью потенциальными покупателями. Все обозначили потребность в викторинах и гибкости, которой им не хватало при работе с PowerPoint. К этому моменту я уже начал примерно два-три отдельных приложения. Я остановил их раздельное развитие и перешёл к единому IamQuiz со встроенными игровыми режимами: поддерживать несколько принципиально одинаковых продуктов было бы лишней работой.

Общие возможности получили отдельное место в системе. iam_boilerplate служит Tauri-заготовкой новых приложений с готовым лицензионным циклом. iam-rc предоставляет телефонное управление по локальной сети и через интернет. Console обслуживает коммерческие права и серверные интеграции.

Почему интерактивы остались отдельными

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

BabyTell — голосование для гендер-пати и свадебного шоу. Ведущий задаёт две стороны, реквизиты и финальный таймер. Гости переводят деньги выбранной стороне, оператор вручную вносит поступившие суммы, а экран показывает соотношение, историю и итог. Есть управление с клавиатуры, локальное сохранение и вывод в отдельное окно, браузер или OBS. В банковских QR сохраняются исходные байты данных: перерисовка кода не меняет реквизиты и кириллицу в нестандартной для веба кодировке.

«Казино с тортом» — игра с ячейками, кусочками торта и фантами. Гость выбирает номер, ведущий управляет открытием и темпом показа. Рабочая карта ведущего отделена от экрана зала; доступны сетка и колесо, настройка заданий и сценического исхода. Состояние партии сохраняется, повторное вскрытие ячейки не зачисляет ставку второй раз, фанты не повторяются до исчерпания списка. Для браузерного и OBS-экрана используется общий iam-rc.

У всех трёх продуктов есть собственный сценарий проведения и общие контракты с Console для лицензирования и получения релизов. Эти небольшие приложения показывают ту же работу с деталями реального мероприятия: операторский контроль, сохранение состояния и отдельную подачу для гостей.

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

flowchart LR
    Buyer["Покупатель · сайт или VK"] --> Console["IAM Console"]
    Console -->|"Лицензия"| Apps["DERB · BabyTell · Cake Casino · IamQuiz · PhotoWall"]
    Phone["Телефон ведущего"] --> RC["IAM RC"] --> Apps
    Guests["Телефоны гостей"] --> Cloud["PhotoWall Cloud"] --> Apps
    Apps --> Screen["Экран зала"]

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

flowchart TB
    WEB["Лендинг и страницы продуктов"] --> BUY["Покупка и веб-кабинет"]
    BUY --> C["IAM Console"]
    MINI["VK Mini App: каталог, покупка, кабинет"] --> C
    BOT["VK-бот: диалоговые сценарии"] --> C
    C <-->|"Платежи и подтверждение оплаты"| PAY["ЮKassa"]
    D["DERB / BabyTell / Казино с тортом"] <-->|"Активация и проверка лицензий"| C
    QUIZ["IamQuiz"] <-->|"Генерация сценария"| C
    C <-->|"Запросы к модели"| LLM["LLM-провайдер"]
    QUIZ <-->|"Схема пульта и команды"| RC["IAM RC: LAN / интернет"]
    PHONE["Телефон ведущего"] <--> RC
    CAKE["Казино с тортом: браузерный / OBS-экран"] <-->|"Локальный транспорт"| RC
    PW["PhotoWall desktop"] <-->|"Управление сессией и доступом"| C
    C <-->|"Команды и подтверждения"| CLOUD["PhotoWall Cloud"]
    GUEST["Телефоны гостей"] -->|"Загрузка материалов"| CLOUD
    CLOUD -->|"Подготовленные медиа"| PW
    PW --> SCREEN["Экран зала / браузер / OBS"]

Первый путь покупателя: сайт и кабинет

Лендинг показывает три мини-интерактива: DERB, BabyTell и «Казино с тортом». Каждый объясняется через действие на мероприятии и визуальную сцену. Посетитель переходит на отдельную страницу продукта с описанием, демонстрацией, порядком использования, ответами на вопросы и вариантами лицензии. IamQuiz и PhotoWall представлены на главной как следующие продукты.

Цены и оформление приложений приходят из Console. Содержание продуктовых страниц — заголовки, преимущества, шаги, FAQ, видео и скриншоты — хранится в данных витрины. Публикацией страницы и доступными тарифами управляет владелец через админку; предложения формируются из общей модели приложений и тарифов.

Покупатель выбирает вариант лицензии, входит через VK ID и оформляет оплату на сайте. Веб-покупка использует тот же серверный checkout, что и Mini App. При повторной покупке сервер определяет, нужно ли продлить существующую лицензию. Веб-кабинет использует общую загрузку лицензионных данных: показывает собственные доступы, скачивание приложений и продление; код активации запрашивается отдельным действием пользователя.

В системе также есть события воронки: просмотр продукта, начало покупки, идентификация и привязка к оплате. Это подготовленный механизм анализа пути покупателя.

Второй путь покупателя: VK Mini App

Mini App предоставляет собственный путь покупателя в клиенте VK. Сервер проверяет подписанные параметры запуска и связывает действия с пользователем. Интерфейс использует VKUI, тему и отступы среды VK, учитывает мобильный и desktop-режимы. Каталог и кабинет работают с теми же приложениями, тарифами и лицензиями, что сайт и Console.

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

Оплата встроена через ЮKassa. Результат определяется серверным состоянием заказа; при недоступности виджета предусмотрен переход на отдельную страницу оплаты. После покупки кабинет продолжает пользовательский путь: срок доступа, приложения для скачивания, код активации по отдельному тапу, привязанные устройства, освобождение места и продление лицензии.

VK-бот обслуживает диалоговый канал: карточку DERB, сценарии получения доступа и покупки, кампании и промокоды. Он связан с общей серверной логикой Console. Сайт, бот и Mini App дают разные точки входа в одну модель продуктов и прав доступа; обязательной последовательности между этими каналами нет.

Как покупка превращается в работающую лицензию

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

В цепочке оплаты сервер проверяет событие через API ЮKassa. Выдача лицензии оформлена отдельной операцией с состояниями выполнения. Лицензия, коды, связь с продажей и успешный результат выдачи сохраняются транзакционно; повторные события учитывают уже начатую или завершённую операцию. Ошибку выдачи можно обработать отдельно от состоявшейся оплаты.

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

Console подписывает условия доступа Ed25519. Tauri-клиент проверяет подпись, устройство и срок действия; локальная запись связана с контрольными данными в системном хранилище учётных данных. Предусмотрены периодическая проверка с сервером и ограниченное время работы без неё. Подтверждённый сервером отзыв удаляет локальные лицензионные данные.

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

В одной студии собраны бумажный квиз, «Миллионер», «Сто к одному» и «Своя игра». Режимы используют общие проекты, хранение медиа, сохранение сессии и механизм передачи состояния экрану зала. У каждого режима остаются собственные правила и команды. Новый режим добавляет свою механику к существующей основе.

Оператор управляет ходом шоу, а экран зала получает состояние для отображения. Например, в «Миллионере» исходный правильный ответ хранится отдельно от сценического решения: ведущий может признать ответ игрока правильным либо раскрыть такой исход отдельным постановочным действием. Это позволяет адаптировать проведение под мероприятие, сохраняя исходные данные вопроса.

Для ведущего, координатора или помощника нужен доступ с телефона. В IamQuiz встроен локальный сервер из iam-rc; для подключения через интернет используется облачный WebSocket relay. Приложение отправляет описание доступного сейчас пульта, а общий телефонный интерфейс отображает его и возвращает команды. Поэтому транспорт и renderer можно использовать в следующих продуктах, задавая для них другую схему пульта.

Механизм включает подключение с PIN и разрешением оператора, повторное соединение и передачу текущего состояния. Полный цикл управления IamQuiz с настоящего телефона я проверил.

Как ИИ вошёл в подготовку викторины

Для бумажного квиза реализован путь: описание мероприятия → форма уточнений → генерация → просмотр результата → добавление или замена раундов в редакторе. Готовые данные становятся частью проекта игры.

Desktop обращается через Rust к Console, где находятся настройки моделей, промпты, проверка доступа, квоты и учёт использования. Приложение передаёт версию и JSON Schema результата, которую определяет игровой модуль. Сервер проверяет структуру ответа; клиент преобразует её в данные редактора. При ошибке формата предусмотрена повторная попытка с описанием ошибки.

Промпты для уточнения и генерации, а также используемые модели редактируются в Console. Изменения промптов версионируются; в журнале остаются модель, расход токенов и версия настроек. Их можно настраивать без пересборки desktop-приложения в рамках существующего формата результата.

Полный цикл я прошёл и получил сгенерированную викторину. На том этапе проверял интеграцию; качество вопросов меня не устроило. Следующий этап для этой функции — доведение контента настройками и проверкой результата.

Как материалы гостей доходят до экрана

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

Console отвечает за право на сессию и её жизненный цикл, Photocloud — за приём и подготовку медиа, desktop — за локальный проект и показ. Управляющие команды сохраняются вместе с желаемым состоянием, подписываются и могут доставляться повторно. Подтверждение облака обновляет фактическое состояние: оператор видит разницу между запросом и его исполнением.

Медиа проходят напрямую через Photocloud: проверка файла, резервирование вместимости в PostgreSQL, приватное хранение в S3/MinIO и очередь BullMQ/Redis. Отдельный worker готовит изображения через Sharp и видео через FFmpeg. Desktop получает временное разрешение MediaLease и скачивает результат в локальный кеш. После этого показ не зависит от облачных ссылок.

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

Нативное окно, браузер и OBS используют один renderer. При переподключении экран получает полный снимок состояния. Локальный проект сохраняется через временный файл и атомарную замену; облачные материалы удаляются по сроку хранения.

Штатная загрузка PhotoWall ↔ Photocloud работает и проверена мной. Остаются замечания к оформлению и проверка сценария с 300+ фотографиями через облако.

В репозиториях есть код тестов конкурентной активации, повторной выдачи лицензии, переходов игровых состояний, пульта и команд PhotoWall. Результаты моих ручных проверок перечислены ниже. Для Console подготовлен процесс развёртывания с резервной копией БД, миграциями, проверкой здоровья приложения и возвратом к предыдущему образу при неудачном старте.

Работающие сценарии и граница результата

На сентябрь 2026 года коммерческих продаж пока не было.

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

Развитие отдельных интерактивов привело меня к следующему направлению — ShowDesk, общей среде проведения мероприятий с подключаемыми игровыми модулями. В прототипе реализованы ядро микшера, отдельный зрительский вывод и контракт модулей с примером Randomizer. Дальнейшее видение — SDK, маркетплейс конкурсов и персональные интерактивы, создаваемые с помощью AI. Архитектура и логика этого перехода описаны в отдельном кейсе ShowDesk.