Всем добрый день!

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

Павел Дуров уже давно ввел в супергруппах топики. И это очень удобно - отдельные обсуждения и обработки разных векторов информации.

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

У вас вышел новый сотрудник? Подключите в супергруппу, 5ти минутный инструктаж и он уже в работе!
Запутались в куче чатов, потому что когда-то ошибочно указали личные контакты? Перейдите в обработку заявок через бота! Всё будет в одном месте

🖲Скоро

Good afternoon, everyone!

The idea of creating business support channels directly in telegram is not new. Many people have tried to create something tangible. It all started with the so-called feedback bots, which the administrators of the telegram channels loved very much. One "proxy" bot that simply redirects messages to the admin and removes the routine of sorting those who write to him personally. Convenient!

Pavel Durov has long introduced topics in supergroups. And this is very convenient - separate discussions and processing of different vectors of information.

We're going even further. In times of financial instability and inflated prices for competitors' product solutions, which need to be installed, configured, and implemented.. We are proactive for you. It is important that it is accessible.

Have you got a new employee? Connect to the supergroup, a 5-minute briefing and it's already in the works!
Are you confused in a bunch of chats because you once mistakenly specified personal contacts? Go to the application processing via the bot! Everything will be in one place

🖲Soon

Как это работает: 👇

🤖 Клиент пишет в бота
Его обращение автоматически попадает в специальный чат поддержки с темами (топиками)

👨‍💻 Команда поддержки видит обращение в чате
У операторов есть удобное меню для управления тикетом:
✅ Взять себе — чтобы начать работу
👥 Назначить коллеге — если нужен другой специалист
🔄 Закрыть — когда вопрос решён
🚫 Пометить как спам — для ненужных обращений

💬 Ответ клиенту
Оператор просто делает Reply на сообщение от бота — и ответ мгновенно уходит обратно пользователю в бот!

Всё просто, быстро и в одном месте! ✨
━━━━━━━━━━━━━━━━

How It Works: 👇

🤖 A client writes to the bot
Their message is automatically forwarded to a dedicated support chat with topics (threads).

👨‍💻 The support team sees the request in the chat
Operators have a convenient management menu for each ticket:
✅ Assign to self — to start working on it
👥 Assign to a colleague — if another specialist is needed
🔄 Close ticket — when the issue is resolved
🚫 Mark as spam — for irrelevant messages

💬 Replying to the client
The operator simply hits Reply to the bot's message — and the response is instantly sent back to the user in the bot!

It's simple, fast, and all in one place! ✨

✅ Что уже сделано:

🖲Ядро системы:
• Полностью переписано ядро GraceHub Platform (бот-менеджер).
• Переход с SQLite на PostgreSQL для масштабируемости и надежности.
• Реализован внутренний asyncio-планировщик вместо системного crontab.

Финансы и оплата:
• Готов биллинг в мини-приложении основного бота.
• Подключены платежные коннекторы:
➝ TON
➝ Telegram Stars
➝ ЮKassa (для РФ)

Надежность и Worker-боты:
• Настроен автоматический рестарт упавших воркер-ботов (которые пользователи настраивают под себя).
• Добавлены новые режимы для воркеров:
🔒 PrivacyMode — блокировка пересылки и скриншотов переписки средствами Telegram.
⭐️ Оценка при закрытии — запрос оценки оператора, если тикет закрыт.
Открытость:
• Репозитории проекта открыты на GitHub и GitVerse.

🐞 Текущие проблемы и вызовы:
Языковая поддержка — Добавили китайский язык, но столкнулись с тем, что в Китае Telegram почти не используется😂. Нужно думать о других каналах.
Тестирование — Остро не хватает массового тестирования, баг-репортов и фидбека от реальных пользователей для доработки модулей.
Интерес — Пока что проект не получил широкого внимания(он же был в закрытом git, логично). Работаем над этим!

📅 Планы:

Вот наш роадмап на будущее:
📧 Модуль почты — Интеграция с email-ящиком для работы с обращениями прямо из телеграм.
🐳 Docker — Упаковка всего проекта в Docker-контейнеры для максимально простого развертывания.
📚 Документация — Написание подробной и понятной документации для пользователей и разработчиков.
🌐 Веб-виджет — Модуль для интеграции на сайты, чтобы принимать обращения прямо с них.
🔐 Аудит безопасности — Проверка кода на уязвимости и повышение общей безопасности системы.

━━━━━━━━━━━━━━━━

✅ What's Already Done & Live:

🖲Core System:
• Fully rewritten the core of GraceHub Platform (manager bot).
• Migrated from SQLite to PostgreSQL for scalability and reliability.
• Implemented an internal asyncio-based scheduler to replace the system crontab.

Finance & Payments:
• Complete billing system implemented in the main bot's mini-app.
• Integrated payment connectors:
➝ TON
➝ Telegram Stars
➝ YooKassa (for Russia)

Reliability & Worker Bots:
• Configured automatic restart for crashed worker bots (those users set up for their own support).
• Added new modes for workers:
🔒 PrivacyMode — blocks message forwarding and screenshots via Telegram's native features.
⭐️ Rating on Close — requests a rating for the support agent when a ticket is closed.

Openness:
• Project repositories are now open on GitHub and GitVerse.

🐞 Current Challenges & Issues:
Language Support — Added Chinese, but faced the reality that Telegram is hardly used in China😂. Need to consider other channels.
Testing — There's a critical lack of mass testing, bug reports, and feedback from real users to refine the modules.
Interest — The project hasn't gained widespread attention yet. Working on it!

📅 Upcoming Plans & Roadmap:

📧 Email module — integration with mailboxes for processing support requests directly from Telegram
🐳 Dockerization — Packaging the entire project into Docker containers for effortless deployment.
📚 Quality Documentation — Writing comprehensive and clear documentation for both users and developers.
🌐 Website Widget — A module for website integration to accept support requests directly from sites.
🔐 Security Audit — Conducting a code audit for vulnerabilities and enhancing overall system security.

December 23, Planet Earth. Notes

I’m planning to focus on small businesses as my target customers — the ones for whom big Helpdesk/omnichannel suites and heavy B2B “all-in-one” machines are either too hard or simply not worth it. This strategy also immediately defines the legal approach: at the start, everything will be based on a public offer agreement 📄Building “enterprise-grade” billing with closing documents and full accounting — let’s be honest — is difficult right now. Especially when the product is multilingual from day one 🌍
So my biggest motivation at the moment is engineering and reliability 🔧I want even a basic demo to feel solid for customers: fast, stable, no surprises. Multi-payment support is coming — tests are already in progress.

There will be 2 ways to use it:
🖲 The project is available on GitHub and GitVerse for self-hosting on your own servers. It’s free ✅
🖲 Quick launch of your support bots on my hosted SaaS (GraceHub Platform): pricing and billing are right in the app 💳This is for those who want business support tooling and don’t plan to dive into infrastructure, deployment, and updates. That means my team and I take on obligations to meet an SLA and provide timely support 🧩

I also clearly see a direction that will only keep growing: everyone building a Telegram mini app or their own service bot almost inevitably runs into support and feedback workflows 💬
That’s exactly what I’m building for — and I’ll be ready to offer it as soon as the first release is out 🚀

What I’m doing right now (technical side):
1. Setting up async / non-blocking DB access. I expect something like 50–350 worker instances of customer support bots per server, so high-quality DB access is critical ⚙️
2. Rewriting the worker bot to use webhooks instead of polling. The project started as a single support bot, and polling was acceptable back then — but for SaaS and real load, it’s not🫢
3. Changing the way worker bots are spawned to manage resources more efficiently and scale without “inflating” hardware usage. Eventually we need to be ready to package everything into Docker🤔
Tests are needed. Lots of tests😅

Stay in touch, have a great day!👋

27 декабря, планета Земля

Добавил Schemathesis OpenAPI тесты(питончик). Они показали что мои эндпоинты FastAPI - дырявое решето😄

..Потратил полтора дня на исправление 500х и прочих ошибок
..Добавил отдельный эндпоинт тестовой авторизации, чтобы можно было получить Bearer token и проверять группу эндпоинтов доступных только с авторизацией(безопасно, не для прод).

Гемор, но оно в перспективе даст хороший фундамент. Я всё еще надеюсь заманить в проект парочку контрибьюторов. Если вы знаете, где они обитают - напишите мне😄

Линтер Ruff в pre-commit тоже в своём отчете фигурально высказывал предположение, что код писал нетрезвый сударь, которому пора завязывать и к психологу. Я даже , казалось, словил удивление в его отчёте - я его запустил первый раз за всю жизнь GraceHub. Еще часа 2 фиксил ошибки линтера. Их было 280, и не все поддавадись автофиксу.

Жду очень момента, когда пофикшу все текущие баги и приступлю к запаковке в docker. Это будет означать первый релиз. При текущей нагрузке это будет в конце января(но я вам ничего не обещал, а то мало ли - не успею🤫)

После релиза потребуется заниматься противоречивым делом, рассказывать о продукте, чтобы оценили, попробовали. Нужны массовые тесты. С одной стороны это классно - говорить о том, во что веришь, я уже наметил habr, vc, reddit, часть других форумов. С другой стороны, никогда не стремясь стать большим авторитетным рупором слова на миллион подписчиков, сложно заявлять о своём продукте, верно?

━━━━━━━━━━━━━━━━

December 27, planet Earth

I added Schemathesis OpenAPI tests (Python). They revealed my FastAPI endpoints are basically a leaky sieve 😄

..Spent a day and a half fixing [500]s and other errors.
..Added a separate test-auth endpoint so you can get a Bearer token and test the group of endpoints that are available only with authentication.

It was a pain, but long-term it’ll give the project a solid foundation. I’m still hoping to lure a couple of contributors into the project. If you know where they usually hang out — message me 😄

Ruff linting in pre-commit also “politely” suggested (between the lines) that the code was written by a tipsy gentleman who should probably quit and see a therapist. I swear I could even sense surprise in its report — this was the first time I ever ran it in the entire lifetime of GraceHub. Then I spent another ~2 hours fixing linter issues. There were 280 of them, and not all were auto-fixable.

I’m really looking forward to the moment when I squash the current bugs and move on to packaging everything into Docker. That’ll mean the first release. With the current workload, it’ll be by the end of January (but I’m not promising anything — who knows, I might not make it 🤫).

After the release I’ll have to do the slightly contradictory thing: talk about the product so people can judge it and try it. I need mass testing. On one hand it’s great — talking about something you believe in. I’m already eyeing Habr, VC, Reddit, and a few other forums. On the other hand, if you’ve never aimed to become some big authoritative megaphone with a million followers, it’s hard to loudly promote your own product, right?

Спрашивали "будет ли Stripe платежка?"

Да, она уже добавлена и тестируется👍. В mini app можно будет в режиме SuperAdmin в панели включить этот платежный шлюз и указать креды для создания инвойсов на оплаты.

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

━━━━━━━━━━━━━━━━

People asked: "Will there be Stripe support?"

Yes, it’s already added and currently being tested👍. In the mini-app’s SuperAdmin panel, you’ll be able to enable this payment gateway and enter your credentials to generate payment invoices.

Implementing RazorPay would be similar in complexity, but their registration requires a local Indian phone number. This prevents developers from other countries from creating a module in sandbox mode. There will be no RazorPay support👎

Приступил к распределению кода по контейнерам docker.

Целый день можно повторять один и тот же алгоритм:
🔘Сборка
🔘Запуск docker-compose.yml
🔘Проверка работоспособности
❌ Error

Я не успокоюсь пока не заработает - докер даст быстрый старт GraceHub Platform для каждого

━━━━━━━━━━━━━━━━

I’ve started splitting the code into Docker containers.

The whole day has been a loop of the same algorithm:
🔘 Build
🔘 Run docker-compose.yml
🔘 Health check
❌ Error

I won’t rest until it’s up and running — Docker will ensure a quick start for the GraceHub Platform for everyone.

Снег, украшенная ёлка и любимые люди рядом в этот час - вот что я вам желаю именно сейчас.

Ну и конечно же С новым годом! Пусть в новом году сбудутся все ваши желания🖲

━━━━━━━━━━━━━━━━

Snow, a decorated tree, and your loved ones by your side at this hour — this is my wish for you right now.

And of course, Happy New Year! May all your wishes come true in the year ahead🖲

Строим бронепоезд очередей

Как у каждого проекта, где много контейнеров + вебхуки я думал про архитектуру и брокеры очередей.

Что максимально важно: по возможности "переложить" надежность доставки сообщений с сети на сам сервер - создать очередь и гарантию(!) доставки.

А теперь внимание вопрос: что дешевле, оперативка или ssd? Особенно когда проект не высоконагружен, а на долгосроке vps кушает ваши деньги.
Именно такими умозаключениями я пришел к тому, что мне не подходят:
1. n8n - не нужен затратный ui да еще + Redis как брокер(уже два сервиса надо!), я хочу чтобы запуск моего проекта был доступен на самом слабом железе.
2. RabbitMQ - он хорош, но это дополнительный внешний сервис на хосте с кворумом + publisher confirms это сопоставимо с постгри по скоростям. К тому же у меня нет сложных правил маршрутизации.

Поэтому было принято решение написать свой масштабируемый(кол-во контейнеров) модуль очередей для хранения в postgre.
Плюсы:
1. Меньше расходы на ram вашего vps. Успешный запуск на слабом железе
2. Максимальная надежность, благодаря ACID транзакциям.

Проблемы, которые нужно решить:
1. Блокируемость
2. Io нагрузку
3. Скорость работы

Как я решал это:
1. Сделал SKIP LOCKED для записей этой таблицы - воркеры должны переходить к следующей записи, зная что предыдущая уже обрабатывается другим воркером
3. LISTEN/NOTIFY вместо Polling SELECT запросов в бд. Превращаем базу в активного брокера очередей.
4. Частичный индекс - индекс на только необработанные сообщения в очередь. Чтобы быстро отсортировать тех, с кем надо работать.
5. Retry механизм + Stuck recovery - возврат зависших задач в работу.

❗️Важно: UNLOGGED не делаю для таблицы очередей. Хотя это ускорило бы бд, по плану делать репликацию - очередь не доедет до реплики(Нет записей в WAL).

━━━━━━━━━━━━━━━━

Building a Queue Armored Train

Like with any project involving lots of containers and webhooks, I started thinking about architecture and message brokers.

What really matters: whenever possible, you want to shift message delivery reliability from the network to the server itself — create a queue and guarantee (!) delivery.

Now, here’s the key question: what’s cheaper — RAM or SSD? Especially when you’re running a long-term project and the server is eating your money.
That’s exactly the kind of reasoning that led me to realize these solutions aren’t right for me:

1. n8n — I don’t need a heavy UI; I want my project to run even on the weakest hardware.
2. RabbitMQ — it’s great, but with quorum queues + publisher confirms, it’s basically as heavy as Postgres. Besides, I don’t need complex routing logic.

So, I decided to build my own scalable (per container count) queue module using PostgreSQL as storage.

Pros:
1. Lower RAM usage on your VPS. Runs smoothly even on low-end hardware.
2. Maximum reliability, thanks to ACID transactions.

Problems to solve:
- Blocking
- I/O load
- Performance

How I solved it:

1. Added SKIP LOCKED for table records — workers move on to the next record, knowing the previous one is already being processed by another worker.
2. Replaced polling SELECT queries with LISTEN/NOTIFY. Basically turning the database into an active message broker.
3. Partial indexes — index only unprocessed queue messages to speed up sorting of tasks that actually need work.
4. Retry mechanism + Stuck recovery — automatically returns stuck tasks back into the queue.

❗️Important note: I don’t use UNLOGGED for the queue table. Even though it would make the DB faster, replication is part of the plan — and unlogged tables don’t replicate (they’re not written to WAL).

В Bot API 9.3 добавили топики в личный чат с ботом. Изучу функционал и в будущем, возможно, добавлю в GraceHub Platform


Upd. Ознакомился с API. Это меняет всю картину. Я могу обращения перенести полностью в mini app и делать части меню в виде mini app ссылок , нативно интегрируя запуск в инлайн кнопки.

В суперчате с топиком это было нельзя(ссылки на вызовы mini app). В личном чате с ботом - можно. Требует детальной проработки👇

Блин, Пашка, ты серьёзно?

А зачем нам управление топиками в личке, если бот не может создать сам топик через createForumTopic?

Анонс по топикам практически не имеет смысла. Я в тупике

━━━━━━━━━━━━━━━━

Damn it, Pashka, are you serious?

Why do we need to manage topics in private messages if the bot can't create a topic itself using createForumTopic?

Announcing topics is practically pointless. I'm at a dead end