Что нужно чтобы создать свой мессенджер. Пишем свой мессенджер P2P

Всем доброго дня! Хочу рассказать про один из проектов, который мы с друзьями недавно запустили. Проект - не что иное, как уже указанное в название статьи мобильное приложение Converse App (от англ. "Общайся"). Приложение представляет собой VoIP-звонилку и классический мессенджер в одном стакане. Многие из вас, дочитав до сюда, уже начнут задаваться вопросом: "А зачем? Ведь это все уже давно есть".

Чтобы ответить на этот вопрос, хочу рассказать о возникновении идеи создания мобильного приложения. Все началось с того, что бизнес, связанный с VoIP-телефонией, в котором мы плаваем уже несколько лет, стал приносить все меньше прибыли и удовольствия (явления не связанные, кстати =)). А наши клиенты с каждым годом начали становиться все ленивее и нетерпеливее. Такие вещи, как необходимость подписания договора, время на предоставление и настройку услуги, необходимость подписания бухгалтерских бумажек каждый месяц - все это потихоньку стало приобретать форму раздражающих факторов для них. "Аларм" был нами замечен, и мы начали думать, куда бы приложить все накопленные знания и опыт, и как сделать наши услуги более дружелюбными для наших клиентов. Это был 2012 год. Решено было переориентироваться на мобильное решение. И первым вариантом решения было предложено создание собственного сип-клиента в классическом его понимании. Идея совсем не новая, а при ближайшем рассмотрении оказалась и совсем не продуктивной: те же матрешки, только в профиль. Тогда мы поплотнее загуглили, куда сейчас катится IT-мир, и выбрали идею создания собственного приложения. Многие снова зададутся вопросом: "А зачем? Если это все уже на рынке" А затем, что мобильных пользователей становится все больше, смартфонов у них тоже становиться все больше, и эта рыночная ниша постоянно растет, а значит, вероятность того, что новый продукт сможет активно наращивать аудиторию, достаточно высока. Достаточно высок был и риск окончательно остаться не у дел, если сидеть на старом месте. Поэтому мы присели на дорожку по старой доброй традиции и отправились в трудный, но интересный путь по созданию своего мобильного приложения.

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

1) бесплатно звонить внутри приложения,

2) платно звонить из приложения на любой телефонный номер в любую страну,

3) обмениваться в чатах и групповых чатах быстрыми сообщениями, фото, видео и местоположением.

Image-slider__item" data-cycle-pause-on-hover="#slider_728 .image-slider__crop" data-cycle-pager="#slider_728 .image-slider__pager" data-cycle-prev="#slider_728 .image-slider__prev" data-cycle-next="#slider_728 .image-slider__next" data-cycle-swipe="true" data-cycle-loader="wait" data-cycle-allow-wrap="false">

Добавили мы в Converse App и несколько своих фишек, а именно функцию привязки дополнительных устройств, которая дает возможность расшарить свой аккаунт с другими устройствами и использовать баланс коллективно для платных звонков. Это могут быть как разные устройства одного и того же человека (тогда и звонить, и писать можно с любого из устройств с полной синхронизацией и дублированием чатов при необходимости), так и устройства, принадлежащие другим людям, кому вы готовы, например, оплачивать зарубежные звонки.

А еще мы очень сильно поработали над качеством голосовой связи и смогли добиться того, чтобы голос ходил даже в самых "узких" интернет-каналах GPRS и Edge. Делали это специально, так как, несмотря на повсеместное развитие 4G, на постсоветском пространстве все еще преобладают старые мобильные технологии, с которыми приходится сталкиваться ежедневно.

На этом я хочу закончить свой первый рассказ. И так слишком много "букаф" получилось. В следующих постах постараюсь рассказать о самом процессе создания, технических характеристиках и планах на ближайшее будущее. Пробуйте наше приложение Converse App , делитесь впечатлениями. Кстати, каждому новому пользователю подарим по $2 для тестирования наших платных звонков.

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

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

Как мы пришли к этой идее?

В определенный период времени мы не могли не заметить повышенный интерес к мессенджерам, в основе которого лежит диалог между людьми, а не чат-боты, как, например, в Telegram. Следует разобраться в привлекательности подобных проектов.

Допустим, вы хотите сделать приложение а-ля Авито, где люди выкладывают объявления по продаже б/у товаров. Покупатель листает ленту или находит нужный ему товар, ему не нужно ждать отклика на заявку, он сразу же напрямую ведет диалог с продавцом и договаривается о встрече. Быстро, удобно, без кучи созвонов и поиска контакта в WhatsApp или Telegram.

Осознав все плюсы мессенджеров, основанных на общении между людьми, мы решили зайти дальше. Мы подумали: «Что получится, если мессенджер не будет загоняться в жесткие рамки, а будет иметь возможность включать в себя различные функции?» Получится новое коробочное решение а-ля "поставить аналог вотсапа себе на сервер с возможностью доработок". Несомненный плюс данного решения в том, что стоить оно будет явно меньше, чем в других студиях при разработке с нуля (за аналог WhatsApp в среднем называется стоимость от 45000$ до 55000$). Это позволит вам протестировать вашу идею по адекватной цене и решить, взлетает проект или нет.

Что уже включает коробочное решение?

Регистрация и авторизация по номеру телефона
Профиль пользователя, он может заполнить ФИО и поставить свое фото
Список пользователей, контакты
Список диалогов
Окно Чата
Статус сообщения

Главный плюс данного коробочного решения заключается в его гибкости. Вы берете у нас основу и добавляете к ней всё, что угодно, в зависимости от ваших целей и задач. Например, просмотр видео и фото, ленту новостей и т.п.

Архитектура приложения выглядит следующим образом:

Objective-C и Java для iOS и Android приложения
Node.js - держим сокет-соединения для получения сообщений в режиме реального времени
Redis -храним стек сообщений для отправки
APN/FCM push-сервер используем для отправки push-уведомлений, если приложение свёрнуто
Bitrix.Framework для генерации экранов мобильного приложения и гибкого развития приложения
MySQL - для хранения пользователей, ролей доступа, историй сообщений и кастомизированных данных приложения
1С-Битрикс - для административного управления мессенджером

Работа с конкретными задачами

Мой знакомый, Павел, не так давно обратился к нам за помощью. Он владеет консалтинговым агентством, специализирующимся на повышении продаж оптовиков и производств. Его проблема заключалась в том, что после завершения консалтинга, клиент переходил на консультации его помощников. Это, в конечном счете, отражалось на качестве оказываемых услуг, а также на прибыли: из-за ошибок помощников Павел недополучал по 50-100 тысяч рублей в месяц.

Мы с ним пришли к модели, что при внедрении месседжера он сможет получить вот такие ценности:

Удалённо оказывать консультационные услуги лично, без потери качества
Сделать видео-ответы на 40 самых популярных вопросов клиентов и, в случае возникновения очередного вопроса из этого стека, отправлять ссылку на видео клиенту без дополнительных трудозатрат
Сэкономить на зарплатах помощников
Увеличить пропускную способность услуги
Использовать консультации в приложении, как вау-эффект для новых продаж основного продукта

Пообщавшись, мы пришли к выводу, что к базовому функционалу потребуется несколько дополнительных экранов:

Групповой чат (чтобы клиенты "заряжали" друг друга)
Экран с тарифами услуг компании

Плюсом добавился брендированный под фирменный стиль компании дизайн. С учётом наших цен приложение вышло чуть дороже 100 тыс. Причём, без привязки к нам. Любой php-разработчик, знакомый с Bitrix.Framework смог бы сделать эти доработки под Павла. На данный момент приложение дорабатывается, но можно посмотреть линкованные мокапы будущего приложения.

Перспективы развития

Ввиду того, что проект нашего мессенджера в первую очередь является стартапом, мы развиваем его в формате Customer Development. За полторы недели, прошедших с момента запуска проекта, уже продано 9 лицензий. Попробовавшие наше коробочное решение клиенты предложили развиваться в следующих направлениях:

разработка функции добавления в окна чата различных мультимедиа (фото, видео, файлы), активных ссылок;
работа над улучшением дизайна;
создание групповых чатов.

Что думаете по поводу развития данного проекта? Стоит ли активно добавлять функционал или лучше оставить гибкость платформы, при которой любой программист сможет доработать приложение под клиента?

Если вас заинтересовало наше новое коробочное предложение, то пишите мне на почту . Буду рад ответить вам на любые вопросы.

Разработка мессенджера для смартфонов или сайта может стать успешным стартапом . Уже сейчас мессенджеры занимают первое место по количеству скачиваний в мире.

Стоит ли создавать еще одно приложение messenger?

У каждого пользователя на телефоне установлены два-пять мессенджеров. Все они используются в той или иной степени.

Со временем некоторые приложения-мессенджеры теряют лидерские позиции, уступая место новым. Так, за один год Skype с первого места, которое он занимал несколько лет, переместился на четвертое. На пятом месте Telegram. Но, похоже, это тоже временный расклад, так как тот же Telegram быстро завоевывает рынок. В 2017 году наметился новый тренд - публичные каналы и чаты. Их наличие привлекает новых пользователей, по сути, превращая мессенджеры в социальные медиа. Возможно, это и стало причиной роста популярности Telegram.

Рейтинг популярности мессенджеров

Источник vc.ru

Статистика роста количества пользователей мессенджеров показывает: потенциал у приложений для обмена сообщениями есть. Но при запуске стартапа нужно быть готовым к конкуренции. Разработка мессенджера для iOs или на Andriod начинается с правильной постановки задачи и подбора инструментов. Так мы получим приложение, которое удовлетворит потребности пользователей.

Как создать мессенджер, востребованный пользователями

Изначально мессенджеры создавались или как чаты, например WhatsApp, или как приложение для звонков - Skype, Viber. Позже в мессенджеры стали добавлять функции, которых изначально не было. Так, в WhatsApp добавились функции аудиозвонков, потом видео. Дальше появились открытые API, боты, маски, статусы, приемы платежей, публичные каналы. Однако внедрить новый функционал или изменить структуру, когда у мессенджера миллионы пользователей, сложно. В том же WhatsApp до сих пор нет API и ботов.

Основная сложность при создании приложения для отправки сообщений на Android или iOS - разработка архитектуры. Структуру приложения нужно разработать таким образом, чтобы в нее можно было безболезненно добавлять новые возможности.

При разработке мессенджера мы закладываем в его основу не только то, что уже есть в других приложениях, но и то, что может быть востребовано в будущем.

Наш подход к разработке архитектуры мессенджера

Большинство подходов к проектированию и разработке архитектуры сводится к модульной системе. Но модульность разная, да и сами модули могут быть огромными и монолитными.

В мы проектируем и разрабатываем архитектуру по принципам Clean architecture.

Чистая архитектура , описанная Робертом Мартином, позволяет спроектировать гибкую и масштабируемую систему.

В современном программном обеспечении это распространенная практика, но достичь Clean architecture получается не у всех. В своей работе мы придерживаемся ряда определенных принципов и получаем ожидаемый результат. На рисунке новая архитектура, которую презентовал Google. C помощью этого подхода и наших собственных доработок мы реализовываем чистую архитектуру на Android.

Гибкость, масштабируемость и тестируемость

В процессе работы мы делаем так, чтобы архитектура делилась на автономные слои. Тогда бизнес-логика, представление и объекты данных разделены и могут меняться независимо друг от друга. Вне зависимости от размеров системы такой подход сохраняет ее гибкость, масштабируемость (масштабирование количества функций) и тестируемость.

Масштабируемым делаем не только код, но и саму инфраструктуру системы.

Производительность приложения

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

В процессе работы думаем о задаче клиента и с этим подходим к выбору инструментов.

Как правило, программируем на PHP. Этот язык программирования используется в Whatsapp, Facebook, Stackoverflow. PHP не уступает остальным языкам по производительности и способен выдержать высокие нагрузки. Плюс этого языка в том, что после выполнения задачи ресурсы сервера высвобождаются, а правильно построенная архитектура и хороший стек технологий перекрывают недостатки языка.

Стоимость разработки проекта на PHP в разы дешевле, чем на языках типа Java, Python. В то же время приложение не уступает по производительности.

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

Работа с большим количеством пользователей и большими нагрузками

В работе используем платформу NodeJS. Как показывает наш опыт, эта платформа подходит для создания чатов и мобильных приложений. NodeJS хорошо устроена и позволяет строить высоконагруженные системы. С коробки чат на NodeJS способен выдержать нагрузку в 10 000 подключений.

Разработка мессенджера для Android или iOS под данную платформу требует использовать Java Script. Этот язык популярен, поэтому найти разработчиков не проблема.

Rethink - используем эту NoSQL DB, так как она производительнее конкурентов. У RethinkDB транслятор языка запросов, так называемого ReQL, реализован не на уровне сервера, а встраивается в качестве предметно-ориентированного языка в язык, на котором пишется клиентское приложение.

Таблицы базы данных хранят JSON-документы, допускающие любой уровень вложенности. У каждого документа прописан уникальный для таблицы-родителя первичный ключ «id». Ссылаясь на ключ, получаем документ. Каждая функция ReQL-запроса работает с данными, полученными из предыдущей функции цепочки. Это позволяет строить более гибкую архитектуру высоконагруженных проектов и не думать о сложности структур данных.

Конкурент NoSQL СУБД - MongoDB. Эта платформа популярна на рынке, но популярность не всегда залог успеха. У MongoDB ряд проблем: при удалении документов не чистится место на диске поэтому приложение должно быть построено так, чтобы документы (файлы объектов) не удалялись часто. Также MongoDB плохо работает с многочисленными массовыми операциями над документами, что противоречит правилам построения высоконагруженной системы.

Основная проблема при построении высоконагруженных проектов - построение архитектуры и потом подстраивания бизнес-логики системы под нее. Такой проект не всегда справляется с большими нагрузками. Поэтому мы делаем наоборот: прорабатываем бизнес-логику всей системы, а уже под нее создаем эффективную архитектуру. В такое приложение можно добавлять новые функции. Оно не потеряет в производительности и не боится высоких нагрузок.

Разработка интерфейса мессенджера

Пользователю должно быть понятно, как работать, и работать должно быть удобно. Поэтому чаще мы рекомендуем использовать нативный дизайн, так как он удобен и предсказуем. Приложение одинаково ведет себя на разных устройствах. Пользователь видит знакомые элементы, знает, как их использовать, и у него не возникает вопросов, как пользоваться мессенджером.

При разработке дизайна важно:

Проработать пустые состояния чатов, экранов, разделов, где пока еще ничего не происходило. Так пользователю будет понятно, какое действие нужно совершить.

Проработать обратную связь. Отправка сообщений, скачивание файлов занимает время. В этот момент пользователю важно показать, что процесс идет.

Все возможные ошибки, например, если пропал интернет, пользователь должен понять, что что-то пошло не так.

Для верификации номера телефона поставить ограничение по времени на повторную отправку sms с кодом верификации, так как сообщение может еще не дойти, а пользователь успеет шесть раз нажать на повторную отправку кода.

Предупредить пользователя о том, что он использует мобильный интернет в момент отправки большого файла.

Удобство внутри чата и предотвращение нелепых ошибок

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

Перед отправкой голосовых сообщений, важно, чтобы пользователь мог их прослушать. Должна быть также возможность исправить ошибку или удалить нежелательное сообщение. Создание приложения для отправки сообщений iPhone или Android требует скрупулезной проработки этих и других нюансов.

Приватность

В интернете можно найти программы, которые позволяют взломать мессенджер и получить личную переписку. Первая задача разработчиков — обеспечить полную анонимность, даже без привязки к номеру телефона и возможности как-то распознать личность. Вторая задача — исключить риски взлома.

Здесь есть нюансы. Скажем для полного анонимного чата собеседники без привязки к конкретным признакам — номеру телефона, имени, локации — должны понимать кто есть кто. Для этого нужно использовать одноразовый шифр, которым могут пользоваться все, но он не будет повторятся дважды. Приглашение людей в такую беседу, также происходит при помощи “ключа”, который работает только раз, и задается только самим человеком.

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

Сколько стоит создать свой мессенджер

Цена разработки мессенджера зависит от того, сколько времени займет работа над приложением. Чем сложнее функционал, тем выше стоимость разработки. Окончательную цену на разработку мессенджера для iOS, андроид или сайта мы сможем назвать только после того, как поймем, какие задачи надо решить.

Стоимость продвижения и поддержки

Разработка мессенджера для Андроид или для iOS - первый этап. Если это не корпоративный чат, то мессенджер надо продвигать. Для этого надо в маркетинговый бюджет заложить определенную сумму. Сюда входит:

ASO-продвижение (App Store Optimization) - комплекс работ для оптимизации мобильного приложения. А именно правильное составление title (название), keywords (ключевые слова), descriptions (описание), в целях максимального увеличения видимости вашего приложения в поиске

Оплата за размещение в магазинах Google Play и App Store.

После запуска приложение необходимо развивать и обновлять:

Устранить ошибки и реагировать на поступившие жалобы пользователей

Добавить новые функции.

С чего начать создание приложения для отправки сообщений на Android или iPhone

Разработка мессенджера под заказ начинается с постановки задачи.

Напишите или позвоните нам, мы договоримся о встрече, обсудим задачу и поможем найти оптимальное решение как создать востребованный мессенджер для Android и iOS.

Для разработки хорошего продукта нужно придерживаться четкой методики проектирования основанной на таких методологиях как Design Thinking или Human Centered Design. Такой процесс отнимает много времени, что в современных условиях не всегда приемлемо. В тех случаях, когда за короткий срок нужно разработать концепцию продукта, можно получить нужный результат сократив количество основных шагов к минимуму.

Проблема

Довольно часто случается так, что стоит задача подготовить концепцию некоего продукта, или минимально жизнеспособный продукт (MVP), но на входе дизайнер получает минимум информации, а на глубокий анализ и исследования нет времени. В таких случаях нужно не впадать в панику а постараться осмыслить входящую информацию, дополнив ее гипотезами и предположениями. В методологиях проектирования, таких как Design Thinking и Human Centered Design, сущесвует вполне определенный перечень шагов количество которых вполне можно сократить для ускорения процесса. Вот эти основные шаги:

Определение целей и потребностей проекта.
Исследование существующих решений.
Персонажи и пользовательские сценарии.
Функционал и информационное наполнение.
Концептуальные прототипы.

Ниже рассмотрим каждый шаг подробнее на основе реального кейса.

1. Определение целей и потребностей проекта

Передо мной стояла задача разработать концепцию мобильного приложения для общения, то есть мессенджера, сама задача была сформулированна достаточно лаконично:

Создание лидирующего мессенджера среди русскоязычных пользователей мобильных телефонов. Ключевые опции:

удобный, простой, красивый интерфейс;
высокая виральность (шаринг контента);
обмен текстовыми, видео- и аудио сообщениями, фотографиями;
обмен метками на карте;
гео-чаты (публичный чат, привязанный к определенной локации).

Аудитория: молодые люди активно использующие Интернет и мобильные телефоны для общения, и решения повседневных задач.

Информации мало для того что бы сразу перейти к разработке концепции, по этому угубляемся в проблему и исследуем существующие решения.

2. Исследование существующих решений

На рынке уже существуют несколько решений которые можно взять в качестве примера: WhatsApp, WeChat, KakaoTalk. Изучаем как они устроены, их недостатки, которые следует избегать, и достоинства, которые можно было бы позаимствовать.

Естественно, для того что бы “погрузиться в тему” нужно установить все эти приложения на телефон и попользоваться ими некоторое время. Фокусируясь на задаче можно делать зметки и скетчи.

3. Персонажи и пользовательские сценарии

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

Благодаря профилю персонажа дизайнер фокусируется на основных задачах и требованиях. После этого можно перейти к описанию основных пользовательских сценариев для того что бы представить как будет работать будущий продукт. Сценарии помогают разгуляться фантазии и придумать действительно интересные решения, но для этого нужно предварительно поштормить мозгами. Хочу подчеркнуть, что в данном случае, когда у нас минимум входящих данных, пользовательские сценарии играют ключевую роль: во время описания будущего опыта использования фактически проводилось проектирование продукта, по этому так было важно охватить все ключевые функции.

Благодря сценариям дизайнер и вся команда, в том числе и клиент, начинают лучше понимать что должно получиться в итоге, как будет использоваться будущий продукт, кем и в каком контексте. Я написал 5 ключевых сценариев:

Сценарий 2. День. Андрей находится в университете. По дороге в аудиторию он вспоминает, что у Саши, одного из его друзей, вчера был день рождения а он его так и не поздравил. Остановившись у самой двери Андрей достаёт телефон, запускает IM и находит в списке Сашу Васильева и начинает с ним чат. Андрей любит поздравлять друзей лично поэтому он решает отправить поздравление в виде голосового сообщения. Для этого он включает запись, диктует короткое поздравление с извинением, публикует его в чате и прячет телефон. Через пол часа приходит пуш-уведомление с сообщением от Саши “Спасибо!”.

Сценарий 3. День. Андрей находится в университете. Прозвенел звонок и наступила большая перемена. Вечером Андрей планировал пойти на свидание с новой девушкой поэтому ему нужно договориться о времени и месте. Он достаёт телефон, запускает IM и смотрит в списке контактов с кем бы можно было поболтать и назначить свидание. Девушка по имени Алёна находится в онлайне поэтому он сначала заходит в её профиль чтобы посмотреть на её фото и узнать сколько ей лет. Алёна оказалась не в его вкусе и несколько старовата поэтому Андрей выходит из профиля Алёны и видит что Марина также в онлайне. Андрей заходит в её профиль и видит по фото, что Марина достаточно привлекательна а также судя по фотографиям в её ленте весьма интересная личность. Он начинает с ней чат и пишет приветствие, попутно вспоминая при каких обстоятельствах с ней познакомился. Марина отвечает через несколько секунд. Андрей без долгой переписки предлагает встретиться вечером в кафе добавив в сообщение несколько смайликов и расположение кафе на карте, чтобы Марина смогла посмотреть по карте где находится кафе. Немного поломавшись Марина соглашается и прощается. Андрей радостный прячет телефон и бежит на пары.

4. Функционал и информационное наполнение

После написания сценариев можно перейти к более детальному описанию функционального и информационного наполнения. Для этого лучше всего подходят программа XMind и Метод скоростной фиксации сценариев . Мы выписываем все действия, которые будет производить пользователь, превращая их в микросценарии и объеденяя в сценарии. В итоге получается большая карта со всеми возможными сценариями.

Благодаря такой карте мы можем создать структуру будущего приложения с разбивкой функционала и напонения по экранам, и, самое главное, оценить объем работ.

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

5. Концептуальные прототипы

Ну и после того как дизайнер понимает как будет работать приложение, и что будет на каждом экране, можно приступать к прототипированию. Для этой задачи я рекомендую использовать векторный редактор, например Adobe Illustrator или Sketch.

Ниже представлены результат первого захода, так сказать концептуальные прототипы.

И был у нее удивительный частный Интернет за заборчиком, где вместо 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 (чатбот и поисковый интерфейс).

Прочее

Возможность, но не требование привязки счета к телефону или емейлу или ещё чему угодно.
ID пользователей, которые трудно угадать, и, соответственно, трудно разослать спам.
Tags, позволяющие реализовывать поиск людей как в WeChat (и, подобно WeChat, встроить в мессенджер службу знакомств) или разделить организацию на отделы как в Slack.
Возможность подключения пользователей без регистрации, необходимая, например, для организации службы поддержки через чат.
Интерфейс и пример подключения чатботов.
Планы создания каналов как в Telegram.

Почему Go?

Сервер для мессенджера по сути роутер: получает сообщение из одного канала, как-то его обрабатывает, затем передает в другой канал или каналы. Go (как и Erlang, но это уже другая история) идеально подходит для создания такого функционала т.к. содержит примитивы goroutine и chan, делающие организацию потоков и обмен данными между ними эффективным и простым.

Безусловно, роутер можно написать и на C/C++, и на Java. Однако, при прочих равных, код скорее всего получится более сложным и потребует больших усилий для избежания дедлоков.

А что потом?

Федерация

Одна из основных задач для Tinode на ближайший год - создание платформы для федерации. Так, чтобы любой желающий мог запустить свой Tinode сервер, который бы мог обмениваться сообщениями с любым другим сервером, точно так, как это возможно с емейлом. Уже сейчас возможна кластеризация серверов. Сетевой обмен между сервером и клиентами идет по TLS websocket, что для внешного наблюдателя мало отличимо от простого HTTPS трафика.

Публичный DNS, вероятно, будет использоваться, по крайней мере первоначально. Однако, в будущем поиск чат-серверов будет осуществляться также, как это сделано в Bittorrent - при помощи DHT , распределенной хеш таблицы.

Хочется также избежать и проблем, за которые часто критикуют XMPP. Например, XMPP сервера очень разговорчивы. До половины сообщений является дублирующими, когда XMPP-клиент рассылает онлайн уведомления индивидуально каждому контакту из адресной книги.

Репутация и распределенное принятие решений

Системы обмена сообщениями больше всего похожи на емейл. Как известно, значительная часть электронной почты - спам. Не хочется повторять чужие ошибки, поэтому механизмы, ограничивающие спам, должны быть сразу встроены в систему. Полностью задача пока не решена, но есть общее направление:

Криптографическая идентификация сервера-отправителя.
Изначально, SMTP вообще не предполагал какой-либо идентификации отправителя. Не стоит снова наступать на эти грабли. Каждый сервер, желающий установить контакт, будет представлен криптографическим сертификатом. "Ну да", скажете вы, "я сейчас нагенерю 100500 сертификатов и каждый раз буду представляться новым чистым сервером". И будете правы. Поэтому следующий пункт.
Распределенный учет репутации.
Когда к нам стучится новый, неизвестный сервер-отправитель, мы сделаем запрос к известным серверам с просьбой сообщить рейтинг нового сервера. И в зависимости от ответа установим, например, скорость, с которой новый сервер может посылать нам сообщения.

Если посмотреть на распределенную систему принятия решения и учета репутации с высоты птичьего полета, то станет заметно сходство с blockchain. Возможно, blockchain (но не криптовалюта) может быть использован в качестве основы для построения распределенной системы репутации, хотя пока и не очевидно каким образом.

Шифрование

Ну а как же в наши дни без шифрования сообщений? Чаты между двумя людьми, вероятно, будут шифроваться OTR . С групповыми чатами пока непонятно. Все известные схемы шифрования групповых чатов либо имеют значительный недостатки, либо тяжеловесны и сложны в реализации. Также, не очевидно, насколько важно шифрование групповых чатов: "Если тайну знают двое – это уже не тайна, а если трое – это уже базар."

Что вы по этому поводу думаете?

Вы можете помочь и перевести немного средств на развитие сайта

Комментарии (205):

- - - - Ваша наивность зашкаливает.
        
        Можно сделать текст жирным, курсивом
        
        Вы сами-то пробвали это сделать хотя бы раз?
        
        Вам нужно сменить хмпп-сервер
        Я использую jabberon.ru, у которого есть HTTP File Upload согласно его диско (upload.jabberon.ru). На conference.jabber.ru всё работает, как вы заявляете.
        
        Но кнопки отправки файла в чат на conference.jabber.ru у меня нет!