Да, но это был бы обширный и дорогой плагин.
1 лайк
Можно ли с помощью SSO или LDAP разрешить вход туда и обратно, не перемещая всех пользователей в один домен для входа?
Например, у меня есть форумы A, B и C. Я хочу, чтобы участники форума A могли входить и публиковать сообщения на форумах B и C, используя свои учётные данные форума A. То же самое должно работать для зарегистрированных участников форумов B и C.
Я думаю, что этот пост и следующие за ним должны быть перенесены в отдельную тему, так как они касаются подмножества функций, обсуждаемых здесь.
1 лайк
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta может вам помочь 
1 лайк
Теоретически, я полагаю, что вместо создания плагина Discourse, функционирующего как сервер протокола федерации ActivityPub, можно было бы настроить учётные записи на отдельном сервере ActivityPub, поддерживающем клиентский протокол Social API, и разработать плагин для Discourse, который общался бы с этим сервером по клиентскому протоколу, вместо того чтобы самому быть сервером ActivityPub. Это могло бы обеспечить более тесную интеграцию с существующими узлами ActivityPub. Однако, я не думаю, что это проще в реализации, чем серверный протокол, и это потребовало бы от администратора форума гораздо больше ручной настройки по сравнению с ролью сервера протокола федерации.
В моей идее того, что следует реализовать, для обеспечения возможности взаимодействия пользователей должен быть способ различать акторов-пользователей Discourse и системных акторов Discourse (например, категории). Я могу представить, что @#slug@discourse.example.org мог бы обозначать актора категории, оставляя место для последующего добавления акторов-пользователей @username@discourse.example.org. Но учитывая распространённость хэштегов, на практике это может просто не сработать.
Было бы проще сосредоточиться только на пунктах 1–3, исходя из того, что пункты 4–5 уже приближаются к попытке превратить Discourse в универсальный сервер ActivityPub, что, безусловно, не является целью.
2 лайка
Mastodon использует следующие регулярные выражения для валидации:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=^|[^\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\.\-]+[[:word:]]+)?)/i
Насколько я понимаю, USERNAME_RE применяется к удалённым пользователям, поэтому мне не совсем понятно, как организовать раздельные пространства имён для пользователей и категорий в Discourse. Это также исключает возможность использования обычных слайгов подкатегорий. Выражение @parentcategory:subcategory@discourse.example.org тоже не будет работать с этим регулярным выражением.
Возможно, можно было бы ввести опциональный поддомен вида @username@users.discourse.example.org, но это потребовало бы дополнительной настройки SSL и DNS и, вероятно, часто приводило бы к ошибкам конфигурации. Возможно, просто не стоит этого делать.
1 лайк
Возможно, имеет смысл не создавать федерацию с другими платформами, а создать федерацию между всеми инстансами Discourse, поскольку их количество очень велико.
2 лайка
Здесь, безусловно, огромный потенциал. Возможности и реализуемость требуют тщательного и взвешенного рассмотрения.
Это может оказаться территорией «Ксанаду»… (Прочитайте сообщение Джеффа выше и перейдите по ссылке в нём.) Столь широкая интеграция, вероятно, также нежелательна для большинства администраторов и операторов экземпляров Discourse. Необходимо провести формальный опрос администраторов и операторов (в отличие от «опроса по уровню трафика» в дискуссионных форумах).
Это выглядит как приглашение к взлому, поскольку здесь «ключи от царства» оказываются в руках любого, кто сможет скомпрометировать учётные данные пользователей любого из федеративных сайтов. По крайней мере, эти функции должны быть отключены по умолчанию или явно загружаться как плагины — с включёнными и заблокированными функциями безопасности. Zoom научил нас этому уроку: справедливо оставив свою платформу открытой и простой в использовании (чтобы быстро набрать и привлечь пользователей на этапе роста), они были вынуждены быстро всё заблокировать, как только хулиганы нашли незапертую переднюю дверь.
Тем не менее, микрофедерация сайтов стала бы стимулом для внедрения Discourse. Если бы я мог создать круг сайтов для моего муниципалитета, объединяющий один и тот же пул пользователей (например, жителей округа или города), это позволило бы людям общаться и могло бы привести к позитивным результатам в местном самоуправлении и жизни сообщества. Этот же принцип применим к любому бизнесу, достаточно крупному, чтобы оправдать накладные расходы на администрирование нескольких экземпляров Discourse, чтобы каждое подразделение могло иметь свой собственный контейнер Discourse с лёгкой навигацией к другим подразделениям. ИМЕННО ЭТО и было бы воплощением meta.discourse.
Однако Джефф, Сэм и компания [@codinghorror @sam] и/или их Руководящий комитет должны сначала решить, является ли Discourse социальной платформой или корпоративной платформой. Мой голос за корпоративный сектор, потому что я вижу там наибольший потенциал для обеих сторон этого разделения. Корпоративный сектор принесёт наибольшую финансовую выгоду и немедленную социальную пользу, улучшив способность бизнеса поддерживать сотрудников (хорошо заботьтесь о бизнесе, и бизнес сможет хорошо заботиться о вас). Часть этих коммерческих средств, вероятно, затем могла бы поддержать фонд social.discourse.org. Также весьма вероятно, что функции, полезные для корпоративного сектора, хорошо перенесутся и в социальную сферу. Эти два фактора создают общую выгоду для всех.
Однако эти две сферы должны быть раздельными, поскольку они настолько различны. И функции, которые «приятно иметь», неизбежно должны отдавать предпочтение той версии, которая является основным вариантом использования.
К счастью, выгоды идут в обе стороны, поскольку любой, кто интересуется social.discourse.org, получает вознаграждение от социальных аспектов построения сообщества и возможности заниматься деятельностью, связанной с сообществом, поэтому будет работать — и часто усердно работать — ради этих нефинансовых наград. Эта работа в рамках social.discourse.org неизбежно приведёт к разработке и функциям, полезным в корпоративном контексте, и тем самым вернёт ценность корпорации Enterprise Discourse Incorporated в обмен на поддержку некоммерческого фонда Social Discourse Foundation. Ещё больше выгоды для всех.
Обратите внимание, что выше нет ни одного восклицательного знака. Это просто факты и утверждения о вероятных исходах. Очень прагматично.
Я уже несколько лет ищу подходящую платформу GroupWare для своих предприятий. Slack на короткое время вселял большие надежды, поскольку был разработан для внутреннего использования в бизнесе (и имеет очень интересную историю создания), но даже не прошёл первичный отбор. Я очень впечатлён Discourse и оптимистично настроен в его отношении.
1 лайк
В этом и заключается суть этой темы, то есть между экземплярами Discourse.
Об этом сказано в первом сообщении:
2 лайка
Верно, и
и
микрофедерация сайтов стала бы подспорьем
Всё по теме, не так ли? 
Не обязательно это является обязательным условием. Следует учитывать экосистему плагинов.
Значительные по масштабу функции часто разрабатываются в виде плагинов или даже компонентов тем (где это возможно), что не требует такой административной нагрузки и централизованного планирования.
Это одна из прелестей экосистемы Discourse.
Например, Pavilion создала Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard (чтобы назвать лишь некоторые) без консультаций с CDCK. Отсюда, отчасти, наше участие в этом обсуждении.
7 лайков
Благословите наших разработчиков плагинов! Они щедро предоставляют примеры концепций, которые можно протестировать в реальных условиях и рассмотреть для включения в основной продукт. Ваш многоязычный плагин — отличный пример!
На сайте python.org эту роль играют разработчики библиотек, которые иногда создают функции, без которых просто невозможно обойтись, и которые принимаются для включения в основной пакет Python или стандартную библиотеку дистрибутива.
2 лайка
Я уже неоднократно высказывался в пользу добавления поддержки федерации в Discourse в ряде тем на этом форуме, например здесь. Сейчас, когда Феди́верс выходит в мейнстрим, а Tumblr и, возможно, Flickr и другие платформы добавляют поддержку федерации, возникает вопрос: заинтересован ли Discourse в том, чтобы тоже внедрить такую поддержку?
Со мной связался один из основных разработчиков Flarum, чтобы получить совет по реализации ActivityPub, и я отправил ему несколько ссылок, в том числе ту, что указана выше.
PS. На форуме разработчиков SocialHub, сообщества разработчиков Феди́верса, мы уже давно ищем способ стать частью Феди́верса, поскольку отдельные форумы оказались слишком серьёзным барьером для участия большинства людей.
7 лайков
В последнее время я проявил умеренный интерес к Mastodon (достаточно, чтобы купить доменное имя, но не установить сам Mastodon), поэтому я немного почитал об аутентификации Discourse с помощью Mastodon.
Я нашёл несколько сообщений, в которых утверждается, что это сложнее, чем думают люди. Насколько я помню, предлагался грант на разработку плагина, но, похоже, он не был реализован. Моё предположение: это задача стоимостью в 10 000 долларов; если я прав, то вам понадобится именно такая поддержка.
Редактирование: но я путал аутентификацию с федерацией.
1 лайк
Моя общая озабоченность здесь заключается в том, что идеи обычно огромны, и их крайне трудно разбить на небольшие части.
Мне кажется интересной идея федерации. Возможная конкретная реализация могла бы быть такой:
- Разрешить администраторам Discourse объединять категорию в федерацию.
- Пользователи Mastodon смогут подписываться на неё, например, подписаться на:
announcements@meta.discourse.org. - При создании новых тем с объявлениями будет публиковаться новое сообщение в федерации с кратким выдержкой и ссылкой на оригинал.
- Когда пользователи отвечают в Discourse, новые ответы будут передаваться в федерацию и атрибутироваться (как ответы на оригинальную тему).
- Когда кто-то из федеративного мира отвечает, на теме создаётся «тенистое» сообщение, атрибутированное автору ответа в Mastodon.
Подобное решение хотя бы достаточно компактно, чтобы поместиться в моей голове.
13 лайков
Проблема с ActivityPub заключается в том, что это открытый стандарт, легко читаемый человеком, но его реализация сама по себе ещё не делает вас «частью Фединверса». Необходимо реализовать ещё множество других вещей, а для домена «Форумы обсуждений» — также собственный словарь ActivityPub для обмена сообщениями. Существуют другие проекты, на основе которых можно начать разработку, и некоторые библиотеки, которые можно адаптировать, но, безусловно, потребуется значительная разработка.
Что касается продвижения: лично я считаю, что при грамотной реализации поддержка AP может стать уникальным торговым преимуществом продукта. Отсутствие необходимости регистрироваться на каждом форуме — это уже плюс, и для меня это тоже является барьером. Стоит ли мне регистрироваться ещё на одном форуме Discourse только ради одного поста, который я хочу добавить?
Однако федерация может принести гораздо большую ценность. В моём идеальном сценарии я бы установил личный форум Discourse или зарегистрировался на инстансе, который, как и Mastodon, изначально был бы полностью пустым. Затем я бы самостоятельно наполнил его структурой сообщества в соответствии со своими потребностями и интересами: выбрал бы тематическую группу, добавил её в соответствующую категорию, добавил бы ещё одну группу и так далее.
Обновление: Перекрёстная публикация с @sam .. это было в ответ на @pfaffman
5 лайков
Да, это было бы отличным началом. Агрегатор ссылок Lemmy работает примерно так же, предлагая федерацию сообществ. Обратите внимание, что, хотя более широкое взаимодействие было бы очень желательным, федерацию можно реализовать уже на старте только между экземплярами Discourse / арендаторами.
Не всё подходит для Mastodon. Это приложение для микроблогов, которое не поддерживает Markdown (хотя другие приложения в федерации это делают).
В настоящее время ведется работа над дальнейшей поддержкой федеративных Групп. Примером служит Lemmy. Bonfire добавит круги, похожие на Google+, и другие функции.
3 лайка
Да! Это именно тот рабочий процесс, который я хотел бы видеть. И продвигать. 
Длина отрывка могла бы быть легко настраиваемой: значение 0 означало бы всю статью, а не отрывок. Обратите внимание, что ограничение в 500 символов в Mastodon произвольное и не имеет никакого отношения к Fediverse, ActivityPub или ActivityStream. Узлы Mastodon, которые я запускаю, сейчас имеют лимит в 2000 символов, а лимит на social.kernel.org составляет 31337 символов. Даже стандартный Mastodon с его лимитом в 500 символов для написания постов корректно отображает более длинные сообщения.
Я вижу одну небольшую сложность: пространства имен пользователей и категорий в Discourse разделены, но в ActivityPub они представляют собой одного и того же «Актора», а как минимум в Mastodon существует довольно строгий регулярный выражение для распознавания Акторов. Учитывая, что для категории #announcements используется @announcements@meta.discourse.org, этот комментарий был бы передан в федерацию как authored пользователем @mcdanlj@meta.discourse.org.
По умолчанию, как администратор Discourse, я бы хотел использовать slug категории в качестве имени Актора. Думаю, что если при настройке федерации для категории администратор выбирает имя Актора (по умолчанию — slug), то оно будет (как имя группы) уникальным относительно имен пользователей Discourse.
(Кстати, я раньше беспокоился о регулярном выражении Mastodon для распознавания имен акторов, но теперь думаю, что оно используется только для упоминаний людей, что в данном случае не особенно ценно. Так что, возможно, даже сработает представление, например, #documentation:admins как @documentation:admins@meta.discourse.org, хотя я бы определенно хотел протестировать это с несколькими основными системами микроблогинга, обязательно включая Mastodon и Pleroma.)
3 лайка
С точки зрения пользователя Mastodon или Pleroma это, вероятно, выглядело бы так: @announcements@meta.discourse.org будет репостить (boost/reblog) тему, созданную, например, @sam@meta.discourse.org, а затем также репостить комментарий, оставленный, скажем, @mcdanlj@meta.discourse.org, как ответ на исходное сообщение (OP). Ни исходное сообщение, ни комментарий на самом деле не публикуются категорией — их публикует человек в рамках категории.
Возможно, плагин изначально будет поддерживать только WebFinger для акторов категорий (чтобы можно было на них подписываться), но в конечном итоге может иметь смысл реализовать это и для отдельных пользователей. На Mastodon я, например, вполне мог бы захотеть подписаться на @sam@meta.discourse.org, чтобы видеть его публикации и комментарии.
2 лайка
Вопрос: каков текущий статус этого обсуждения и планы по возможной реализации? Нужна ли вам, например, поддержка в тестировании? Или этот вопрос пока «слишком преждевременен» 