Разработка концепции и прототипа мобильного мессенджера. Как создать свой собственный корпоративный мессенджер? Создание мессенджера для телефона

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

Стоит ли создавать еще одно приложение 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.

Одна из важных составляющих как IT-инфраструктуры компании, так и информационной безопасности – организация общения между сотрудниками, а также офисами и филиалами компании. Уже общепринято, что компания имеет свои почтовые сервера и корпоративный e-mail адрес, переписка ведется и хранится на собственных (купленных или арендованных) серверах, оставаясь таким образом, внутри защищенного контура.

В то же время многие компании по-прежнему не задумываются о том, что сотрудники пользуются публичными мессенджерами типа Skype или IСQ, пересылая по ним и цифры, представляющие коммерческую тайну, и документы, и логины-пароли.

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

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

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

Начать использовать корпоративный мессенджер компании могут двумя способами. Во-первых, можно купить эту услугу как готовый пакет. Подобные предложения встречаются, например, у облачных провайдеров. В этом случае провайдер создает для компании-клиента сервер с установленной на нем платформой корпоративного мессенджера, физический, либо виртуальный. Сотрудникам компании-клиента выдаются логины и пароли. На компьютерах и ноутбуках сотрудников устанавливаются специальные программы. Самые распространенные из них: QIP, Pidgin, Spark, но каждый пользователь может выбрать на свой вкус. Причем у каждого из сотрудников может быть выбрана собственная, удобная именно этому пользователю, программа. По желанию можно установить программу и на мобильные устройства.

Во-вторых, компания может поднять собственный сервер с платформой для мессенджера, а затем точно также подключить к этому серверу своих сотрудников. Отдельно стоит отменить, что передача данных в обоих случаях осуществляется по ssl – то есть по зашифрованным каналам связи. И это существенно повышает информационную безопасность компании.

Для разработки хорошего продукта нужно придерживаться четкой методики проектирования основанной на таких методологиях как 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.

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

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

Используемые технологии и инструменты

Стек MEAN (Mongo, Express, Angular, Node).
Сокеты для прямого обмена сообщениями.
AJAX для регистрации и входа.

Подготовка

Структура будущего приложения выглядит примерно так:

Схема должна получиться примерно следующего вида:

{ "_id" : ObjectId("5809171b71e640556be904ef"), "name" : "Monkey proger", "handle" : "mkproger", "password" : "proger228", "phone" : "8888888888", "email" : "[email protected]", "friends" : [ { "name" : "habrick", "status" : "Friend" }, { "name" : "javaman", "status" : "Friend" } ], "__v" : 0 }

Собеседникам могут быть присвоены следующие статусы:

Friend - собеседник является другом.
Pending - собеседник пока не принял запрос.
Blocked - собеседник заблокирован.

Предположим, что собеседник отклонил запрос на приватную беседу. В таком случае отправитель должен иметь возможность снова направить запрос.

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

Также вы можете создать REST API для обслуживания клиента. Например, конечную точку, отправляющую домашнюю страницу, из которой пользователи могут выполнять другие запросы.

Некоторые из возможных конечных точек API:

App.post("/register", function(req,res){}) app.post("/login", function(req,res){}) app.post("/friend_request", function(req,res){}) app.post("/friend_request/confirmed", function(req,res){})

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