У меня то же самое. Я не могу изменить владельца темы, даже если категория НЕ является федеративной.
Это предупреждения, а не ошибки. Они не обязательно означают, что что-то не так; они предназначены для предоставления вам дополнительной информации о происходящем. Существует множество причин, по которым контент из Федериверса не обрабатывается, и многие из них связаны с отправителем контента. Если вы не хотите, чтобы они отображались в ваших логах, отключите подробное ведение логов для плагина ActivityPub (activity pub verbose logging).
Находится ли тема в категории ActivityPub или у неё есть тег ActivityPub?
Была ли тема создана в категории ActivityPub или с тегом ActivityPub?
Обратите внимание, что изменение владельца темы намеренно отключено для тем ActivityPub. Причины этого описаны выше:
Это категория с ActivityPub, но мы говорим о владельце темы, который не участвует в ActivityPub, так как это другой аккаунт.
Я думаю, что должна быть возможность изменить владельца в любом случае, иначе не имеет смысла, что в Discourse есть модальное окно для смены владельца.
Также возможность изменить его без отправки обновлений в ActivityPub идеально подходит для нас.
1 лайк
Я понимаю, что многие хотят иметь возможность менять владельца сообщений. Проблема, которую нужно решить в этом контексте, — это та, о которой я говорил выше, а именно:
Контент, отображаемый на вашем Discourse, поступает из сервиса, где вы не являетесь администратором и над которым, за исключением ActivityPub, у вас вообще нет никакого контроля. Просто расширять возможность изменения автора такого контента без должного учёта этого факта было бы неразумно.
Что касается контента, созданного пользователями вашего Discourse в теме, опубликованной через ActivityPub, подумайте, что должно происходить, если после смены автора сообщения вносятся какие-либо обновления. Должны ли мы:
- прекратить публикацию обновлений ActivityPub;
- публиковать их от имени «старого» актора (пользователя);
- публиковать их от имени «нового» актора (пользователя).
Публикация обновлений для существующего объекта с новым актором (то есть вариант 3) будет работать в Discourse (я пытался предусмотреть возможность решения этого вопроса), но не будет работать с другими сервисами ActivityPub. Действительно, я уже поднимал этот вопрос в экосистеме ActivityPub именно по этой причине. См. здесь:
Также у меня есть незакрытый PR в Mastodon, чтобы сделать вариант 3 возможным:
В качестве примера одной из проблем рассмотрите ситуацию, когда вы публикуете контент через ActivityPub со своим аккаунтом (вашим именем и фото). Один из ваших «конкурентов» подписывается на ваш контент. На их сервере они затем меняют владельца всех постов с вашим контентом, делая их постами от их имени (с их именем и фото) вместо ваших. Это может, что вполне понятно, вас возмутить. Да, конечно, это возможно реализовать с помощью кастомного кода, но вопрос в том, хотите ли вы встроить такую возможность в стандартные функции плагина.
Подумав об этом overnight, один из подходов, который мог бы несколько смягчить ситуацию, — добавить отображение актора публикации в статус ActivityPub:
Я открыт к другим идеям в этом духе.
Верно, я думаю, что просто уберу модальное окно полностью для тем в ActivityPub, пока мы не решим этот фундаментальный вопрос.
2 лайка
Я понимаю проблему: в нашем случае мы используем ActivityPub с отдельным аккаунтом для каждой категории и поста, которые обновляются. Поэтому для нас в рамках ActivityPub не так важно, кто является владельцем темы в различных сценариях. По этой причине я считаю, что мы должны иметь возможность делать это в любом случае.
ActivityPub — это не только о том, как вы используете свой форум, но и о том, как ваш форум взаимодействует с остальной частью федиверса. Более того, при внедрении каких-либо функций в плагин мы должны учитывать и другие сценарии использования.
Я не хочу создавать впечатление, что возможность смены владельца поста не рассматривается активно или что она не будет реализована в будущем обновлении. Мне интересны любые идеи по решению лежащих в основе проблем, некоторые из которых я изложил выше.
Отвечая на этот пример, было бы разумно запретить изменение владельца постов, которые были получены через федерацию, при этом разрешая администраторам изменять владельца постов, созданных внутри этого экземпляра Discourse, независимо от того, федерированы они или нет.
Администратор может выдавать себя за пользователя. Следовательно, администратор способен в рамках платформы с её существующими возможностями создавать контент, маскируясь под любого пользователя платформы. Я надеюсь, что администраторы не будут злоупотреблять этой властью; я не буду. Однако эта власть по своему воздействию схожа с возможностью изменять владельца поста, федерированного или нет. В целом, утверждение «администратор может сделать что-то злонамеренное» уже верно множеством способов.
Я согласен (по крайней мере, насколько я понимаю 
), что изменение владельца поста, созданного через федерацию (следовательно, это не пост темы?), не имеет особого смысла. В отличие от изменения владельца постов, созданных на сайте, я не припоминаю, чтобы кто-то озвучивал конкретный сценарий использования для этого.
Мне это нравится не только с точки зрения устойчивости к такого рода атакам, но и для повышения видимости федерации, облегчая посетителям сайта поиск акторов, на которых можно подписаться. Как бы это выглядело в случае, когда есть актор категории (и, возможно, когда-нибудь, актор сайта?) и актор-человек? У вас был бы список?
- Опубликовано
[@category@site](link) - Опубликовано
[@person@site)(link)
1 лайк
Спасибо за ваш полезный анализ.
Согласен.
Этот анализ верен только для сообщений, не распространённых в федеративную сеть. Вопрос не в том, имеет ли смысл для самого Discourse изменять владельца сообщения. Вопрос в том, какие последствия изменение владельца имеет для распространённого контента. Если вы измените владельца локального сообщения, которое было распространено, вам придётся ответить на следующий вопрос:
Я начну с того, что оба варианта 1 и 2 имеют существенные проблемы, которые я могу подробно объяснить, если потребуется. Ответом может быть тот, который уже поддерживается плагином, а именно «3», однако, если мы пойдём по этому пути, произойдёт следующее (предполагая, что мой текущий PR в Mastodon не будет принят):
- Тема распространена.
- Сообщения из темы появляются в Mastodon.
- Администратор сайта меняет владельца сообщения.
- Новый владелец сообщения вносит различные правки в сообщение.
- Правки не попадают в Mastodon (или на любую другую платформу ActivityPub, если уж на то пошло).
И исходя из этого:
- Кто-то придёт сюда и скажет: «мои правки не распространяются». Причина этого не будет сразу очевидна, потому что с точки зрения Discourse они распространяются.
Ключевой момент здесь в том, что если мы выберем такой подход, мы станем первой платформой в федеративной сети (насколько мне известно), которая это делает. Быть единственным узлом в взаимосвязанной системе узлов, делающим что-то такое, не является очевидно желательным действием. Мы можем спровоцировать изменения в этом отношении, но должны осознавать, что именно это мы пытаемся сделать.
Тем не менее, я уже реализовал вариант 3, и подозреваю, что это будет окончательным решением, которое позволит мне снять это ограничение. Я всё ещё надеюсь, что кто-то сможет предложить немного более нюансированный подход или что-то, что я ещё не учёл.
В списке будет указан только Актор attributedTo объекта, поэтому будет только один.
1 лайк
Я вижу, насколько это неуклюже. Логика, которая привела меня к такому решению, примерно следующая…
Я мог бы наивно представить вариант, похожий на #3, но с небольшим добавлением из #2 — например, чтобы при федерации сгенерировать обновление от старого пользователя, которое добавляло бы к последней версии, опубликованной им, сгенерированную системой строку вверху или внизу, что-то вроде: «Для будущих обновлений следите за @newuser@site».
Тогда (опять же, наивно) имело бы смысл назначить новый ID для обновлённого поста под новым атрибутом attributedTo, который будет использоваться для обновлений нового владельца.
Очевидный для меня пограничный случай — это возврат прав владения первоначальному владельцу. Возвращается ли пост к старому ID или назначается ещё один новый ID? Я склоняюсь к тому, что должен быть возврат, в котором случае ID федеративного поста фактически должен быть ключом для кортежа (пользователь, пост Discourse). Я ожидаю, что для поддержки этого с обратной совместимостью потребуется миграция.
Всё это, как мысленный эксперимент, заставляет меня яснее понять, почему вы не стремитесь торопиться с внедрением предлагаемого вами изменения, которое рассматривается для Mastodon! 
Независимо от того, будет ли принят ваш PR для Mastodon, я мог бы представить возможность помечать отдельные посты как нефедерируемые. В таком случае они федерировались бы как удаление, если ранее были федерированы, и/или это можно было бы сделать с установленным плагином, но до включения федерации. Затем можно было бы разрешить смену владельца только для нефедерируемых постов. Насколько я могу судить, все посты, для которых я хочу иметь возможность менять владельца, — это посты, которые не представляют ценности для федерации.
Я мог бы представить, что это было бы полезно даже в случае принятия вашего PR для Mastodon и поддержки смены владельца. Не уверен, что имеет смысл федерировать посты категорийных тем. По крайней мере, я думаю, что исключил бы все из них из федерации на моём сайте, даже если бы была поддержка смены владельца, при наличии такой возможности их исключения.
Интересный мысленный эксперимент, однако это не сработает по нескольким причинам.
- В ActivityPub для Discourse вы не подписываетесь на отдельных пользователей.
- Нельзя изменить ID существующего объекта ActivityPub (придётся создавать новый объект).
- Как вы сами заметили, если владение изменится снова или несколько раз, для одного поста образуется несколько объектов, что станет неуправляемым.
Одно, что я могу сделать сейчас в этом направлении, — изменить ограничение на то, опубликован ли первый пост в локальной теме. Это поможет с некоторыми темами, как вы и отметили.
1 лайк
Я ошибся; мне казалось, что вы также добавили возможность делать это, а также создавать акторов для категорий. (Это не запрос на новую функцию, а просто моё заблуждение.)
Именно это я и пытался описать, хотя и не очень удачно. В любом случае, это было задумано как своего рода reductio ad absurdum. 
Это было бы замечательно! 
1 лайк
Привет, есть ли ограничение в Lemmy?
Я не могу подписаться на @batepapo@lemmy.eco.br, например.
На самом деле, я могу подписаться. Кнопка «Отписаться» даже появляется под профилем, но при обновлении страницы всё исчезает.
1 лайк
Отличная работа! У меня вопрос касательно задержки доставки в Activity Pub (в минутах). Можно ли отключить эту функцию, чтобы пост был виден сразу?
Установка 1 мин — это почти мгновенно, но я также хочу публиковать в реальном времени.
1 лайк
@David_Ghost прочитайте это
2 лайка
Я тоже это заметил. В чём недостаток добавления заголовка новой темы в пост, распространяемый через ActivityPub?
[Заголовок темы Discourse]
[пустая строка]
[Текст темы Discourse, как публикуется сейчас]
Команда Lemmy работала над добавлением совместимости с Discourse. Я планирую проверить этот вопрос.
Это означает, что Discourse отправляет запрос «Подписаться», но не получает от Lemmy подтверждения «Принято».
В настоящее время это можно сделать только с помощью переменной окружения (например, установленной в файле app.yml):
DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0
Заголовок темы уже публикуется. Он является полем name коллекции, связанной с темой.
Именно так при федерации между экземплярами Discourse, или между Discourse и NodeBB, или между Discourse и любой другой платформой, похожей на форум, включаются заголовки тем. Mastodon не обрабатывает заголовки. Если бы мы помещали заголовок темы в содержимое заметки, как вы предлагаете, это создало бы проблемы, например, при федерации контента на платформы, поддерживающие заголовки.
В основе описываемого вами ограничения лежит тот факт, что Mastodon — это платформа для микроблогов. Мы уже добавили функциональность для учёта этого, а именно разметку [note][/note], позволяющую выбирать контент для федерации. Если вы хотите полноценную федерацию в стиле форумов, я рекомендую использовать другие экземпляры Discourse.
Да, существует множество экземпляров Mastodon. Но есть и множество экземпляров Discourse. Если экземпляр Discourse, с которым вы хотите установить федерацию, ещё не настроен для этого, я с радостью помогу им с настройкой.
5 лайков
Возможно ли удалять Акторов?
И можно ли настроить несколько категорий, чтобы он публиковал всё новое в Discourse?
В противном случае кому-то придётся подписываться на множество аккаунтов в Mastodon, чтобы получать контент из всех категорий.
Вы можете отключить Актора, что отключит всё, связанное с этим актором.
Если вы удалите категорию или тег, с которыми связан актор, это приведёт к удалению Актора. Удаление Актора изолированно в настоящее время невозможно. Я рекомендую просто отключить Актора.
Это может стать возможным в будущем (среднесрочная или долгосрочная перспектива), если мы добавим актор «Приложение» для всего Discourse. Федерация всего контента в Discourse через одного Актора, вероятно, всегда останется нишевым вариантом использования.
1 лайк
Хм, хорошо. Возможно, моё понимание возможностей отличается…
Вчера я всё настроил, и всё работало отлично. Я удалил посты на Discourse, потому что просто тестировал, но посты всё ещё доступны в Mastodon. Поэтому я подумал, что могу удалить аккаунт, чтобы удалить контент и из Mastodon.
Когда я просто отключаю его, контент всё ещё доступен в Mastodon.
А если я не могу его удалить, то не смогу использовать этот хендл для других категорий в будущем. Возможно, я захочу изменить некоторые категории, но не смогу использовать их с этим хендлом, у которого уже есть xx подписчиков. Так что мне придётся создать новый хендл, и всем придётся подписываться на него заново. Я не вижу преимуществ в том, чтобы просто отключить хендл, который мне больше не нужен.
И ещё: когда я отключаю один хендл, другой тоже отключается. Значит, я могу запускать только несколько хендлов или ничего?
Но ведь именно этого я и хочу, или я что-то понимаю неправильно? Я хочу информировать людей в социальной сети о обсуждениях на всём моём Discourse, а не только по одному тегу или категории. Если я веду раздел «Новости», это понятно, но я хочу, чтобы все участвовали в обсуждениях, поэтому мне нужно публиковать всё, а не только одну категорию.