Идеальный веб-клиент для XMPP

Отслеживать
Пожалуйста, обратите внимание, что пользователь заблокирован
На Go консольный
 
Главное отсутствие зависимостей, питухон и джава на пример не наши бро.
Важны кроссплатформенность, функционал, дружелюность интерфейса к пользователям.
 
Последнее редактирование:
admin сказал(а):
Как вы считаете, на чем должен быть написан идеальный веб-клиент для XMPP?
если именно веб, то кроме Javascript особо выбора-то и нет. WebAssembly у всех нормальных людей выключен, поэтому си, го и прочее что тут насоветовали не подходит.
 
Dread Pirate Roberts сказал(а):
если именно веб, то кроме Javascript особо выбора-то и нет. WebAssembly у всех нормальных людей выключен, поэтому си, го и прочее что тут насоветовали не подходит.
Да, именно веб. Десктоп и мобильных клиентов достаточно. Выбор есть, в отличии от одного-единственного Telegram Desktop =) А вот нормальных веб клиентов нет.
 
Ruby, Perl
 
Была мысля написать простой в использовании клиент с нуля на расте. Есть прекрасный фреймворк eframe (egui) - натив кроссплатформ GUI (так же есть поддержка wasm), готовые крейты с реализацией протокола XMPP тоже есть. Но кто его будет использовать? Старички со своих любимых клиентов, которые используют годами, вряд ли захотят переходить на что-то другое, новички так и остануться в телеге. Пустая трата времени.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Бэк однозначно на Go. Фронт на чем угодно.
 
На мой взгляд, можно реализовать разными подходами.

1. Все на клиенте (как converse.js)
Клиент (SPA) -> JabberServer
Плюсы:
- Безопасность. Никто кроме вашего браузера не хранит данные для подключения.
- Простая поддержка. Требуется только js программист и лампочка
Минусы:
- Тяжелый финальный бандл. (не могу сказать точных цифр, но примерно 2-3Мб добавит). Это долгая первая загрузка на стороне клиента. Но потом все будет работать быстро.
Я нашел 2 бибилиотеки которые на это потенциально способны
- https://github.com/legastero/stanza
- https://github.com/xmppjs/xmpp.js

2. Отдельный промежуточный бэкенд
Клиент (SPA) -> Бэк -> JabberServer
Плюсы
- Легкий финальный бандл и простая разработка. Стандартное приложение. Храним сессию, перекидываемся json. Быстрая загрука у клиента, долгие операции выполняются бэкендом.
- Возможность добавить кэширование для снижения нагрузки на основной jabber сервер.
- Возможность расширить стандартный функционал. Я говорю о добавлении фич по типу редиректа сообщений на другой jabber (все сообщения с jid1 и jid2, отсылаются сразу на jid3), отправка уведомлений о непрочитанных сообщениях на почту или отправка в уведомления/PM основного форума, ... . Не знаю на сколько это востребованно, но иметь такую возможность приятно.
- Возможность расширить спам фильтры. Если пользователь отправляет 15 сообщений новым пользователям за 1 минуту, получает бан. Но это не сработает если спамер подключен напрямую к JabberServer
- Автоматическое добавление всех в roaster или отклонение всех входящих запросов.
- Если разрешить регистрацию только через эту систему. Появится возможность добавить кастомную капчу или использовать hCaptcha, что возможно снизит количество спама и ботов.
- Возможность вынести промежуточный бэк в тор. Атаки в торе проводить немного сложнее, поэтому уменьшит количество скана и перебора
- Возможность добавить внешнее API, что упростит дальнейшее разивитие. Может появлятся jabber боты
Минусы:
- Потенциально бэкенд может перехватить ваши данные. Но если мы говорим о форумном клиенте, то так же можно изменить JabberServer для перехвата)
- Дольше разработка, больше кода.
- Придется дополнительно поддерживать бэк.

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

И вопрос к админу, а зачем пишете свое? Что именно не устраивает в текущей реализации? Зная проблемы, можно придумать более подходящие решения.
 
Последнее редактирование:
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх