Letter Box

Разбор

Решения

Почтой владеет сервер, а не приложение

Первая версия держала IMAP прямо в Electron, и это разваливалось предсказуемо: закрыл окно — синхронизация встала, переустановил приложение — пароли приложений надо заводить заново, открыл на втором компьютере — состояние разъехалось.

Соединения, credentials и хранилище переехали в NestJS. Desktop стал тонким: он спрашивает данные по REST и слушает обновления по Socket.IO. Побочный выигрыш — веб-клиент теперь можно написать поверх того же API, ничего не трогая на сервере.

Разметка живёт в очереди, а не в интерфейсе

Соблазн был сделать «нажал на письмо — увидел тег». Но локальная модель отвечает секунды, а не миллисекунды, и на пачке в двести писем интерфейс превратился бы в спиннер.

Поэтому синхронизация и разметка стали задачами BullMQ. Worker разбирает их в своём темпе и присылает готовый результат событием. Письмо появляется в списке сразу, тег — когда доедет. Здесь же решается вторая проблема: очередь ограничивает параллельные вызовы модели, иначе локальный инференс просто съедает всю память.

Локальная модель — опция, а не требование

Ollama подключается через переменные окружения. Если её нет, Letter Box остаётся обычным почтовым клиентом: пропадают только теги и часть дашборда. Такую зависимость нельзя делать обязательной — иначе приложение перестаёт запускаться у всех, кто не готов держать модель.

Что оказалось сложным

Провайдеры по-разному врут про IMAP. Mail.ru, Яндекс и Gmail расходятся в именах системных папок, в поддержке CONDSTORE и в том, что считать «удалено». Логику пришлось выносить в отдельный слой с правилами на провайдера, а не надеяться на общий стандарт.

Второе — качество разметки на маленькой модели. Свободный ответ она даёт многословный и нестабильный, поэтому промпт пришлось сузить до выбора из закрытого списка категорий, а ответ — валидировать и отбрасывать, если он в список не попал. Это тот случай, когда точность берётся не из модели побольше, а из более узкой постановки задачи.