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

"Ну ладно, это же опенсорс! Значит можно попробовать что-то с этим сделать своими силами. Заодно и внести посильный вклад в развитие этого продукта. Что может быть лучше?" - сказали вы себе. Но реальность оказалась иной. Код для непрограммиста оказался довольно сложный, принятая разработчиками архитектура приложения также вызывает вопросы (конечно, скорее всего только у меня) и т.д. Частично отсюда и пресловутая "лень" в заголовке.

К чему это я? Начну с небольшой предыстории.

Истоки

На заре становления меня самого в качестве айтишника (более 15 лет назад) для рабочего общения сотрудников в бюджетных и не только организациях основным средством была (да собственно до сих пор и остается) электронная почта. Однако потребность общения в реальном времени также всегда присутствовала (не только телефон или при встрече). Мессенджеры - наше всё. Протоколов и приложений народилось за последние 20 лет великое множество. Примеры приводить не буду - все всё и так знают.

Скажу лишь, что первым протоколом и приложением ("человек и пароход"©) для рабочей быстрой переписки ("корпоративного чата", как его формально называют) в моей практике стал jabber (xmpp). Без каких-либо наворотов - просто приложение, устанавливаемое и настраиваемое вручную на компьютерах организации и умеющее на тот момент (год этак 2009, вроде бы) только текст и смайлики (и то разнообразия особого не было, как и анимации). Сервером был ejabberd под FreeBSD 6, если мне память не изменяет, но могу ошибаться - давно было.

Чуть позднее уже на другой работе нашлась другая реализция сервера - Openfire, а в качестве клиента ее "родной" Spark. Данная связка оставалась в моей рабочей практике незыблемой буквально до 2023 года. Почти всё необходимое она умеет: LDAP, архивирование, многочисленные интеграции, поддержка клиентом даже самых устаревших ОС в лице Win XP и Win 7, в конце концов в развертке и настройке это всё еще и очень не сложная история. Казалось бы на том можно и остановиться. Но однажды в организации появился облачный сервер на базе Nextcloud со своей экосистемой...

Самоделкин

Стала очень заманчивой идея максимально интегрировать функционал всего (или почти всего), что есть в организации, в эту самую экосистему и корпоративный чат не стал исключением. Темой этой статьи стал именно он - Nextcloud Talk (ранее известный как Spreed). О других интеграциях и костылях сделанных и успешно работающих я (может быть) расскажу в другой раз.

Сейчас же хочу сразу хочу уточнить, почему выбор пал именно на Talk. Собственно в организации уже был работоспособный упомянутый ранее Openfire с раскиданным групповыми политиками по рабочим местам пользователей клиентом Spark. Поначалу чисто для пробы в работающем Nextcloud'е был установлен и настроен JavaScript XMPP Chat - OJSXC. Но степень интеграции в Nextcloud оказалась довольно ограниченной. Кроме того донимали многочисленные недоработки.

Затем, в перерывах между работой над интеграцией Roundcube и тестированием RocketChat я решил посмотреть, а что собственно умеет Talk. Как оказалось, умеет он настолько достаточно, что теоретически может выступить неплохим заменителем не только корпоративного чата, но и уже работающей со во времен начала пандемии системы ВКС Bigbluebutton (при условии, что администратор осилит настройку быстрого backend сигнального сервера - у меня к слову уже есть готовый рецепт для быстрой развертки прямо в докер). Сразу стало интересно, а можно ли "вытащить" Nextcloud Talk из браузера и сделать так, чтобы он работал на рабочих местах сотрудников как приложение мессенджер, типа Spark. Поскольку по роду деятельности я всё-таки системный администратор, также заинтересовал вопрос минимального участия пользователей рабочих мест в его настройке, т.е. в идеале , чтобы распространить приложение на места, выдать какой-то единый конфиг для клиента и не запрашивать у пользователей домена логин и пароль (SSO).

Естественно первым делом я нашел официальный десктопный клиент для Talk, но разочаровался в нем сразу, т.к. на тот момент будучи альфа версией в нем отсутствовал самый на мой взгляд важный для корпоративного (да и не только корпоративного) мессенджера функционал. Забегая вперед могу сказать, что на данный момент (за почти 2 года с момента, как я его нашел) этого функционала так и не появилось. Например, элементарный и очень важный счетчик непрочитанных сообщений на иконке приложения (в трее и/или панели задач ОС) до сих пор стабильно откладывают "на потом", несмотря на многочисленные просьбы.

Конечно, я ознакомился с кратким руководством разработчика для приложения, решил сделать форк проекта и попробовать поразбираться. Тем более, что про Electron наслышан, но ничего еще раньше на нем не делал. Я быстро понял, что что-то не так, когда увидел, что с условного `npm start` до момента появления главного окна browserWindow проходит почти минута, а то и больше. Стало ясно, что помимо и без того тяжелых зависимостей, которые тянет с собой electron (по сути целый браузер Chrome), разработчики предлагают еще и весь исходный код Talk тянуть, который и так работает на стороне сервера, с которым должен работать клиент. И я решил попробовать подойти к разработке с другой стороны.

Небольшое отступление. Я понимаю, что есть определенные правила, рекомендации и best practices при разработке приложения на electron касательно безопасности при открытии в десктопном окружении кода с удаленного сервера, но держа в уме, что приложение делаю для работы внутри организации с кодом своего полностью подконтрольного сервера Nextcloud я решил, что для себя можно этими вещами пренебречь. Если кто-то со мной не согласен - можно в комментариях, если они будут, об этом мне не упоминать - я всё понимаю. Кто хочет воспользоваться - воспользуется. Страшный исходный код открыт.

Итак. Потыркавшись в официальное приложение и приняв во внимание, что по сути никакого базового функционала настольного мессенджера в нем нет, я решил попробовать сделать свой вариант сразу с теми минимальными вещами, с которыми это приложение можно было бы использовать в любой организации с сервером Nextcloud и доменом. А чтобы не тянуть весь исходный код, я решил сделать приложение wrapper, которое взаимодействует с удаленной страницей Nextcloud и, при необходимости, загружает локальный js код из клиента и выполняет его в browserWindow с загруженной с удаленного сервера Nextcloud страницей Talk. Еще раз подчеркну: убедитесь, что не используете его с неизвестным вам потенциально небезопасным сервером Nextcloud.

Перечислю функции настольного приложения, которые я поставил себе в качестве целей при разработке NC Talk Electron и уже пришел к ним в текущей версии (0.4.1-alpha на момент написания статьи):

• возможность автоматически загружаться при входе пользователя в ОС

• возможность запускаться в свернутом виде с иконкой в трее

• возможность использовать логотип удаленного сервера Nextcloud в качестве иконки

• хранить настройки в базовом понятном текстовом формате json

• хранить логин и пароль в системном trusted store (за это отвечает модуль npm keytar)

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

• отображать счетчик непрочитанных сообщений на иконках в трее (на всех поддерживаемых платформах) и панели задач (кроме Linux - там множество DE и под все подстроиться сложновато)

• возможность автоматически использовать настроенный в Nextcloud openid SSO - клиент запускается и входит без ввода пароля пользователя (ставьте "+" в карму, чтобы смотивировать меня на написание гайда по настройке)

В ближайших планах, если будет время и силы, сделать возможность работать сразу с несколькими серверами Nextcloud (multi account) и переработать всплывающие уведомления (сейчас используется штатная система Nextcloud с некоторыми проблемами).

Подробнее о системных требованиях, параметрах конфигурации и информация для разработчиков - в README на github.

Кстати, насчет системных требований - есть одна существенная для кого-то ложка дегтя: приложение несовместимо с версиями Windows старше Windows 7 - ограничения Electron версии 22.3.27. Собственно ради "семерки" тоже пришлось поколдовать с зависимостями, но пока она поддерживается. Это главный минус по сравнению со Spark.

Эпилог

Напоследок снова хочу отметить, что приложение делается в первую очередь для себя, а этот опус решил написать для того, чтобы немного добавить (или поубавить) мотивации к его развитию - благо развивать там можно еще много чего, всё-таки альфа-версия. Бесплатными тестерами по сути являются сотрудники на трех разных рабочих площадках в разных организациях с более, чем 300 сотрудниками суммарно. Это не считая тех, кто вполне возможно воспользовался приложением самостоятельно. Но жалоб не так, чтобы много. Основная их масса пришлась на самое начало разработки. Если кто-то из читателей хабра найдет приложение полезным - буду рад поставленной звездочке. =) На лавры тру/мидл/сеньор программиста (нужное подчеркнуть) я не претендую - исходный код говорит сам за себя.

Спасибо всем за внимание!