1. Звонки
2. Текстовые сообщения
3. Отправка фотографий ( снимок и из галереи ? )
4. Отправка голосовых сообщений
5. Групповые чаты
6. Принудительная блокировка геолокации
7. Блокировка на скриншот
8. Пароль при входе в приложение ( буква и 4 цифры )
9. Пароль при прикреплении файла
10. Пароль для входа при выключении экрана ( скорее при включении? )
11. Пароль номер 2 на удаление блокировку ( т.е. при вводе этого пароля телефон делает factory reset/удаление приложения )
12. Отображение получения сообщений/файлов сигналом
13. Отображение получения сообщений/файлов цифрой. Цифра отображает количество полученных сообщений
14. Текст сообщения не отображается в уведомлениях
15. Отправитель сообщения не отображается
16. Отображение "typing"
17. Принудительное сообщение/удаление файлов через 24 часа
18. Установка удаления сообщений через заданное время ( 5,10,30 минут, 1,2,5,10 часов ) после прочтения
19. Удаление чата одним из абонентов
20. Удаление групповых чатов создателем чата
21. Если сообщение/файл не прочитаны, то удалять их по истечении суток после отправки
22. Алгоритм блокировки абонента администратором системы ( не совсем понятно что имеется ввиду, задача условий блокировки через интерфейс администратора?)
23. Nickname 001-500 абонента присваивать при загрузке приложения ( хотелось бы понять данное требование на примере)
24. Видеозвонки - нет
25. Отображение "Online" - нет
26. Отображения "когда был в сети" нет
27. Отправка файлов - нет ( данное требование противоречит требованиям 9, 12, 13, 17, 21 полностью или частично в той формулировке, в которой они заданы )
28. Отправка видео - нет
29. Отображение «online» - нет
30. Отображение «когда был в сети» — нет

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

1. End to End encryption для сообщений ( включая метаданные )
2. Client - Server encryption соединение ( TLS )
3. Если мы говорим о том, что мы также будет заниматься сопровождением то стоит отметить как отказоустойчивость ( например 99% доступности в год ) так и восстановление после сбоев в автоматическом режиме
4. Защита от DDos атак как сетевого так и уровня приложения
5. Также в процессе разработки необходимо будет проработать механизм аудита и раннего обнаружения атак. Здесь надо подумать над балансом между тем насколько много данных пользователей мы будем хранить/получать на сервере и тем как точно и быстро мы хотим эти атаки обнаруживать. Чем больше данных тем точнее инструмент, но тем ниже уровень безопасности пользователей в случае если сервер будет скомпрометирован
6. Также push сообщения по видимому не могут быть реализованы с использованием сторонних сервисов, это усложняет разработку.
7. Обновление приложения в обход google play сервиса
8. Локальное хранилище приложения ( e2e ключи и кэш ) должны быть зашифрованы
9. Хранилище серверной части также должно быть зашифровано

Планируется что все приложение будет запускаться на ванильном Android, в котором будут отключен функционал из требования 6 и 7
Также это позволит нам запретить установку любых других приложений кроме нашего
Локальное хранилид

Ниже приведено 3 варианта решений

Opensource клиент-серверное приложение на Python
Плюсы:

• Активно развивающийся проект
• OpenSource, а значит имеет возможность проходить аудит широкой общественности
• Интегрируется с IDM/IDP
• Большая часть серверной части функционала уже есть
• Высокий уровень покрытия тестами
• Написан на статически типизированном Python 3
• Есть bounty программа по поиску багов

Минусы:

• Python имеет ряд ограничений, хотелось бы все-таки компилируемый язык
• В целом разработан и заточен под хранение истории и поиск, поэтому потребует довольно много доработок
• Сложнее поддерживать из-за высокого уровня доработок
• Клиентская часть написана на React Native, что предположительно может вызвать затруднения для запуска на ванильном андроид. Также высокий уровень абстракции не позволит быть уверенным в высоком уровне безопасности приложения

Стоимость разработки - 25 140 000 рублей

Сроки реализации этапа 5 месяцей

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

• Давно на рынке
• Opensource
• Огромное количество контрибьютеров
• Надежная, зарекомендовавшая себя команда разработки
• Надежный протокол, получивший широкое распространение ( например его использует WhatsApp )
• Есть e2e шифрование, даже групповых чатов
• Регулярный аудит кода
• Большая часть функционала уже реализована
• Клиентская часть написана на Java, скорее всего проблем с запуском на ванильном android не будет

Минусы:

• Команда разработки консервативна в принятии PR на новый функционал
• Довольно старый проект, есть некоторый груз в виде например Java а не Kotlin на фронтенде
• Некоторого функционала все-таки нет на бекенде

Стоимость разработки - 19 972 000 рублей

Сроки реализации проекта 4 месяца

Предполагается использование какого-то готового XMPP сервера, например Jackal
Плюсы:

• Проверенный временем протокол
• Большой выбор готовых решений практически под любой язык
• Есть готовые библиотеки для e2e шифрования ( например OTR )

Минусы:

• Выглядит менее надежным чем Signal
• Большая часть готовых решений довольно вяло разрабатывается
• Безопасность не является его основным функционалом как и в случае с zulip, а значит разработчики не уделяют этому так много внимания, как та же команда Signal
• Потребует практически гарантированно написание фронтенд части с нуля, что увеличит риски не успеть в срок

Стоимость разработки - 22 500 000 рублей

Сроки реализации проекта 4 месяца