Я опубликовал код на GitHub, но, на мой взгляд, на данный момент качество находится на альфа-уровне. Многие функции работают, однако плагину не хватает документации, а также требуются дополнительные исправления (например, это), чтобы Discourse мог его корректно использовать.
На данный момент реализовано:
Обнаружение домашнего сервера — работает
Каналы — работает
Групповые чаты — работает
Личные чаты — работает
Редактирование — работает
Удаление — работает
Загрузка файлов — запланировано на следующий этап
Уведомления о присутствии/печати и подтверждения прочтения — запланировано на следующий этап (если возможно)
Реакции — работает
Ответы на сообщения — работает
Текстовые сообщения (обычные и форматированные, эмодзи) — работает
Когда плагин достигнет бета-качества, будет создана более официальная тема для его анонса. Спасибо за ваш интерес к этому плагину!
Может, вопрос глупый, но обеспечит ли эта интеграция сквозное шифрование (E2EE) в Discourse (End-to-end Encryption for Chat)? Или же это будет просто копирование данных из Discourse и их отправка в Matrix, так что администратор Discourse всё ещё будет иметь доступ ко всем сообщениям в чатах в открытом виде?
Это невероятно захватывающе. Я заметил, что связанный pull request завершён, но, без сомнения, это масштабный проект. Мне интересно, как продвигается поддержка чата Matrix, и я очень рад этому.
На мой взгляд, Discourse в первую очередь предназначен для публичных форумов. Сквозное шифрование в данном случае скорее контрпродуктивно. Если вы не доверяете администратору экземпляра Discourse, то я не вижу смысла в его использовании вообще. Сквозное шифрование не помешает администратору внедрить вредоносный функционал в браузер для обхода шифрования. Если к конфиденциальности односторонней или многосторонней связи предъявляются высокие требования, лучшим выбором, на мой взгляд, будет выделенный канал Matrix.
Согласен. Мне кажется, что подавляющее большинство пользователей интернета не до конца понимают, что приватный чат на платформе часто доступен для просмотра администратору. В моём случае, как администратор, я, вероятно, просто отключил бы приватные чаты в Discourse, потому что не уверен, что люди поймут: я могу читать все их личные сообщения, несмотря на то, как много раз я им об этом говорю. Возможно, стоит перенаправить пользователей: если они хотят связаться с кем-то напрямую, пусть делают это через Matrix или Signal (я всё ещё жду имена пользователей, чтобы не приходилось раскрывать свой номер телефона всем подряд).
Я понимаю вашу точку зрения: с открытым исходным кодом Discourse администратор всё равно может нарушить сквозное шифрование (E2EE), поэтому, возможно, доверять ему нельзя в любом случае.
Очень круто, но я вижу, что здесь нет реальных инструкций по установке.
Более подробная информация об этом плагине и о том, как его установить, доступна на [Meta](https://meta.discourse.org/t/TODO).
Вы ошибаетесь. Это мост к Matrix, что означает отсутствие какого-либо шифрования E2E. Оно просто делает чат форума доступным для пользователей Matrix.
Это не имеет ничего общего с секретностью. Это просто для общения с людьми, которые находятся в Matrix.
Здесь нет E2E. E2E означает, что шифрование происходит на стороне клиента, до того как данные достигнут сервера. Давайте, пожалуйста, перестанем смешивать поддержку Matrix с E2E.
Для тех, кто хочет использовать E2E в Discourse и обсуждать это в другом месте… вы можете воспользоваться Discourse Encrypt (deprecated)
Мы могли бы довольно просто решить эту проблему, включив всех администраторов в список участников каждого чата (и, конечно, динамически управлять этим при выходе или входе администраторов), но это было бы отдельным запросом на новую функцию, разумеется.
Не знаю, изобретаю ли я велосипед, но я пишу мост между Discourse Chat и другими платформами. С Telegram у меня был довольно хороший успех, и мост работает очень хорошо. Далее я рассматриваю возможность создания моста между Discourse Chat и Matrix.
Отчасти. Эта ветка началась с идеи замены протокола чата Discourse на протокол Matrix. Это звучит очень разумно, так как он кажется хорошо спроектированным и набирает популярность. Я даже не понимаю, зачем мы здесь говорим о мостах. Вопрос в том, почему протокол Discourse следует или не следует устаревать в будущем.
Сквозное шифрование (E2EE) для личных чатов/сообщений (по моему мнению, это одно и то же) стало бы возможным по умолчанию при внедрении протокола Matrix. Нет необходимости в собственном протоколе.
Может ли кто-нибудь из основной команды Discourse поделиться информацией о текущем состоянии обсуждений по вопросу «взаимодействия чата Discourse с чатами на базе Matrix»? В Европе у нас есть несколько крупных игроков, которые уже используют Matrix в качестве технической основы для своих собственных мессенджеров:
Принятие Matrix растёт по всему миру. Я считаю, что возможность «связывания» чата Discourse с экосистемой Matrix может стать ключевым аргументом в пользу использования платформы Discourse в ближайшем будущем (примерно так же, как ActivityPub для связывания Discourse с Mastodon). Существует некоторый код моста по адресу:
но последняя активность была 2 года назад. Есть ли какие-либо планы по интеграции этого кода или созданию чего-то нового, что будет «официально поддерживаться»?
Несмотря на то, что ActivityPub отлично подходит для связывания открытых обсуждений, внедрение протокола Matrix также могло бы стать безопасным способом связывания непубличных категорий между разными серверами Discourse, а также дополнительным каналом для отправки уведомлений пользователям.
Мы работали с Дэном в ходе тех ранних исследований, которые вы видите в этом репозитории, чтобы лучше понять целесообразность обеспечения совместимости чата с Matrix.
На тот момент это выглядело многообещающе, хотя мы столкнулись с рядом проблем, которые так и не успели полностью решить — главной из них был подход к обработке пользователей в каждой из систем.
С тех пор чат значительно развился, и мы не рассматривали совместимость с Matrix как ограничение при проектировании, поэтому возможно, что между двумя системами возникли дополнительные расхождения, которые потребуют устранения.
Скорее всего, для продолжения этой работы потребуется спонсор, который обеспечит дальнейшее развитие и создаст более сильные стимулы для поддержки созданного решения.