Neitr, у нас был Slack, пока в нём сидела разработка, эксплуатация и саппорт, было ещё более-менее по цене, когда решили внедрить во всю компанию поняли что ценник негуманный, и тогда выбрали Rocket.Chat за то что он достаточно близок к слаку по идеологии. Но он оказался довольно глючным и тормозным, поэтому в прошлом году изучали альтернативы, в шортлист вошли Mattermost и Matrix, в итоге победил Matrix и мы провели тест его использования, по итогу руководство того отдела, что вело этот проект, решило остаться на Rocket.Chat и просто его немного доработать (своя сборка мобильного приложения, свой модуль интеграции с LDAP).
По поводу Rocket.Chat есть такие проблемы:
1. В мобильном клиенте есть недостаточно поддерживаемые фичи, из-за чего сообщения с кусками кода временами рендерятся криво.
2. Мобильный клюент в бесплатной версии глючит с пушами, часто пуши опаздывают, иногда приходят прям пачками и даже дублируются. Можно заплатить разрабам за поддержку, и пуши будут идти через другой сервер и работать быстрее, но всё равно не очень надёжно. Мы в итоге сделали свою сборку клиента со своими пушами, но её приходится ставить не из сторов, на андроиде ещё ничего, на яблоках это какой-то странный квест...
3. Декстопная версия очень любит жрать память и вообще не очень отзывчива по скорости работы. Вообще, кто-то у нас заметил, что там в интерфейсе дофига избыточных div и span...
4. Это приложение на Electron, причём один из худших вариантов, которые я встречал. Да, я знаю, что приложения на Electron это фактически браузер, но всё же. Вон, клиент Matrix Element тоже Electron, но он реально клёво написан, память не жрёт, работает быстро и красиво.
В общем-то мы привыкли, да и глючить оно стало в современных версиях чуть меньше, чем раньше, хоть и жаль, что прогресс такой медленный.
Также смотрели Mattermost. Его декстопный клиент вроде выглядел поприличнее Rocket.Chat, но он кажется чуть меньше похож на Slack. Про мобильный клиент не помню впечатления.
Ещё смотрели Zulip, это довольно забавная штука, там можно текстовые топики создавать прям в канале и фильтровать по ним, этакая замена тредов, но это явно будет пользователям тяжело воспринимать.
Что касается аудиовидео, большинство открытых проектов такого рода просто используют Jitsi Meet, позволяя прям из клиента создать в нём встречу и показывая в webview её. Можно поставить свой сервер Jitsi Meet и использовать. У нас всё равно свой сервер есть, мы его и внутри используем, и для встреч с внешними пользователями (включая онлайн-собеседования). Правда, часть сотрудников всё равно используют обычный Zoom с личными аккаунтами :)
lolrofl01, никак, докер даёт приложению очень мало времени на завершение, потом убивает принудительно, с высокой вероятностью никакие потуги не позволят гарантированно записать базу в файл.
Вообще, советую пересмотреть свою задачу: зачем ей вообще нужны такие манипуляции? Может, нужно базу в докер не засовывать, а запустить на хосте?
Neitr, да, может. И даже его функции федерации можно зарезать, чтобы нельзя было связываться с другими Matrix-серверами.
Но есть некоторые неудобства в том, что пользователей придётся обучить его функциям криптографии (бэкап ключа, авторизация других устройств итд). Это стало основным препятствием, почему у нас в конторе решили его не внедрять.
Не надо копипастить простыню кода безо всяких пояснений. Может, автор вопроса скопипастит и у него заработает (но не факт), а вот понимания не прибавится и лучше программировать он не научится.
Вадим, интернет там был ни при чём. Браузер тормозит - скрипт считает, что видео отдаётся медленно - понижает качество.
Ну а общее соображение в том, что "интернет хороший" - это масло маслянное. Как будет роутиться трафик и какая будет загруженность конечного сервера угадать никогда нельзя. Тем более что, как я говорил, у них может быть такой же автодетект, как у ютуба и других хостингов, который снизит качество при любых лагах сети.
EDIsaev, раньше были деятели которые сканили номера телефонов перебором, потом Телеграм это прикрыл. В общем-то если на сайте бронируют одну из четырёх комнат в доме, то вряд ли это страшно, а если это что-то более сурьёзное, то я бы уже поостерёгся.
Этот функционал НЕ ПРЕДНАЗНАЧАЛСЯ для отправки сообщений автоматизированно неограниченному кругу пользователей, он нужен только для работы полноценных Телеграм-клиентов.
habrdima, в реальности объект requests.Session - это не коннект. Это что-то типа "шаблона запроса", который может иметь параметры по умолчанию, запоминать полученные от сервера куки итд итп. Можно с одной сессией запросить сначала яндекс, потом гугл, и это не будет значить, что будет один коннект.
Более того, изначально дизайн протокола HTTP предполагал, что по одному коннекту может пройти только один запрос. Потом появился HTTP/1.1 с keepalive, где можно держать коннект и гонять по нему несколько запросов. Но ни один сервер в здравом уме не будет держать часами коннект, по которому нет никакой активности. Поэтому в реальности коннект не будет удерживаться вечно, он всё равно закроется и достаточно быстро.
Тем более что нормальный способ использования requests.Session - не создавать сессию с нуля в тысячах функций, а создать один раз и использовать повсеместно.
Neisvestniy, dislash, discord_components и прочие костыли с discord.py 2.0 с самого начала очень плохо дружили. У меня самый тривиальный скрипт валился где-то в недрах с невнятными ошибками.
Алексей, похоже что да, понял неправильно. Я думал, ты свою систему регистрации пишишь и хочешь чтобы пользователи подтверждались из письма без перехода на сайт. Но ты похоже хочешь автоматизировать регистрацию на стороннем сайте.
Весьма вероятно, что там подтверждение требует полноценного браузера с js, то есть придётся или разбираться, как оно происходит в деталях, или использовать selenium (или аналоги).
Vindicar, в отличие от дискорда, у телеграма открытый клиентский API, и эти библиотеки его реализуют. Но, конечно, некоторые действия могут привести к бану. Например, частый поиск по номеру телефона или откровенный спам.
