Как сделать свой мессенджер html
Личный IM-мессенджер со сквозным шифрованием только для своих
В этой статье я рассказал, как сделать собственный безопасный мессенджер только для своей тусовки параноиков.
Сейчас есть много IM-мессенджеров с end-to-end шифрованием, но вариантов, которые можно быстро развернуть на своем сервере гораздо меньше.
Изучая варианты, мой взгляд упал на Delta Chat, о котором на Хабре уже упоминали — мессенджер без централизованной серверной инфраструктуры, использующий почтовые сервера для доставки сообщений, что позволяет развернуть его, например, на своем домашнем сервере и общаться с устройств, в том числе не имеющих доступ в интернет.
Среди преимуществ этого подхода можно отметить:
End-to-end шифрование
Delta Chat для подключения к серверу может использовать StartTLS или SSL подключение к серверу, сообщения по умолчанию будут шифроваться по стандарту Autocrypt Level 1, после обмена первыми сообщениями (они передаются в незашифрованном виде). Таким образом если общение идет между пользователями одного сервера, информация не будет передаваться на другие сервера, в передаче сообщений будет занят только наш сервер и устройства пользователей.
Настройка сервера
Настройка сервера для Delta Chat сводится к установке Postfix + Dovecot с настроенными StartTLS/SSL и настройке записей домена.
Для настройки сервера я буду использовать CentOS 8, для других дистрибутивов могут быть несущественные расхождения. Выбираем подходящие параметры сервера под нашу задачу.
В DNS я создал две записи: домен третьего уровня будет и почтовым доменом и именем почтового сервера:
Зададим hostname и установим postfix, dovecot и nginx (nginx — для получения сертификатов let’s encrypt, wget — для установки certbot-auto, nano — редактор):
Разрешим Postfix принимать почту извне и настроим hostname, domain и origin сервера, так как почтовый домен и адрес сервера совпадают, то домен будет везде одинаковым:
Для того что бы Delta Chat был доступен для подключения из Интернета, нужно открыть порты 80, 143, 443, 465, 587, 993. Так же откроем порты 80, 443 что бы получить сертификаты let’s encrypt и обновлять их в дальнейшем. Если планируется получение писем от других почтовых серверов, так же понадобится открыть порт 25 (в моем случае я не планирую подключаться используя другие сервера, поэтому 25й порт я не указываю). И возможно потребуется добавить перенаправление портов 80, 143, 443, 465, 587, 993 на маршрутизаторе, если сервер планируется использовать в локальной сети.
Откроем порты 80, 143, 443, 465, 587, 993 в firewall:
Создадим настройки сайта для нашего доменного имени, что бы получить сертификаты let’s encrypt используя certbot-auto
Включим и запустим nginx:
Сгенерируем сертификаты для сайта (в дальнейшем мы будем их использовать для TLS-шифрования соединения с сервером):
Будут созданы сертификаты и так же будет выведено в консоль их расположение:
Исправим соответственно файл конфигурации Postfix, что бы разрешить прием писем на портах 465 и 587:
Выполним команды, что бы указать расположение TLS сертификата и личного ключа сервера:
При необходимости можем включить логирование TLS подключений:
Добавим в конец файла конфигурации Postfix требование использовать протоколы не ниже TLS 1.2:
# Включим и запустим Postfix:
Установим, включим и запустим Dovecot:
Изменим файл конфигурации Dovecot, что бы разрешить протокол imap:
Настроим хранилище писем, что бы письма сохранялись в папках пользователей:
Добавим Dovecot в группу mail что бы Dovecot мог читать входящие:
Запретим авторизацию без TLS шифрования:
Добавим автоподстановку домена при авторизации (только по имени пользователя):
Изменим расположение сертификата, ключа, расположения файла с ключом Диффи-Хеллмана, минимальную версию TLS 1.2 и предпочтение выбора протоколов шифрования сервера, а не клиента:
Сгенерируем ключ Диффи-Хеллмана, генерация ключа может занять продолжительное время:
Изменим секцию service auth, так что бы Postfix смог подключиться к серверу авторизации Dovecot:
Включим автосоздание системных почтовых папок (на тот случай, если мы будем пользоваться сервером в том числе и для обычной почты) добавив строку auto = create в секции почтовых папок:
Настроим что бы Dovecot доставлял письма в настроенное хранилище, добавив параметр lmtp:
Настроим сервис LMTP следующим образом:
Добавим следующие настройки в конец файла, что бы сообщить Postfix доставлять письма в локальное хранилище через сервис Dovecot LMTP. Так же отключим SMTPUTF8, так как Dovecot LMTP не поддерживает это расширение:
Создадим пользователей которые будут использовать сервер, создав соответствующую запись в системе и задав ей пароль, который будет использоваться для авторизации через smtps и imaps:
# Перезапустим Dovecot и Postfix:
Добавим в /etc/crontab задачу для автоматического обновления сертификатов:
На данном этапе сервер должен функционировать как почтовый сервер, т.е. можно подключиться почтовым клиентом и попробовать отправить и принять письма на другие почтовые ящики этого сервера или если выше открыли 25 порт, то и на другие почтовые сервера.
Теперь настроим клиент Delta Chat на ПК и смартфоне с Android.
Для подключения достаточно ввести созданный ранее на сервере почтовый адрес и пароль, Delta Chat определит какие порты можно задействовать, после чего можно будет добавить новый контакт, так же по адресу электронной почты, использованием действующего почтового адреса.
Первые сообщения будут отправлены в незашифрованном виде, на этом этапе идет обмен ключами. Далее сообщения будут зашифрованы помимо TLS используемого при передаче данных, сквозным шифрованием Autocrypt Level 1.
Так же есть возможность создания группового проверенного чата — где все сообщения зашифрованы сквозным шифрованием, а участники могут присоединиться, сканируя приглашение с QR-кодом. Таким образом, все участники связаны друг с другом цепочкой приглашений, которые гарантируют криптографическую согласованность от активных сетевых атак или атак провайдера.
Один из самых интересных моментов, которые я хотел проверить — посмотреть как выглядит сообщение в хранилище сервера. Для этого я отправил сообщение на неактивный аккаунт — в данном случае сообщение будет ждать своего получателя на сервере, и мы имея доступ к серверу сможем просмотреть его:
Return-Path:
Delivered-To: user1@secureim.example.com
Received: from secureim.example.com
by secureim.example.com with LMTP
id g/geNIUWzl+yBQAADOhLJw
(envelope-from )
for ; Mon, 07 Dec 2020 14:48:21 +0300
Received: from [127.0.0.1] (unknown [192.87.129.58])
by secureim.example.com (Postfix) with ESMTPSA id AA72A3193E11
for ; Mon, 7 Dec 2020 11:48:21 +0000 (UTC)
MIME-Version: 1.0
References:In-Reply-To:
Date: Mon, 07 Dec 2020 11:48:20 +0000
Chat-Version: 1.0
Autocrypt: addr=user2@secureim.example.com; prefer-encrypt=mutual;
keydata=xjMEX83vexYJKwYBBAHaRw8BAQdAYgkiTiHDlJtzQqLCFxiVpma/X5OtALu8kJmjeTG3yo
7NIDx1c2VyMkBzZWN1cmVpbS5zYW1vaWxvdi5vbmxpbmU+wosEEBYIADMCGQEFAl/N73sCGwMECwkI
BwYVCAkKCwIDFgIBFiEEkuezqLPdoDjlA2dxYQc97rElXXgACgkQYQc97rElXXgLNQEA17LrpEA2vF
1FMyN0ah5tpM6w/6iKoB+FVUJFAUALxk4A/RpQ/o6D7CuacuFPifVZgz7DOSQElPAMP4AHDyzcRxwJ
zjgEX83vexIKKwYBBAGXVQEFAQEHQJ7AQXbN5K6EUuwUbaLtFpEOdjd5E8hozmHkeeDJ0HcbAwEIB8
J4BBgWCAAgBQJfze97AhsMFiEEkuezqLPdoDjlA2dxYQc97rElXXgACgkQYQc97rElXXhYJgEA+RUa
RlnJjv86yVJthgv7w9LajPAgUGCVhbjFmccPQ4gA/iiX+nk+TrS2q2oD5vuyD3FLgpja1dGmqECYg1
ekyogL
Message-ID:
To:
From:
Subject:…
Content-Type: multipart/encrypted; protocol=«application/pgp-encrypted»;
boundary=«OfVQvVRcZpJOyxoScoY9c3DWqC1ZAP»
—OfVQvVRcZpJOyxoScoY9c3DWqC1ZAP
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification
—OfVQvVRcZpJOyxoScoY9c3DWqC1ZAP
Content-Type: application/octet-stream; name=«encrypted.asc»
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename=«encrypted.asc»;
wU4DKm2PBWHuz1cSAQdA4krEbgJjac78SUKlWKfVyfWt2drZf41dIjTH01J52HIg
aY/ZzCn/ch8LNGv3vuJbJS8RLHK7XyxZ4Z1STAtTDQPBTgNyNpRoJqRwSxIBB0AC
OVrbhsjNPbpojrm/zGWkE5berNF7sNnGQpHolcd+WyCdpqQAk3CaiQjxsm7jdO0A
gMtmXABw/TWcpTU/qOfW/9LBVwFZ/RPCKxCENfC0wau4TI+PMKrF0HODyWfBkEuw
e3WlQpN/t0eSUPKMiMhm7QM0Ffs52fPz0G6dfVJ2M6ucRRyU4Gpz+ZdlLeTLe3g2
PkKbb6xb9AQjdj/YtARCmhCNI48sv7dgU1ivh15r37FWLQvWgkY93L3XbiEaN/X9
EWBQxKql/sWP01Kf67PzbtL5uAHl8VnwInCIfezQsiAsPS2qiCb1sN3yBcNlRwsR
yTs2CPJTIi7xTSpM1S/ZHM5XXGnOmj6wDw69MHaHh9c9w3Yvv7q1rCMvudfm+OyS
/ai4GWyVJfM848kKWTCnalHdR4rZ3mubsqfuCOwjnZvodSlJFts9j5RUT87+j1DM
mQa4tEW8U5MxxoirFfbBnFXGUcU/3nicXI5Yy6wPP8ulBXopmt5vHsd68635KVRJ
2GMy7sMHcjyzujNCAmegIQgKqTLO5NUOtxW7v1OXL23pKx32OGcy8PtEJp7FBQYm
bUNAaz+rkmC971S2FOU0ZGV8LNp8ULioAbL629/JpPHhBOBJCsVnsXDIh6UBPbuM
06dU7VP6l8PNM87X/X1E3m2R1BCNkZghStQrt16fEoA+jm9F6PNtcap2S5rP9llO
klo/ojeciqWl0QoNaJMlMru70TT8a9sf6jYzp3Cf7qFHntNFYG1EcEy9YqaXNS7o
8UOVMfZuRIgNqI9j4g8wKf57/GIjtXCQn/c=
=bzUz
——END PGP MESSAGE——
Как видно, на сервере письма хранятся в зашифрованном виде, и в случае захвата сервера заинтересованными лицами, сообщения не будут под угрозой.
Для большей надежности можно использовать полное шифрование диска сервера и устройства на котором работает клиент, так же для подключения к серверу по ssh использовать ключи и использовать надежные, сложные пароли для почтовых учетных записей.
Вывод
Delta Chat — интересная альтернатива для self-hosted IM-мессенджера, позволяющий обмениваться сообщениями по существующим почтовым протоколам (что в перспективе позволяет не беспокоиться о блокировке), а высокая стойкость к перехвату сообщений, отсутствие центрального сервера и возможность развернуть на своем сервере, позволяет не беспокоится о том, что ваши данные попадут в чужие руки.
«Хочу как Дуров»: пишем простой мессенджер
В последнее время растёт популярность приложений для обмена сообщениями. Пользователи предпочитают мессенджеры, потому что они позволяют взаимодействовать в режиме реального времени. В этой статье мы разберём процесс создания простого приложения для обмена мгновенными сообщениями. Не будем сильно углубляться в нюансы разработки: мы напишем рабочий мессенджер, который в дальнейшем можно будет улучшить.
Статья подойдёт состоявшимся программистам и тем, кто только интересуется, как войти в IT.
Используемые технологии и инструменты
Подготовка
Структура будущего приложения выглядит примерно так:
Установите Node.js и MongoDB. Кроме того, нам понадобится библиотека AngularJS, скачайте её и скопируйте в папку lib каталога Client.
Примечание: созданный мессенджер можно будет интегрировать в качестве виджета в любой проект.
Серверная часть
Шаг 1. Запуск проекта
Перейдите в каталог Server и выполните команду:
Она запустит новый проект.
Укажите все необходимые сведения. В результате будет создан файл package.json примерно следующего вида:
Шаг 2. Установка зависимостей
Выполнение этих команд установит необходимые зависимости и добавит их в package.json :
Выглядеть они будут примерно так:
Шаг 3. Создание сервера
Создадим сервер, который обслуживает порт 3000 и возвращает HTML-файл при вызове. Для инициализации нового соединения сокету нужно передать HTTP-объект. Событие connection будет прослушивать входящие сокеты, каждый сокет будет выпускать событие disconnect, которое будет вызвано при отключении клиента. Мы будем использовать следующие функции:
Создайте сервер с именем server.js . Он должен:
В результате ваш сервер будет выглядеть примерно так:
Клиентская часть
Создайте файлы index.html в каталоге Client, style.css в каталоге CSS и app.js в каталоге js.
Client/index.html
Пусть это будет простой HTML-код, который получает и отображает наши сообщения.
Включите скрипты socket.io-client и angular.js в ваш HTML:
socket.io служит для нас клиентом. Он по умолчанию подключается к хосту, обслуживающему страницу.
В результате index.html должен выглядеть примерно так:
CSS/style.css
Чтобы придать нашей странице внешний вид окна чата, добавим немного стилей. Вы можете использовать любую CSS-библиотеку. Получим следующее:
js/app.js:
Создайте Angular-приложение и инициализируйте соединение сокета. Для этого нужны следующие функции:
Теперь, когда будет набран текст сообщения и нажата кнопка, вызовите функцию отправки сообщения. Когда сокет получит сообщение, отобразите его.
В результате app.js будет выглядеть примерно так:
Запуск приложения
Перейдите в папку с server.js и запустите команду:
Сервер начнет работу на порте 3000. Чтобы в этом убедиться, перейдите по ссылке в браузере:
Ваш собственный мессенджер готов!
Что можно улучшить?
Можно создать базу данных для хранения информации о пользователях и истории сообщений. Лучше, если она будет масштабируемой, потому что в дальнейшем это позволит добавить больше функций.
Установите Mongoose или MongoDB для работы с базами данных Mongo:
Можете ознакомиться с документацией по их использованию: mongoose и mongodb.
Схема должна получиться примерно следующего вида:
Собеседникам могут быть присвоены следующие статусы:
Предположим, что собеседник отклонил запрос на приватную беседу. В таком случае отправитель должен иметь возможность снова направить запрос.
Неплохо было бы реализовать для пользователя функционал сохранения сообщений в дополнительные коллекции. Пусть каждый её объект содержит сообщение, отправителя, получателя и время. Спроектируйте вашу базу данных в соответствии с конкретными потребностями и методами обработки сообщений.
Также вы можете создать REST API для обслуживания клиента. Например, конечную точку, отправляющую домашнюю страницу, из которой пользователи могут выполнять другие запросы.
Некоторые из возможных конечных точек API:
Вот какой мессенджер получился у автора статьи:
Внешний вид приложения
Исходный код приложения можно найти на GitHub.
Пишем мессенджер на C#. Часть 1. Вёрстка
Клиент-серверная разработка — одна из самых востребованных отраслей программирования. Зная её азы, можно создавать как мессенджеры, так и онлайн-игры.
В этой серии статей мы напишем клиент-серверное приложение на C# — простейший мессенджер. Серия состоит из трёх частей:
Язык C# пригодится в разработке чего угодно. Возможности WPF (система создания графических интерфейсов) позволяют создавать красивые и функциональные приложения для Windows, а ASP.NET — мощные серверные приложения.
Я постараюсь объяснить подробно, но охватить всё невозможно, поэтому вам нужно знать основы C#, ООП, ASP.NET, WPF и работы в Visual Studio.
Вот несколько статей, с которыми стоит ознакомиться, если вы чего-то не знаете:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Структура приложения
Мы не рассматриваем регистрацию, поиск контактов, хранение сообщений, продвинутый дизайн. Вместо этого вы узнаете азы создания клиент-серверных приложений и сможете сделать всё самостоятельно.
Исходный код мессенджера вы найдете на GitHub.
Приложение мы поделим на экраны:
Экран — это элемент Border, который по умолчанию скрыт от пользователя. Виден будет только активный экран.
На экране авторизации пользователь сможет ввести логин и пароль, чтобы войти. Если он ввёл верные данные, то перейдёт на экран с контактами, иначе — увидит сообщение об ошибке.
На экране с контактами видны имена других пользователей, с которыми ведётся переписка. Чат открывается при нажатии на имя другого пользователя.
На экране с чатом видна переписка с одним конкретным контактом. Пользователь может написать и отправить новое сообщение или вернуться к экрану с контактами.
Верстаем экран авторизации
Начнём с определения стилей. В них минимально обозначим, как должны выглядеть элементы, и сразу укажем, что экраны по умолчанию должны быть скрыты:
Теперь сверстаем сам экран авторизации — он должен быть видимым:
Как создать свой мессенджер: ответы на популярные вопросы
Время чтения: 7 минут
Если вы сомневаетесь нужно в ли ступать на территорию разработки мессенджеров, просто взгляните на последние цифры. В 2021 году приложением Facebook Messenger пользуются 1,3 миллиарда человек во всем мире, а WhatsApp есть на телефоне у 2 миллиардов пользователей (¼ часть населения земли, на секунду).
Хорошая новость заключается в том, что у большинства установлено сразу несколько приложений, поэтому все перечисленные компании не конкурируют между собой, а дополняют друг друга. Например, WeChat популярен в основном в азиатских странах, а Slack используют 12 миллионов человек для коммуникации внутри компаний. Аналитики ожидают, что количество активных пользователей будет только расти, а рынок приложений для обмена сообщениями будет цвести и пахнуть.
В этой статье мы подробно расскажем о том, как разработать и монетизировать приложение для обмена сообщениями. Тех, кто дочитает до конца, ждет сюрприз — бесплатный расчет стоимости приложения.
Ключевые функции мессенджеров
Must-have функции
Авторизация
Для пользователя регистрация не должна занимать больше, чем две минуты. Чтобы ускорить процесс, мы рекомендуем добавить интеграции с социальными сетями, регистрацию по номеру телефона или адресу электронной почты. После этого юзеры смогут выбрать фотографию профиля и имя. В некоторых приложениях, например, в Telegram, есть дополнительная функция, которая скрывает номер телефона от других, также в мессенджере можно создавать сразу несколько профилей. Например, рабочий и личный, или российский и заграничный, если вы живете на две страны.
Доступ к контактам
Эта функция значительно упрощает процесс авторизации, поскольку пользователь может зарегистрироваться, синхронизировать свои контакты и сразу отправить кому-нибудь сообщение, а не проходить через семь кругов ада, специально сохраняя каждый нужный ему номер в мессенджере.
Обмен сообщениями
Обмен файлами
Возможность обмена медиафайлами — еще одна причина, почему люди будут регулярно обращаться к вашему сервису. Разрешите им отправлять друг другу фотографии, видео, гифки и документы, и тогда многие будут использовать чаты в качестве облачного хранилища (да-да, мы все искали когда-нибудь фотографию карты или паспорта в переписках).
Push-уведомления
Как создать свой мессенджер без функции уведомлений? Это невозможно! В эпоху, когда мы так боимся пропустить что-то важное, пользователи обязаны немедленно знать, что они получили новое сообщение. Наверняка, каждый из нас хоть раз сходил с ума, ожидая обратную связь от потенциального работодателя — не нам вас убеждать в том, насколько важны push-уведомления в чатах 🙂
Защита данных
Для любого общения — по работе или личного — важна конфиденциальность. Данные пользователей обычно хранятся на серверах, которые принадлежат приложениям, а сообщения шифруются и передаются между устройствами с использованием разных протоколов связи. Напишите нам, и мы расскажем больше технологиях безопасности данных.
Nice-to-have функции
Звонки
Чат-боты
Эта функция привлечет бизнес-клиентов в ваше приложение-чат. Не пугайтесь слова «Боты». Чат-бот — это всего лишь автоматическое программное обеспечение, которое поддерживает онлайн-связь с клиентами, отправляет автоматические сообщения и помогает с ответами на часто задаваемые вопросы. Они также могут позвать человека, если вопрос пользователя пришелся роботу «не по зубам».
Как создать свой мессенджер, который принесет прибыль?
Как найти надежного разработчика?
Проверить команду разработчиков «на прочность» можно в два шага:
Помимо этого, для стартапа важно соблюдать бюджет и сроки. Поэтому мы искренне советуем выбрать того, кто разрабатывает приложения на React Native. Почему? Сейчас объясним.
React Native — это фреймворк, который был создан Facebook 5 лет назад. Код приложений пишется на JavaScript – одном из самых популярных языков программирования во всем мире. Есть 3 основных преимущества работы с компанией, которая работает на React Native.
JavaScript. Этот язык — один из самых распространенных среди разработчиков, поэтому вы сможете найти подрядчика для разработки вашего приложения быстро и безболезненно.
Нативные UI-элементы. Компании Facebook принадлежат бесконечные библиотеки нативных UI-элементов для интерфейса. Как это поможет вашей бизнес-идее? Очень просто — это означает, что ваше будущее приложение функционировать как нативное. Производительность мессенджера будет такой же, как если бы вы разработали его на Java или Swift.
Мы работаем с React Native последние 4 года и еще ни разу не разочаровались. Фреймворк позволяет нам создавать MVP (минимально-жизнеспособный продукт)для наших клиентов за 3 месяца. Это означает, что вы придете к нам с идеей, и через 90 дней у вас будет рабочая версия продукта, которую можно тестировать, собирать обратную связь и показывать потенциальным инвесторам.
Сколько стоит создать приложение-мессенджер?
Вот мы и дошли до самой важной части статьи — той, которая про стоимость и сроки. Разработка мессенджера – сложный процесс, в котором участвует команда разработчиков, дизайнеров, проектных менеджеров и QA-специалистов. Выбросить кого-то из команды и при этом сделать крутой продукт нельзя 🙂
Мы подробно рассказали о том, как создать свой мессенджер и как его можно монетизировать. Теперь давайте посчитаем, сколько это стоит!
Key in your e-mail address to get a full breakdown of the estimation with all details
Thank you! You will be contacted soon!
Итого
Пишем мессенджер с открытым исходным кодом
Давным-давно в одной далекой стране была компания America Online. И был у нее удивительный частный Интернет за заборчиком, где вместо URL-ов были «keywords»: что-то среднее между адресом веб страницы и купленным ключевым словом в рекламе. Компании боролись за интересные ключевые слова, как сейчас борются за домены, а реклама выглядела так: «посетите нас во всемирной сети по адресу www.example.com, или наберите AOL Keyword: ‘banking'».
История имеет свойство повторяться. Сейчас роль Америки Онлайн играют основные мессенджеры: все они за заборчиками, несовместимы друг с другом, все изобретают свои keywords, желают схватить пользователя и уже никогда не отпускать. Компании не заинтересованы в открытости: более крупные игроки не желают делиться пользователями с более мелкими и уж тем более становиться открытыми. В результате невозможно послать сообщение даже из WhatsApp в Facebook Messenger, несмотря на то, что оба принадлежат одной компании. Да и пользователи ценят надежность и удобство выше абстрактной открытости, хотя многих раздражает, что часть друзей, например, в Telegram, часть в WhatsApp, а родители в Skype.
А вот роль открытого интернета, к сожалению, сегодня не играет никто. Ситуацию хочется изменить. Если XMPP не справился, может быть кто-то другой сможет? И тут рассказ про Tinode.
Что такое Tinode
Tinode — мессенджер с полностью открытым исходным кодом на Github. Все клиентские приложения (ReactJS и Андроид) лицензированы под Apache 2.0, для того, чтобы упростить создание коммерческих приложений на основе Tinode, сервер под GPL 3.0. Цель проекта — создать федерированный мессенджер, который прост и удобен как для пользователей, так и для операторов. Поставил — и все работает, как MySQL или Nginx. В долгосрочной перспективе цель проекта – создать открытую альтернативу существующим проприетарным мессенджерам, повторить в отношении мессенджеров то, что сделал Android в отношении операционных систем для мобильных телефонов.
Что он умеет
Поддержка множественных устройств.
У всех есть смартфон, иногда не один, плюс часто удобно использовать web-приложение с основного компьютера. Поэтому поддержка множественных устройств была одним из главных требований к проекту, что определило основные архитектурные решения. Если пользователь авторизуется с нового устройства, то не хочется, чтобы он начинал с чистого листа как в WeChat. А это означает, что нужно и адресную книгу, и сообщения хранить на сервере, что и было реализовано.
Очевидно, что хранение информации пользователя на сервере подходит не всем, так как создает риски нежелательного доступа: чем больше копий данных хранится в разных местах, тем выше вероятность, что что-то пойдет не так. Для этого предусмотрена возможность эфемерных сообщений и сообщений, которые удаляются с сервера после доставки клиенту. Технически, существует и возможность не хранить контакты на сервере постоянно — клиент отправляет их на сервер в момент подключения (login), затем они удаляются после logout. Однако, авторы посчитали это непрактично сложным и не стали делать.
Онлайн статус
Трансляция онлайн/оффлайн статуса пользователя в мессенджерах воспринимается как что-то само собой разумеющееся, однако, это весьма тяжелая в реализации фича. Нужно, чтобы она «просто работала», предсказуемо и надежно. Надежность работы исключила генерацию статуса на клиенте, как это реализовано в некоторых XMPP приложениях. В случае Tinode, сервер генерирует онлайн статус и рассылает по адресной книге, что, опять же, требует хранения контактов на сервере и их синхронизацию с клиентскими приложениями.
Простота протокола
Протокол хотелось сделать таким, чтобы кривая обучаемости была пологой – не нужно знать всего, чтобы начать. Спецификация получилась очень компактной: 10 запросов клиента, 5 ответов сервера. Например, по сравнению с 200+ страницами только core XMPP, не считая extensions, это почти записка на салфетке.
Представление данных отделено от сетевого протокола. Протокол лишь требует определенную структуру данных, но не требует, чтобы они передавались по сети каким-то определенным образом. Сейчас сервер поддерживает JSON по websocket и long polling, c TLS и без, плюс gRPC по TCP. Поддержка gRPC была реализована одним разработчиком за две недели, включая написание текстового клиента на Питоне. Добавление поддержки иных форматов данных и протоколов, например, MessagePack или Noise, вряд ли займет намного больше.
Расширяемость
С одной стороны, хочется, чтобы все работало сразу, например, чтобы основной функционал был сравним с WhatsApp и Telegram прямо из коробки. С другой, потребности у людей разные и нужно иметь возможность расширять функционал. Поиск баланса похож на выбор между монолитной архитектурой и микросервисами: нежелательно иметь неизменяемый монолит, и, аналогично, плохо получить получить зоопарк микросервисов, управление которыми превращается в отдельную задачу.
Было принято решение разделить функционал на три части — основной, сетевой и вспомогательный. Основной — это то, что позволяет Tinode выполнять основную функцию — пересылать сообщения. Сетевой — функционал взаимодействия в серверами, как формат передаваемых данных и сетевой протокол. Вспомогательный — то, что решает чью-то локальную задачу, например, поддержка конкретной базы данных в качестве бэкенда или какой-то метод авторизации, но никак не влияет на другие сервера или пользовательские приложения. Основной функционал реализован в основном коде. Сетевой функционал выделен, но также хранится в основном репозитории для того, чтобы по возможности избежать создания несовместимых серверов. Вспомогательный реализован в виде плагинов — компилируемых Go интерфейсов (поддержка разных баз данных, разных авторизаторов, пуш нотификации, валидаторы по емейл или телефону, поддержка каптчи и т.п.) и gRPC endpoints (чатбот и поисковый интерфейс).
Прочее
Почему Go?
Сервер для мессенджера по сути роутер: получает сообщение из одного канала, как-то его обрабатывает, затем передает в другой канал или каналы. Go (как и Erlang, но это уже другая история) идеально подходит для создания такого функционала т.к. содержит примитивы goroutine и chan, делающие организацию потоков и обмен данными между ними эффективным и простым.
Безусловно, роутер можно написать и на C/C++, и на Java. Однако, при прочих равных, код скорее всего получится более сложным и потребует больших усилий для избежания дедлоков.
А что потом?
Федерация
Одна из основных задач для Tinode на ближайший год — создание платформы для федерации. Так, чтобы любой желающий мог запустить свой Tinode сервер, который бы мог обмениваться сообщениями с любым другим сервером, точно так, как это возможно с емейлом. Уже сейчас возможна кластеризация серверов. Сетевой обмен между сервером и клиентами идет по TLS websocket, что для внешного наблюдателя мало отличимо от простого HTTPS трафика.
Публичный DNS, вероятно, будет использоваться, по крайней мере первоначально. Однако, в будущем поиск чат-серверов будет осуществляться также, как это сделано в Bittorrent — при помощи DHT, распределенной хеш таблицы.
Хочется также избежать и проблем, за которые часто критикуют XMPP. Например, XMPP сервера очень разговорчивы. До половины сообщений является дублирующими, когда XMPP-клиент рассылает онлайн уведомления индивидуально каждому контакту из адресной книги.
Репутация и распределенное принятие решений
Системы обмена сообщениями больше всего похожи на емейл. Как известно, значительная часть электронной почты — спам. Не хочется повторять чужие ошибки, поэтому механизмы, ограничивающие спам, должны быть сразу встроены в систему. Полностью задача пока не решена, но есть общее направление:
Если посмотреть на распределенную систему принятия решения и учета репутации с высоты птичьего полета, то станет заметно сходство с blockchain. Возможно, blockchain (но не криптовалюта) может быть использован в качестве основы для построения распределенной системы репутации, хотя пока и не очевидно каким образом.
Шифрование
Ну а как же в наши дни без шифрования сообщений? Чаты между двумя людьми, вероятно, будут шифроваться OTR. С групповыми чатами пока непонятно. Все известные схемы шифрования групповых чатов либо имеют значительный недостатки, либо тяжеловесны и сложны в реализации. Также, не очевидно, насколько важно шифрование групповых чатов: «Если тайну знают двое – это уже не тайна, а если трое – это уже базар.»