Просто заметка: мы сейчас находимся на этом этапе
5 лайков
Выглядит отлично!
Недавно я настроил сервер Discourse для нашего кооператива CoSocial, который также запускает сервер Mastodon. В итоге я установил плагин OAuth2, чтобы мы принимали только логины с нашего сервера Mastodon → https://members.cosocial.ca (очень простая новая установка, просто «подтверждение OAuth»).
Мой вопрос / предложение по функциональности: было бы здорово иметь возможность синхронизировать или объединять аккаунты Mastodon с аккаунтами Discourse, чтобы при ответах с аккаунтов Mastodon они могли быть связаны / принадлежать соответствующему аккаунту Discourse.
Как это не делает Lemmy
Я описал, как Lemmy не делает этого — вы можете взаимодействовать через Mastodon, и для этого аккаунта Mastodon создается аккаунт в Lemmy, но вы не можете войти в систему и использовать основные функции Lemmy со своим аккаунтом Mastodon.
4 лайка
Это уже включено в план работ…
И уже находится в очереди на рассмотрение
3 лайка
Отлично. Похоже, что пользователям плагина OAuth для Discourse потребуется «подтвердить ещё раз», чтобы обеспечить совместимость с этим плагином AP.
Я считаю, что на данном этапе это вполне приемлемо. Просто хочу отметить сервер OAuth как ещё один аспект, при условии, что это не создаст конфликтов. «Желательно иметь» — это «если используется OAuth с сервером Mastodon, то автоматически связать идентичность актора AP». Это полностью будущая функция, и она уникальна именно для такой конфигурации!
(И извините, что не открыл страницу, чтобы посмотреть на эту часть! Отлично!)
1 лайк
PR, добавляющий этот набор функций, теперь объединён.
Как отметил выше Angus, следующим шагом будет верификация пользователей через OAuth-токены.
2 лайка
Проблемы с необработанным Markdown, которые я ранее наблюдал, похоже, затрагивают и Meta. Я подписан на @feature@meta.discourse.org, и несколько часов назад был создан этот пост, федеративно переданный от этого актора:
В Mastodon он отобразился у меня со сбоем вот так:
В Elk выглядит немного лучше:
Я только что начал подписку на @feature@meta.discourse.org в своём «чистом» аккаунте Mastodon, чтобы протестировать это, но, конечно, уже слишком поздно, чтобы увидеть этот конкретный пост там. 
Так что встроенный Markdown, который я видел ранее в своей установке, не был вызван ошибкой в базе данных. Или, если и был, то это проблема базы данных, общая с Meta, и, следовательно, вероятно, не связана с моим тестированием.
2 лайка
Да, я могу воспроизвести это. Я вижу похожий вывод на экземпляре Mastodon и в приложении Ivory (iOS).
2 лайка
Не уверен, что всё работает правильно. Плагин включён, я создал тему в категории с включённым ActivityPub, но значок рядом с сообщениями не отображается (и моя попытка подписаться на актора ActivityPub категории, похоже, не удалась, так как система ведёт себя как сервер, где подписки требуют ручного подтверждения пользователем).
Я только что заметил, что та же проблема, похоже, возникла с #feature на Meta.
1 лайк
Было бы здорово понять конечную цель ограничений, не беспокоясь о промежуточном состоянии.
Например, мне кажется, я видел упоминание в PR о том, что смена владельцев постов будет заблокирована, если плагин включен. Как администратор, я использую эту функцию в редких случаях (например, при смене модератора категории я делаю нового основного модератора категории владельцем закрепленного поста в этой категории). Я надеюсь, что в итоге это будет отображаться как удаление и повторная публикация, или даже просто игнорироваться, вместо блокировки смены владельца.
Также меня интересует перемещение постов между категориями. Мне приходится делать это довольно часто, особенно когда новые пользователи публикуют посты в неправильной категории. Я наивно ожидаю, что это приведет к тому, что актор старой категории уберет свой репост, а актор новой категории добавит его, но сам пост при этом не будет удален, так что если кто-то другой уже увидел и репостнул пост, его репост не исчезнет только потому, что репост актора категории был удален.
В целом, было бы очень полезно узнать, что, по вашим ожиданиям, будет запрещено после добавления этого плагина и завершения разработки всех описанных функций, независимо от того, какие ограничения действуют в данный момент.
1 лайк
@hello-smile6 Я наблюдаю то же самое с плагином, обновлённым сегодня:
Я не вижу конфигурации для этого, поэтому предполагаю, что это ошибка.
2 лайка
Спасибо за дополнительный отчёт. Я разбираюсь в этом.
Спасибо за отчёт, мы разбираемся в этом.
Я понимаю вашу точку зрения, однако:
-
Пока плагин активно разрабатывается, попытки объяснить всё в таком ключе были бы бесплодными, так как объяснение может измениться.
-
Существует довольно много различных сценариев и частных случаев, с которыми плагин уже справляется. Объяснить каждый из них повествовательно на данном этапе заняло бы слишком много времени (то есть фактически пришлось бы написать этот длинный пост несколько раз). Для плагина уже существует более 400 различных спецификаций.
-
Тем не менее, ограничения часто разъясняются повествовательно в комментариях к PR и коммитам, которые вы, как я полагаю, уже читаете.
Это обсуждалось довольно подробно в PR
Я ограничил изменение владельцев постов и создание вики-постов, даже для администраторов, в темах AP. Это связано с тем, что удалённые посты AP должны сохранять точность по отношению к оригиналу, и оба действия могут потенциально нарушить эту точность.
Возможно, существует способ заставить федерацию работать и с вики, и со сменой владельцев постов, однако я предлагаю добавить это как «функцию» в будущем PR, так как это потребует умножения или изменения актора, связанного с объектом, который федеративно распространяется по нескольким платформам. Я считаю, что мы никогда не сможем разрешить изменение владельцев импортированных постов AP (заметок), так как связь актора/объекта не принадлежит Discourse, а принадлежит месту, где был создан контент. Для наглядной аналогии: в данном контексте удаление поста, связанного с импортированной заметкой, является не столько «удалением» как таковым, сколько выбором не показывать Заметку.
Существует довольно много различных сценариев, связанных с перемещением постов. Я пока займусь конкретным случаем, который вы упомянули, а именно перемещением поста между двумя разными категориями, поддерживающими ActivityPub.
Вы предполагаете, что единственный случай перемещения поста между категориями — это когда пост изначально опубликован в неправильной категории, и перемещение происходит вскоре после его создания. А что, если через 4 месяца после создания поста вы переместите его в другую категорию, потому что хотите объединить определённую коллекцию постов в новую тему в другой категории? Имело бы смысл отправить «Отмену» для первоначального репоста в таком сценарии?
Это зависит от того, говорим ли мы о конфигурации «Первый пост» или «Полная тема». В первом случае мы добавим кнопку для ручной публикации первого поста, чтобы специально решить сценарий перемещения категории. Во втором случае автоматическое добавление репоста может иметь смысл, я подумаю над этим ещё.
Я понимаю вашу точку зрения, однако я уже поделился довольно подробной информацией о конечном состоянии в спецификации Фазы 2 выше. За пределами этой спецификации, и выражаясь максимально мягко, существует слишком много вариантов использования и сценариев, чтобы обсуждать их все подробно с вами, а затем и с командой Discourse.org, параллельно с их реализацией 
Я обновлю первое сообщение общим обзором ожидаемого поведения после завершения Фазы 2.
1 лайк
Мне не удалось воспроизвести эту проблему. Я просто подписался на feature@meta.discourse.org с тестового аккаунта Mastodon и не увидел ошибок (ни в Mastodon, ни в Discourse).
1 лайк
Возможно, это связано с инстансом, с которого я его перешёл. Делает ли этот инстанс что-то необычное?
Ох, как жаль, что в попытке задать чёткий вопрос я создал впечатление, будто прошу о большой работе. Приношу извинения за недопонимание. Благодарю за вдумчивый ответ.
Именно это я и хотел спросить, а не постоянные подробные обновления в этой теме. Моё слово «после» в фразе «после завершения разработки указанной функции» относилось к тому моменту, когда уточнение будет полезно получить, а не к тому, чтобы вы сейчас описывали будущее состояние. Мой вопрос был сформулирован неоднозначно. Извините за это!
Вот что я действительно хотел понять: является ли конечной целью, в общем смысле, ограничить Discourse только тем, что официально поддерживает ActivityPub, или же цель — обеспечить федерацию от неограниченного нативного опыта Discourse к федиверсу по принципу «по возможности»? Мой прошлый опыт интеграций с Discourse заставлял ожидать подход «по возможности»; теперь я понимаю, что вы планируете стремиться к точности, даже ценой функциональности Discourse, и это не временная мера на период разработки.
Я не делаю такого предположения. Почему бы четыре месяца имели бы значение здесь? Пост только что оказался в федеративной категории, почему бы этому не вызвать репост со стороны федеративной категории? Я, по крайней мере, наивно ожидал, что это произойдёт. Я часто вижу, как люди репостят сообщения, которым несколько месяцев, поэтому я не знаю конкретной причины, почему здесь должно быть иначе.
И да, я считаю, что имеет смысл отправить «Отмену» для первоначального репоста. Это кажется распространённой практикой. (Фактически, отмена репоста с последующим новым репостом — типичный механизм для «поднятия» контента; это не связано с данной целью, но иллюстрирует, что отмена репоста широко используется и поэтому не должна создавать проблем для других реализаций ActivityPub.)
Я сейчас наблюдаю то же самое для feature@meta.discourse.org с mastodon.cloud, который, как мне кажется, работает на чистом Mastodon.
1 лайк
Лично я не рассматриваю вопрос ни с той, ни с другой стороны. Discourse.org определит общую повестку, но в целом решения принимаются исходя из того, как это работает и что практично. Если существует разумный и устойчивый способ разрешить изменения авторства для всех сообщений, независимо от их происхождения, то это отлично.
Сосредоточившись исключительно на отмене первоначального распространения, кажется, что эта конкретная отмена не имеет цели? Кроме того, в некоторых сценариях это может показаться немного неожиданным, как пытался показать мой пример. Цель перемещения категории может заключаться не в том, чтобы отменить (Undo) первоначальную «обнаруживаемость» контента. Возможно, это сделано для изменения организации контента в будущем по другой причине.
Иными словами, автоматическая отмена первоначального действия Announce при изменении категории в Discourse работает в некоторых сценариях, но не во всех. И даже в сценариях, где это кажется более логичным, первоначальное Announce на самом деле не наносит никакого вреда. Поэтому, следуя принципам минимального вреда и минимального удивления, кажется, что более разумным будет оставить первоначальное Announce без изменений. Извините, если я что-то упускаю.
Если посмотреть на это с другой стороны, я считаю, что неправильно рассматривать действия Announce актора Категории как синоним таксономической роли самих Категорий. Announce — это способ, которым актор Категории делится контентом со своими подписчиками, но это не сама таксономия. Это один из способов обнаружения контента в федиверсе. Я не считаю, что должна существовать связь один к одному между категориями и действиями Announce акторов категорий.
3 лайка
Ах, значит, это действительно вопрос для команды. 
Это тоже имеет смысл. Я согласен: отменять усиление нет особого смысла.
Итак, это сигнал, срабатывающий по фронту; он будет означать «пост только что появился в этой категории, будь то созданный здесь или перемещённый сюда». Это концептуально просто.
Тогда я бы рассматривал изменение авторства поста аналогичным образом. Это было бы создание нового актором нового действия для поста нового автора, и нет особой необходимости что-либо делать с прежним действием, выполненным под именем старого автора, поскольку старый автор не будет вносить правки и не должен получать за них заслуги. Они на самом деле не удалили свой пост на Discourse, поэтому удаление активности старого автора не обязательно отражает какую-то объективную истину. Но то, что было опубликовано ранее актором старого автора, останется тем, что они написали, и нет причин удалять эти посты. И если кто-то перейдёт по ссылке обратно на Discourse, он увидит текущее содержание и авторство, а также (при наличии достаточных прав) историю редактирования.
Та же логика применима к вики-страницам. Они отображаются на Discourse под авторством одного человека, но с возможностью редактирования другими. Обновления, внесённые другими авторами, не получают широкого упоминания (если у вас нет достаточных прав для просмотра истории). Не так уж важно, отображается ли это упоминание в виде аватара в веб-представлении внутри Discourse или как актор ActivityPub, связанный с действием; конечный результат — это упоминание, представленное человеческому читателю в конце одного из конвейеров рендеринга.
1 лайк
Хм, не уверен, что согласен. Итогом этого станет наличие двух идентичных заметок в Фидиверсе, созданных разными акторами, которые будут видны на нескольких платформах. Для нового человека, впервые ознакомившегося с этим контентом, он будет выглядеть как один и тот же материал, но от разных авторов. Напротив, при смене автора на Discourse вы по сути переписываете историю: новый человек, впервые увидевший контент, увидит только нового автора. Разница есть, не так ли?
Не уверен, что полностью понимаю. Вы имеете в виду, что все правки в вики-посте, сделанные любым пользователем, должны просто рассматриваться как стандартные действия обновления, приписанные оригинальному актору (то есть человеку, который его опубликовал)?
Обратите внимание, что это предмет данного PR, сопровождаемый пояснительными заметками.
4 лайка