Исходный код мессенджера для android

«Хочу как Дуров»: пишем простой мессенджер

Авторизуйтесь

«Хочу как Дуров»: пишем простой мессенджер

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

Статья подойдёт состоявшимся программистам и тем, кто только интересуется, как войти в IT.

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

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

Подготовка

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

Установите Node.js и MongoDB. Кроме того, нам понадобится библиотека AngularJS, скачайте её и скопируйте в папку lib каталога Client.

Чтобы сделать пользовательский интерфейс приложения привлекательнее, вы можете воспользоваться любой CSS-библиотекой. Скачайте её и скопируйте в lib .

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

Серверная часть

Шаг 1. Запуск проекта

Перейдите в каталог Server и выполните команду:

Она запустит новый проект.

ABBYY , Москва, можно удалённо , От 250 000 ₽

Укажите все необходимые сведения. В результате будет создан файл package.json примерно следующего вида:

Шаг 2. Установка зависимостей

• socket.io — JavaScript-библиотека, которая предоставляет двустороннюю связь клиента и сервера в режиме реального времени;
• express — фреймворк Node.js, предоставляющий набор функций для разработки мобильных и веб-приложений. Позволяет отвечать на HTTP-запросы, используя промежуточное ПО, а также отображать HTML-страницы.

Выполнение этих команд установит необходимые зависимости и добавит их в package.json :

Выглядеть они будут примерно так:

Шаг 3. Создание сервера

Создадим сервер, который обслуживает порт 3000 и возвращает HTML-файл при вызове. Для инициализации нового соединения сокету нужно передать HTTP-объект. Событие connection будет прослушивать входящие сокеты, каждый сокет будет выпускать событие disconnect, которое будет вызвано при отключении клиента. Мы будем использовать следующие функции:

• socket.on(. ) — ожидает событие, и когда оно происходит, то выполняет функцию обратного вызова.
• io.emit(. ) — используется для отправки сообщения всем подключенным сокетам.

Создайте сервер с именем server.js . Он должен:

• Выводить сообщение в консоль при подключении пользователя.
• Слушать событие chat message и транслировать полученное сообщение на все подключенные сокеты.
• Когда пользователь отключается, выводить сообщение в консоль.

В результате ваш сервер будет выглядеть примерно так:

Клиентская часть

Создайте файлы 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-приложение и инициализируйте соединение сокета. Для этого нужны следующие функции:

• socket.on(. ) — слушает определенное событие, и, когда оно происходит, выполняет функцию обратного вызова.
• socket.emit(. ) — используется для отправки сообщения конкретному событию.

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

В результате app.js будет выглядеть примерно так:

Запуск приложения

Перейдите в папку с server.js и запустите команду:

Сервер начнет работу на порте 3000. Чтобы в этом убедиться, перейдите по ссылке в браузере:

Ваш собственный мессенджер готов!

Что можно улучшить?

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

Установите Mongoose или MongoDB для работы с базами данных Mongo:

Можете ознакомиться с документацией по их использованию: mongoose и mongodb.

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

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

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

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

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

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

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

Вот какой мессенджер получился у автора статьи:

Внешний вид приложения

Исходный код приложения можно найти на GitHub.

Источник

Создан сверхзащищённый мессенджер без названия. Исходный код уже на GitHub

Авторы проекта TFC объявили о размещении исходного кода сверхзащищённого мессенджера на GitHub. Это не просто приложение, а программно-аппаратный комплекс: он предполагает использование трех отдельных ПК участниками переписки. Плюс, у каждого участника должен быть специальный аппаратный сплиттер, подключенный к ПК. Все сообщения в новом мессенджере передаются через сеть Tor и шифруются надежными алгоритмами, а аппаратный сплиттер не позволяет добраться до конечных пользовательских устройств и взломать их. В Сети уже окрестили проект «мессенджером для параноиков».

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

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

Конструкция сплиттера позволяет предотвратить перехват сообщений при компрометации любого из трех задействованных в сети компьютеров на стороне каждого участника беседы. Все схемы, а также перечень необходимых для сборки компонентов распространяются бесплатно по лицензии GNU FDL 1.3.

Вся функция шифрования передаваемой информации в проекте TFC основана на 256-разрядных ключах, для обмена которыми используется криптографический протокол Диффи-Хеллмана. Для защиты ключей паролем используется медленная хэш-функция Argon2id.

Названия у проекта пока нет; исходный код мессенджера написан на языке Python.

UPD drom vdem:
Для работы мессенджера на ПК должна быть установлена любая из ОС данного списка.

Источник

Простой клиент-сервер на Android (интернет-мессенджер)

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

Поехали. Многие мобильные приложения (и не только) используют архитектуру клиент-сервер. Общая схема, думаю, понятна.

Уделим внимание каждому элементу и отметим:

• сервер — представляет собой некую программу, работающую на удаленном компьютере, и реализующую функционал «общения» с приложениями-клиентами (слушает запросы, распознает переданные параметры и значения, корректно отвечает на них);
• клиент — в нашем случае, программа на мобильном устройстве, которая умеет формировать понятный серверу запрос и читать полученный ответ;
• интерфейс взаимодействия — некий формат и способ передачи/получения запросов/ответов обеими сторонами.

Неважно, как реализован любой из этих элементов, все они в любом случае присутствуют. Давайте реализуем примитивный сервер и Android клиент, работающий с ним. Как пример, будем использовать любой популярный мобильный интернет-мессенджер (Viber, ICQ), а приложение условно назовем «интернет-чат».

Схема взаимодействия следующая:

Клиент, установленный на устройстве А, посылает сообщение для клиента, установленного на устройстве Б. И наоборот. Сервер играет роль связующего звена между устройством А и Б… С, Д… и т.д. Также он играет роль «накопителя» сообщений, для их восстановления, на случай удаления на одном из клиентских устройств.

Для хранения сообщений используем SQL БД как на сервере, так и на устройствах-клиентах (в принципе, вся работа клиентов интернет-мессенджеров и сводится к постоянной синхронизации локальной и удаленной БД с сообщениями). Дополнительно, наш интернет-чат будет уметь стартовать вместе с запуском устройства и работать в фоне. Взаимодействие будет происходить путем HTTP запросов и JSON ответов.

Более логично, если синхронизация происходит через порт/сокет, это с одной стороны упрощает задачу (не нужно циклично слать HTTP запросы на проверку новых сообщений, достаточно проверять состояние прослушиваемого сокета), но с другой стороны, это усложняет создание серверной части приложения.

Делаем сервер

Для реализации «сервера», нам нужно зарегистрироваться на любом хостинге, который дает возможность работы с SQL и PHP.

Создаем пустую SQL БД, в ней создаем таблицу.

1. author — автор сообщения;
2. client — получатель сообщения;
3. data — время и дата получения сообщения на сервере;
4. text — сообщение.

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

Структура запросов к api:

• обязательный атрибут action — может быть равен select (сервер ответит списком записей из своей БД), insert (сервер добавить новую запись в свою БД), delete (сервер очистит свою БД)
• если action=insert, нам нужно будет передать дополнительные параметры: author (кто написал сообщение), client (кому адресовано сообщение), text (сообщение)
• action=select может содержать дополнительный параметр data, в этом случае ответ сервера содержит не все сообщения из БД, а только те, у которых время создания позднее переданного

Примеры:

• chat.php?action=delete – удалит все записи на сервере
• chat.php?action=insert&author=Jon&client=Smith&text=Hello — добавит на сервере новую запись: автор Jon, получатель Smith, содержание Hello
• chat.php?action=select&data=151351333 — вернет все записи, полученные после переданного времени в long формате

Клиентская часть

Теперь структура Android приложения:

В фоне работает FoneService.java, который, в отдельном потоке, каждые 15 секунд делает запрос на сервер. Если ответ сервера содержит новые сообщения, FoneService.java записывает их в локальную БД и отправляет сообщение ChatActivity.java о необходимости обновить ListView, с сообщениями. ChatActivity.java (если она в этот момент открыта) получает сообщение и обновляет содержимое ListView из локальной БД.

Отправка нового сообщения из ChatActivity.java происходит сразу на сервер, минуя FoneService.java. При этом наше сообщение НЕ записывается в локальную БД! Там оно появится только после получения его назад в виде ответа сервера. Такую реализацию я использовал в связи с важным нюансом работы любого интернет-чата — обязательной группировкой сообщений по времени. Если не использовать группировку по времени, будет нарушена последовательность сообщений. Учитывая, что клиентские приложения просто физически не могут быть синхронизированы с точностью до миллисекунд, а возможно будут работать даже в разных часовых поясах, логичнее всего будет использовать время сервера. Так мы и делаем.

Создавая новое сообщение, мы передаем запросом на сервер: имя автора сообщения, имя получателя сообщения, текст сообщения. Получая эту запись назад, в виде ответа сервера, мы получаем то, что отправляли + четвертый параметр: время получения сообщения сервером.

Источник

Опубликованы исходники швейцарского криптомессенджера Threema

Архитектура веб-клиента Threema, источник

Защищённый мессенджер Threema открыл исходный код и инструкции по воспроизводимой сборке приложений. Опубликованы 12 репозиториев для клиентов Android, iOS, веб-версии, рилеев нотификаций и других компонентов. Это важнейшее событие в истории компании Threema GmbH, которая с публикацией исходников выходит на новый уровень разработки.

На фоне массового исхода пользователей WhatsApp платный мессенджер Threema стал одним из самых скачиваемых приложений в мире, вместе с Telegram, Signal и Element (децентрализованная сеть Matrix), см. также статью «Какое шифрование лучше: Signal или Telegram?».

Threema наименее известна в этой плеяде. Зато у неё есть одно преимущество перед конкурентами — швейцарская юрисдикция.

Threema — сервис для обмена сообщениями, который реализует сквозное шифрование коммуникаций (E2EE). Поддерживаются аудио- и видеозвонки, обмен файлами и другие возможности современных мессенджеров.

Есть версии для Android, iOS и веба. Отдельного десктопного приложения, в том числе под Linux, пока не разработано.

Интересно, что исходники на Github обновляются только с обновлением клиентов, то есть один коммит = один релиз. Пул-реквесты и баги в репозиториях Github не принимаются, только по почте.

Юрисдикция — это важно

Threema развивается швейцарской компанией Threema GmbH. Серверы проекта тоже в Швейцарии. Именно швейцарская юрисдикция — главное преимущество Threema перед Signal (США) и Telegram (США, Великобритания, разработка переезжает по офисам в разных странах, сейчас находится в ОАЭ, основатели и программисты преимущественно из России, инвесторы из России и других стран, кроме США).

Юрисдикция управляющей компании — вовсе не второстепенный вопрос, когда у властей возникают претензии к отдельным пользователям, клиентам сервиса. Например, в США действуют законы, по которым компания обязана секретно внедрить бэкдоры в свои продукты и сервисы и реализовать слежку за пользователями, если секретный суд примет такое решение.

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

Многие помнят историю почтового сервиса Tutanota, которого немецкий суд заставил установить бэкдор для расшифровки почты определённого пользователя. Владельцы ганноверской компании тогда жалели, что не выбрали иную юрисдикцию. В одном из интервью они сказали, что рассматривают переезд в Швейцарию, хотя правовая ситуация в Германии не такая плачевная: «Правовая ситуация и конституция Германии в основном очень хорошие и защищают конфиденциальность людей. Общественная активность также помогает нам предотвратить или ослабить проблемные законы (слежку)».

В США правовая ситуация гораздо хуже, особенно после 9/11. В августе 2013 года был вынужден закрыться почтовый сервис Lavabit. Основатель и владелец сервиса Ладар Левисон (Ladar Levison) сказал, что принял это решение после долгих раздумий:

«Я бы хотел иметь легальную возможность рассказать вам о всех событиях, которые привели к такому моему решению, но я не могу. Я чувствую, что вы заслуживаете знать, что происходит. Первая поправка должна гарантировать мне свободу слова в ситуациях вроде этой. К сожалению, Конгресс принял законы, которые говорят обратное. На данном этапе я не могу поделиться событиями последних шести недель, хотя я дважды отправлял соответствующие запросы [чтобы мне разрешили это сделать]», — написал основатель Lavabit Ладар Левисон. Он не вдаётся в подробности своего дела, но обращается ко всем пользователям: «Минувшие события преподали мне один очень важный урок: до решения Конгресса или чёткого судебного прецедента я _очень_ не рекомендую кому-либо доверять персональные данные компании, которая физически привязана к США».

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

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

Threema GmbH — швейцарский стартап, который получил финансирование от немецко-швейцарской инвестиционной компании Afinum Management AG. Основатели компании — три программиста Мануэль Каспер (Manuel Kasper), Сильван Энгелер (Silvan Engeler) и Мартин Блаттер (Martin Blatter).

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

Разработчики обещают выпустить полноценный десктопный клиент, в том числе под Linux, которым можно будет пользоваться без смартфона: «Безопасность и защита приватности глубоко укоренились в ДНК Threema, поэтому наш код регулярно проходил внешний аудит (см. результаты аудита за ноябрь 2020 года). Благодаря открытым исходникам любой желающий может самостоятельно проверить безопасность Threema и убедиться, что опубликованный исходный код соответствует загруженному приложению. В будущем благодаря инновационному решению с несколькими устройствами можно будет использовать несколько устройств параллельно. В отличие от других подходов, на сервере не останется никаких следов персональных данных. Благодаря этой технологии Threema можно использовать на ПК без смартфона. В итоге, Threema станет ещё более надёжным и ещё более удобным приложением».

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

Источник