AmoBit Inbox

Обзор

Multi-channel inbox product summary

AmoBit Inbox - web-first B2B inbox для обработки клиентских диалогов из нескольких messaging channels в одном workspace.

Продукт не является CRM clone и не является desktop messenger wrapper. Основная идея проще: операторы входят через браузер, открывают workspace, подключают каналы, обрабатывают dialogs, видят contact context, отправляют сообщения и медиа, а follow-up работа остаётся рядом с разговором.

Продукт построен вокруг React-клиента и отдельного Django backend. Backend остаётся источником истины для рабочих пространств, пользователей, каналов, контактов, тредов, сообщений, вложений, профилей и защищённого доступа к медиа.

Product model

Workspace, channel and provider model

AmoBit Inbox организован вокруг workspaces. Workspace представляет отдельную компанию или customer cabinet. Users входят в workspace через memberships, и у каждого workspace свои connected channels, dialogs, contacts и operational state.

Channel model отделяет provider account credentials от concrete routing identities. Для shared aggregator channels вроде WA, TG и MAX внешний API token может быть account-level, а profile_id определяет actual channel profile used for routing. Direct bot channels вроде TG BOT и MAX BOT рассматриваются отдельно.

Это различие важно, потому что один provider account может обслуживать несколько channel profiles. Продукт не должен предполагать, что у каждого видимого WhatsApp, Telegram или MAX channel есть отдельный внешний API token.

Main workspace

Структура операторского интерфейса

Главный экран оператора - «Сообщения». Он объединяет queue of dialogs, active conversation, message history, text/file/voice sending, media rendering, channel indicators, group chat metadata, reactions, contact и context surfaces.

Интерфейс спроектирован как рабочий инструмент, а не marketing page: высокая плотность, стабильный scroll, компактная навигация, readable chat cards и доступный composer.

Для mobile и narrow screens chat flow следует модели list-to-thread-to-details, а не пытается сжать полный desktop split layout в один экран.

Contacts

Contact context and conversation surface

Contacts - отдельная product surface, а не просто side effect сообщений.

Contacts section включает list/grid style interface и right-side contact card. Card может показывать contact properties, channel rows и embedded conversation window. Contact conversation может hydrate real messages, fallback to timeline messages, send text, files and voice, and load older history without disruptive scroll jumps.

Продукт также включает duplicate/linking flows. Merge flow позволяет выбирать primary values, сохраняя multiple phones, multiple emails, channels and tags. В текущих материалах merge modal UI существует, а persistence to backend merge endpoint оставлен follow-up.

Messaging runtime

Webhook, persistence and outbound flow

Backend обрабатывает incoming webhooks, message normalization, thread resolution, contact resolution, persistence, attachments, delivery status и outbound sending.

Runtime поддерживает text, media и voice paths. Для media backend отдаёт protected media access и signed share URLs, когда provider delivery требует reachable file URL. Browser UI media access остаётся authenticated.

Продукт также обрабатывает reactions как события сообщений. Reactions показываются на целевых сообщениях, когда target можно определить, и используют fallback-поведение для неразрешённых событий.

Group chats

Group metadata and participant handling

Group chats моделируются явно.

Group не рассматривается как direct dialog с меняющимся participant name. Backend tracks whether thread is a group, prefers real group metadata for titles, and avoids using latest sender as group title or avatar.

Для этого потребовалось provider payload hardening. Boolean-like provider fields вроде isGroup="false" парсятся явно, а не через generic truthiness. Group avatars принимаются только из chat-level avatar fields, а не из полей, которые на самом деле могут содержать latest participant avatar.

В UI group conversations могут показывать sender names внутри incoming bubbles и использовать group-specific labels or icons вместо direct-contact assumptions.

Media handling

Protected media access and caching

AmoBit Inbox не относится к protected media как к public static files. Доступ к media проходит через backend-controlled endpoints, а remote provider media может храниться metadata-first.

Для MAX media используется lazy caching: provider file загружается и кешируется только когда оператор открывает его. Cache TTL, maximum object size и cleanup tooling ограничивают рост storage.

Также был обработан реальный provider issue: некоторые MAX payloads содержали small placeholder body, while actual file URL was available elsewhere in the payload. Backend изменён так, чтобы prefer safe provider file URLs for MAX media, and repair command был добавлен для ранее сохранённых bad attachments.

Browser runtime

Web-first deployment model

AmoBit Inbox теперь web-first.

Канонический runtime - браузерное развёртывание с логином и защищёнными маршрутами рабочих пространств. Desktop/Tauri packaging есть в репозитории, но считается legacy, пока desktop-направление явно не открыто заново.

Browser runtime использует backend как source of truth. При первом workspace load client принудительно получает full server snapshot, чтобы reloads, restored tabs и old browser cache не оставляли queue в misleading state. Delta sync используется для ongoing updates, но не как единственный source of truth.

Deleted or cleaned-up threads reconciled through backend tombstones. Changes endpoint может вернуть deleted thread information, а browser удаляет tombstoned conversations, messages, cursors и stale active selections из local state.

Operational hardening

Security, sync and failure boundaries

Продукт включает несколько решений по production hardening, которые являются частью формы продукта, а не просто cleanup реализации.

Dev bootstrap не является production auth model. Продукт использует explicit login/logout и authenticated sessions. Webhook handling требует valid channel authorization вместо trust spoofable request metadata.

Backend избегает возврата raw connector secrets normal clients. Channel management различает configured state и secret values, а operator-facing UI не должен без необходимости раскрывать provider secrets.

Production cleanup expected to be backup-first and repeatable. Manual database surgery считается слишком рискованной для recurring import or messaging problems. Existing tooling включает dry-run-first repair or cleanup commands для specific cases, а active remaining question - нужен ли broader invalid-import cleanup собственный command.

Deployment shape

Same-origin deployment and proxying

Live web runtime served through nginx from backend server.

Frontend bundle отдаётся с root web path, while /api/ proxied to Django. This same-origin shape keeps browser behavior simpler and avoids unnecessary CORS complexity in current deployment model.

Project materials identify https://inbox.amobit.io as canonical review/runtime URL. Legacy sandbox routes больше не считаются working review zones.

Current status

Active runtime scope

AmoBit Inbox - browser-first inbox application с workspace login, isolated workspace data, channel provisioning, WhatsApp and MAX QR-oriented authorization flows, message queue and thread view, text/file/image/voice handling, protected media delivery, group chat support, reactions, contacts and merge UI, profile and channel surfaces, and reminders as part of the operator workspace.

Главная оставшаяся тема hardening в доступном project plan - acceptance cleanup-tooling для будущих плохих импортов. Более широкое направление продукта уже зафиксировано: AmoBit Inbox - independent web inbox, где backend хранит канонические данные, а браузерный клиент является основной рабочей поверхностью оператора.