Да, Discourse может реализовать нечто подобное с помощью своего виджета встраивания комментариев. Это, среди прочего, могло бы помочь снизить неловкость, которую некоторые испытывают при запуске форума с небольшим количеством активных участников: AI sockpuppet accounts to jumpstart my community?. Новые сайты на Discourse могли бы использовать публикации в блогах для продвижения и наполнения своего форума. Это в какой-то степени возможно и сейчас, но возможность комментировать напрямую через виджет встраивания сделала бы этот процесс более плавным.
3 лайка
Простая форма комментариев, подключенная к Discourse на стороне WordPress, позволила бы посетителям оставлять комментарии без необходимости сначала переходить в Discourse и создавать там учётную запись. Это помогло бы снизить трение и повысить вовлечённость, по крайней мере для издателей вроде меня.
Для моего случая было бы идеально, если бы комментатор мог оставить свой комментарий, просто указав имя и адрес электронной почты. Эти данные затем можно было бы использовать для создания временной учётной записи в Discourse и отправки пользователю приглашения присоединиться к сообществу, чтобы продолжить обсуждение, не препятствуя при этом оставлению комментария.
Мы наблюдаем, что дополнительные сложности, связанные с созданием учётной записи для оставления комментария к опубликованной статье, затрудняют повышение вовлечённости и, в конечном итоге, рост сообщества на нашем форуме. Например, когда нас спросили о разделе комментариев (с использованием текущей интеграции Discourse и WordPress), один из авторов дал нам следующий отзыв:
Касательно раздела для обсуждения: теперь, когда вы об этом упомянули… я вспомнил об этом. И в тот момент я решил пока отложить это, так как регистрация казалась слишком затратной по времени. Это убедительное свидетельство того, как большинство людей отнесётся к необходимости проходить через этот процесс. Обычно я почти одержим тем, чтобы видеть комментарии к своим текстам. Помню, как я смеялся про себя и говорил: «Похоже, я не настолько одержим, чтобы иметь дело с этим прямо сейчас». В идеале комментарии должны быть открыты для всех без процесса регистрации. Но любое упрощение или облегчение этого процесса улучшило бы вовлечённость. Комментарии такого рода обычно оставляются импульсивно. Если люди хоть немного сталкиваются с препятствиями, они, как правило, уходят и не тратят время.>
4 лайка
Я как раз думал об этом на днях. Странно, но мне не хватает комментариев WordPress на моих постах в блоге, потому что там людям так легко начать, очень низкий порог входа.
Несмотря на очень простую процедуру регистрации, сейчас, если кто-то хочет прокомментировать пост, ему нужно перейти на новую страницу. Мне кажется, что преодоление этого порога может показаться слишком обременительным. Почти как будто я хочу прокомментировать А, но должен перейти на В, чтобы прокомментировать А, а затем вернуться на А, чтобы увидеть комментарий. Было бы естественнее комментировать А прямо под ним.
Мне нравится идея поэтапного создания пользователей. Я могу представить, как можно это реализовать, настроив форму комментариев WordPress так, чтобы она отправляла письмо на форум Discourse и таким образом создавала пользователя поэтапно, хотя, полагаю, полная интеграция таким способом может стать более сложной.
3 лайка
Кажется, раньше это было возможно, но я почти уверен, что теперь Discourse сравнивает заголовок «From» (От кого) письма с его Return-Path (обратным путём). Если они не совпадают, письмо отклоняется. (Если Discourse не проверяет Return-Path, систему комментариев можно было бы легко злоупотреблять — в форму можно было бы вводить любой адрес электронной почты.)
Есть несколько подходов к решению проблемы использования Discourse в качестве системы комментариев. Я считаю, что лучший вариант — это улучшение Discourse встроенного iframe для комментариев, чтобы пользователи могли взаимодействовать с ним как авторизованные пользователи Discourse. Если это невозможно, можно разработать отдельное веб-приложение для встроенных комментариев Discourse. Это был бы интересный проект, но я бы хотел убедиться, что Discourse не планирует предоставить аналогичный функционал через свой встроенный iframe для комментариев, прежде чем углубляться в эту идею.
Также существуют возможные решения, специфичные для WordPress. Самое простое — включить комментарии WordPress и плагин WP Discourse. Риск заключается в том, что это может снизить активность на форуме Discourse. Однако, думаю, есть способы помочь с этим в интерфейсе WordPress — например, добавлять ссылки на связанные обсуждения, происходящие на Discourse.
Также можно разработать решение, специфичное для сайтов WordPress, которые выступают в роли провайдера SSO для Discourse. Я писал об этом в предыдущих сообщениях этой темы. Для качественной реализации, возможно, потребуются значительные изменения в плагине WP Discourse. Если только (я думаю вслух):
На скриншоте выше я пытаюсь показать, что для случая, когда сайт WordPress является провайдером SSO для Discourse, комментарии могут отображаться через встроенный iframe комментариев Discourse. Создавать комментарии можно будет через форму, отправляющую данные в API Discourse. Возможно, это потребует некоторых изменений в iframe комментариев Discourse, чтобы гарантировать его обновление при добавлении нового комментария, но при этом не потребуется, чтобы пользователи могли взаимодействовать с ним как авторизованные пользователи Discourse.
4 лайка
Итак, если я правильно понял, идея заключается в следующем: комментатор регистрируется на стороне WordPress, затем оставляет комментарий через встроенный iframe Discourse, который публикует его в теме на Discourse, после чего отображение на WordPress обновляется, чтобы комментарий появился сразу.
Процесс регистрации на WordPress, полагаю, включает проверку email. Однако это также потребует переключения на WordPress в качестве провайдера SSO для Discourse — технически выполнимо, но в некотором роде неудобно, так как переносит трудности на другую сторону для тех, кто просто хочет зарегистрироваться на форуме.
Я склонен согласиться с тем, что вы написали здесь:
Если бы даже можно было зарегистрироваться прямо в этом iframe или хотя бы пройти предварительную регистрацию, чтобы продолжить написание комментария (который, возможно, будет опубликован только после проверки email), это показалось бы мне одним из решений, балансирующим между удобством использования и безопасностью.
2 лайка
Да, вы всё верно поняли. Если WordPress выступает провайдером единого входа (SSO), то задача разрешить пользователям комментировать темы на Discourse не так уж сложна. Основная сложность, учитывая текущее состояние плагина WP Discourse, заключается в том, как отображать комментарии на WordPress — в настоящее время раздел комментариев плагина WP Discourse не дублирует ответы из темы Discourse. Вместо этого отображается подборка «лучших» комментариев.
Возможно обновить плагин WP Discourse для поддержки этого сценария, но для правильной реализации потребуется полностью переписать механизм обработки комментариев Discourse. Это не мое решение, но я считаю, что усилия по улучшению iframe комментариев Discourse были бы более целесообразным использованием времени.
5 лайков
Я просто хотел поддержать идею добавления этой функции.
Было бы здорово, если бы пользователи на WordPress могли просто зарегистрироваться/войти и комментировать посты прямо на сайте WordPress, не переходя на форум, чтобы всё это выглядело как единая система комментариев. Их комментарий появлялся бы как под постом, так и в созданной теме на Discourse. При этом у них всегда будет возможность публиковать комментарии либо в Discourse, либо на WordPress, либо в обоих местах — бесшовно. Я не знаю, как это можно реализовать, но это был бы действительно бесшовный способ интеграции комментариев WordPress с Discourse, который выглядел бы менее громоздко и, несомненно, значительно увеличил бы количество комментариев по сравнению с тем, что мы получаем с помощью текущего плагина.
3 лайка
Возможно, это:
Но, насколько я знаю, это полностью перехватывает вход в Discourse.
Позволит ли это пользователям публиковать комментарии непосредственно под постом в WordPress и автоматически создавать соответствующую тему в Discourse?
Я сейчас работаю над этим. Первая версия предназначена для headless-сайта WordPress, использующего фреймворк Remix для фронтенда. Как только это будет готово, я сделаю версию для обычных сайтов WordPress. Скорее всего, это будет плагин, расширяющий функционал плагина WP Discourse. Я надеюсь, что большая часть того, что я делаю на headless-сайте WordPress, сможет быть перенесена на обычные сайты WordPress, хотя, возможно, потребуются некоторые компромиссы.
Реализовать возможность комментирования напрямую с внешнего сайта несложно. Основное требование — у внешнего сайта должен быть доступ к учётным данным пользователя Discourse. Это можно сделать либо используя внешний сайт в качестве провайдера DiscourseConnect для Discourse, либо настроив Discourse как провайдера DiscourseConnect для внешнего сайта.
Во втором сценарии, когда внешний сайт не является провайдером DiscourseConnect для Discourse, при первой попытке пользователя оставить комментарий с внешнего сайта ему потребуется перейти по ссылке для привязки своей учётной записи на внешнем сайте к учётной записи Discourse (или зарегистрироваться в Discourse, если он ещё этого не сделал). С точки зрения пользователя этот процесс может быть довольно бесшовным.
Однако вышеупомянутое изменение не делает всю систему похожей на обычную систему комментариев. Обычное ожидание от такой системы — возможность читать и взаимодействовать со всеми комментариями. Плагин WP Discourse отображает лишь выборку комментариев, загружаемых из специального маршрута, предоставляемого Discourse. Он не предоставляет функционала для взаимодействия с комментариями.
Сложные части задачи:
- пагинация всех комментариев темы на WordPress, учитывая, что их может быть тысячи;
- создание интерфейса, который даёт пользователю понимание его положения в длинном списке комментариев;
- определение способа отображения комментариев, являющихся прямыми ответами на другие комментарии. (Конвенция Discourse в этом вопросе отличается от того, как большинство систем комментариев обрабатывают ответы.)
- предоставление возможности пользователям отвечать на комментарии, ставить лайки, редактировать свои комментарии и т.д.;
- работа с комментариями, созданными в Discourse, которые могут содержать контент или разметку, которые сложно отобразить или с которыми трудно взаимодействовать на внешнем сайте. Например, oneboxes, опросы…
- предоставление возможности фильтрации комментариев по дате создания (сначала новые, сначала старые), по рейтингу и т.д.
Всё это необходимо реализовать, не создавая чрезмерной нагрузки на сервер внешнего сайта, не выполняя слишком много API-запросов к Discourse и не потребляя слишком много памяти на устройстве пользователя (цель — создать легковесную систему комментариев). Это достижимо, но нельзя просто внедрить это в существующий код плагина WP Discourse без внесения в него существенных изменений.
4 лайка
Хорошо слышать, что вы уже начали это делать!
Всего одна мысль: поскольку часть идеи заключается в том, чтобы снизить трение при привлечении людей к комментариям, возможно, стоит сосредоточиться на бесшовности первого комментария. Как упоминалось выше, многим людям просто хочется иметь возможность комментировать, указав свой адрес электронной почты; тогда проблема заключается в проверке и входе в систему или создании учетной записи (в зависимости, полагаю, от того, как настроен DiscourseConnect).
Как только пользователь окажется «внутри», я бы ожидал, что он с большей вероятностью посетит соответствующую тему форума, чтобы получить весь функционал обсуждений на базе Discourse. Я просто надеюсь, что все эти сложные части проблемы не помешают решению проблемы «первого комментария». Тогда наличие тысяч комментариев, для которых нам нужно будет решить вопрос пагинации, станет «приятной проблемой» 
4 лайка
Для меня этого достаточно, так как и новые, и старые пользователи будут участвовать и взаимодействовать друг с другом. Это не большая проблема для меня как для внешнего наблюдателя.
Да, это действительно серьёзный вопрос. Первый шаг — запустить демонстрационный сайт. Наличие рабочего сайта для тестирования должно сразу выявить все точки трения.
Технически возможно разрешить анонимным пользователям комментировать посты. Единственный нехакерский способ, который я могу придумать, — это чтобы комментарии публиковались от имени анонимного пользователя реальным пользователем. Хотя это кажется немного странным.
Я знаю, что в WordPress есть настройка, позволяющая «гостевым» пользователям создавать комментарии. У этого есть ограничение: комментарий «гостя» не будет связан с реальным пользователем, если пользователь, создавший гостевой комментарий, зарегистрируется на сайте уже после создания комментария. Публикация «от имени» пользователя должна работать аналогично — не будет способа узнать, что пользователь, создавший анонимный комментарий, является владельцем указанного им адреса электронной почты.
В идеале пользователи должны проходить аутентификацию либо на внешнем сайте, либо в Discourse перед созданием комментария.
С точки зрения пользователя наименьшее трение возникает в случае, когда внешний сайт выступает провайдером единого входа (SSO) для Discourse. Это позволит им комментировать темы в Discourse, никогда не посещая сам сайт Discourse.
С точки зрения владельца сайта технически самый простой способ аутентификации пользователей — это использование Discourse в качестве провайдера аутентификации для внешнего сайта. Именно такую конфигурацию я сейчас использую на своём локальном тестовом сайте. Внешний сайт (Remix) даже не имеет таблицы пользователей. Он просто создаёт сессию пользователя на основе ответа от маршрута Discourse /session/sso_provider.
Недостаток использования Discourse в качестве провайдера аутентификации для внешнего сайта заключается в том, что это заставляет пользователей проходить процесс регистрации/входа в Discourse. В самом процессе нет ничего плохого, кроме того, что он, похоже, вынуждает пользователей загружать все ресурсы Discourse, даже если они просто хотят оставить комментарий на внешнем сайте. Поэтому это довольно медленно. Я изучу этот вопрос подробнее…
Да, было бы Возможно, стоит сократить это число до сотен для более реалистичного сценария. Суть моей мысли в том, что проблема становится сложной, как только вы выходите за пределы одной страницы постов (20 постов).
Редактирование: возможно, использовать приглашения Discourse для упрощения процесса — если анонимный пользователь захочет прокомментировать пост, вместе с формой комментария будет отображаться поле для ввода адреса электронной почты. Отправка комментария вызовет отправку приглашения на этот адрес через Discourse. Комментарий будет находиться в очереди до тех пор, пока приглашение не будет принято. Это позволит пользователям создавать комментарий, когда у них появится вдохновение, и сразу получать обратную связь о статусе их комментария.
4 лайка
С нетерпением жду, какое решение предложит @simon.
Хотел лишь отметить, что альтернативное решение, которое развивается в другом направлении, — это использование ActivityPub. В последнем выпуске официальный плагин WordPress для ActivityPub добавил поддержку плагина Discourse ActivityPub.
Это означает, что если у вас установлены плагин WordPress ActivityPub и плагин Discourse ActivityPub, вам нужно лишь настроить категорию для «подписки» на аккаунт WordPress, публикующий посты (или на весь сайт WordPress), и ваши посты из WordPress будут появляться как новые темы в этой категории Discourse.
(обратите внимание, что плагин WordPress имеет задержку публикации, поэтому в видео пост появляется в Discourse через минуту; перейдите к 1:40, чтобы увидеть момент появления).
Плагин WordPress ActivityPub также поддерживает приём активности и уже настроен на обработку входящих активностей в ответ на пост как «комментарий» к этому посту. Однако эта конкретная часть пока не работает с активностями, отправляемыми плагином Discourse (по-видимому, плагин WordPress пока не поддерживает объявленные заметки). Но это тоже должно заработать в ближайшее время.
Подробнее:
6 лайков
Обратите внимание, что Матиас, разработчик плагина WordPress, уже добился этого. Вскоре должна появиться поддержка обмена публикациями и нативного двустороннего комментирования между Discourse и WordPress (через ActivityPub).
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 лайка
Эта тема началась с идеи, что система комментариев на базе Discourse могла бы обеспечить функциональность, аналогичную Coral, с дополнительным преимуществом возможности ветвления комментариев сайта в обычные темы Discourse. Discourse предоставляет возможность модерировать комментарии сайта и позволяет обсуждать их на форуме.
Я считаю, что необходимость модерации не требует доказательств.
Необходимость ветвления комментариев в полноценные темы Discourse может быть не столь очевидной. Я исхожу из предположения, что ведение любых онлайн-разговоров затруднено: в личном общении присутствуют всевозможные тонкие сигналы, которые отсутствуют в интернете. Проводить содержательные онлайн-разговоры с более чем несколькими людьми практически невозможно. Именно здесь на помощь приходит Discourse. Функциональность групп в Discourse позволяет ограничивать круг участников темы. Группы комментаторов могут получать доступ к закрытым темам Discourse. Это своего рода противоположность тому, как работает фидиверс.
Тем не менее, мне интересно, как могла бы работать интеграция Discourse/WordPress с фидиверсом. Например, если Салли комментирует пост Боба в WordPress, что должно произойти с её комментарием, если у неё есть аккаунт в Discourse? Что может произойти с её комментарием, если у неё нет аккаунта в Discourse? Есть ли способ, чтобы Салли могла отказаться от публикации своего комментария в фидиверсе?
Отклоняясь от темы, но учитывая различные законопроекты об онлайн-вреде, которые внедряются или предлагаются в западных странах: если комментарий Салли будет признан оскорбительным, кто несёт ответственность за его публикацию? Я предполагаю, что на этот вопрос пока невозможно дать ответ.
3 лайка
Интересно!
Я бы предложил рассматривать работу ActivityPub в контексте модерации, группировки (и других аспектов онлайн-общения) следующим образом: это прежде всего стандарт коммуникации. Он предоставляет некоторые механизмы для решения этих вопросов, но в значительной степени оставляет их на усмотрение различных клиентов в системе.
Email как стандарт коммуникации — несовершенная, но, возможно, полезная аналогия. «Email» — это набор стандартов коммуникации, позволяющий обмениваться сообщениями с кем угодно в интернете. У него есть различные проблемы с «контролем качества», например, спам. В наборе стандартов, который мы называем «email», есть некоторые аспекты, помогающие справляться с этими проблемами (например, DMARC, DKIM, SPF и т. д.), однако, возможно, основной способ решения вопросов контроля качества заключается в самих почтовых клиентах. Gmail стал популярным почтовым клиентом отчасти потому, что он, по мнению многих, довольно эффективно справлялся со спамом (и аналогичными проблемами контроля качества).
Продолжая эту аналогию, Discourse можно считать «Gmail» для ActivityPub. Все инструменты модерации, группировки пользователей и другие функции, делающие Discourse отличной платформой для обсуждений, (почти) полностью доступны в контексте ActivityPub. Я раскрою эту тему, начав отвечать на ваши вопросы.
Сначала я опишу, что происходит, а затем, возможно, перейдём к более тонким вопросам. Я пропущу многие детали, сосредоточившись на ответе на основные вопросы:
-
Комментарий Салли публикуется как объект ActivityPub из WordPress.
-
Объект импортируется в Discourse и преобразуется в пост.
-
Если «Актив» Салли связан с учётной записью пользователя в Discourse, пост будет связан с этой учётной записью. Если её Актив ещё не связан с учётной записью пользователя, будет создана временная учётная запись на основе Актива Салли, и она станет владельцем поста.
Вы можете увидеть это в действии в этой теме:
-
Категория Discourse WordPress - SocialHub подписана на WordPress Маттиаса.
-
Маттиас опубликовал новую статью в своём блоге, используя свою обычную учётную запись WordPress.
-
Это появилось в Discourse как новая тема, где пост был связан с временной учётной записью, соответствующей Активу Маттиаса.
-
Работа комментариев происходит точно так же.
Просто чтобы ответить на, возможно, самый очевидный вопрос: может ли Маттиас объединить «временную» учётную запись, созданную на основе его Актива WordPress, со своей обычной учётной записью в Discourse на этом сервере?
Краткий ответ: плагин Discourse имеет набор функций «Авторизация», который в настоящее время позволяет вам заявить права на владение Активами с других серверов Discourse или серверов Mastodon, что объединяет любые такие временные учётные записи с вашей учётной записью (что означает, что теперь вы владеете постами в своей основной учётной записи Discourse). Этот набор функций может быть расширен для поддержки WordPress. Я понимаю, что это немного многословно, и, возможно, будет проще понять, что я имею в виду, благодаря этому демонстрационному видео:
Более долгосрочный ответ заключается в том, что в будущем в активности ActivityPub могут быть встроены доказательства идентификации, что, возможно, устранит необходимость в авторизации со стороны пользователя, и тогда «объединение» может стать (более) автоматическим.
Возможно, ещё один вопрос: необходимо ли вообще «объединение», учитывая, что Маттиас всё ещё контролирует атрибуты идентификации своей временной учётной записи через свой Актив ActivityPub (который можно редактировать в WordPress, а изменения автоматически применяются к временной учётной записи в Discourse).
Я говорю всё это как вступление, чтобы мы могли перейти к вашим более тонким и важным вопросам. Надеюсь, я пока излагаю мысли понятно.
2 лайка
Всё понятно.
Что касается вопроса модерации, я имею в виду использование Discourse для модерации комментариев WordPress. Именно эта функциональность позволит использовать Discourse аналогично Coral. Это легко реализовать, если комментарии WordPress на самом деле являются комментариями Discourse, которые публикуются из WordPress в Discourse через API. Это работает из коробки. Это позволяет, например, использовать любые инструменты модерации на базе ИИ, предоставляемые Discourse. Мне интересно, можно ли добиться чего-то подобного с помощью интеграции WordPress/Discourse через ActivityPub.
Какие доказательства личности требуются для временной учётной записи? Передаётся ли их адрес электронной почты с исходного сервера?
Что касается моего (личного) опасения нежелания публиковать контент во всём фидиферсе, то технически возможно настроить двустороннюю связь ActivityPub между сайтом Discourse и сайтом WordPress, но мне кажется, что это противоречит самой сути протокола ActivityPub.
Редактирование: стоит добавить, что цель — создать взаимовыгодные отношения между веб-сайтом и связанным с ним форумом Discourse. Инструменты модерации Discourse призваны обеспечить уверенность в том, что система комментариев веб-сайта хорошо контролируется. Секция комментариев веб-сайта предназначена для того, чтобы создавать темы и пользователей на сайте Discourse.
2 лайка
Пост, преобразованный из объекта ActivityPub, проходит почти те же функции предварительной и последующей обработки, что и пост, созданный через API. Точка входа отличается (то есть контроллер ActivityPub вместо контроллера постов), но способ создания постов в основном одинаков.
*Более технически: если вы создаете пост через API, фактическая обработка выполняется через NewPostManager, который затем передает большую часть работы в PostCreator. Основную задачу, которую решает NewPostManager (в нашем контексте), — это очередь проверки. Всё остальное обрабатывается в PostCreator.
В настоящее время плагин ActivityPub пропускает NewPostManager и передает работу в PostCreator через собственный PostHandler (плагина). Я сделал это в основном для снижения сложности при первоначальной реализации. Нет никаких фундаментальных причин, по которым PostHandler плагина не мог бы передавать пост в NewPostManager и получать преимущества проверок очереди.
Короче говоря, между постами, созданными через плагин ActivityPub, и постами, созданными через обычный API, нет существенной разницы.
Здесь есть несколько уровней.
-
Во-первых, POST-запрос от источника на ваш сервер подписывается с использованием HTTP-подписей, чтобы гарантировать, что запрос действительно исходит от источника.
-
Во-вторых, каждый Актор (то есть пользователь) на этом источнике имеет UUID, то есть идентификатор, привязанный к его домену и уникальный во всем федеративном пространстве. Он выглядит примерно так:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619dВ ActivityPub адреса электронной почты не используются.
-
Каждое Действие (например, создание объекта, похожего на пост), которое вы получаете, связано с идентификатором Актора. И каждый идентификатор Актора может быть разрешен до атрибутов Актора.
-
Таким образом, к моменту получения «Действия» (например, создания нового объекта, похожего на пост) на вашем сервере вы знаете, исходя из домена, от которого пришло действие, атрибуты Актора, выполняющего это действие. Здесь вы доверяете отправляющему домену, но это всегда так: например, Discourse доверяет экземплярам WordPress с плагином WP Discourse, чтобы они отправляли правильные атрибуты пользователей.
Поэтому сам временный пользователь не нуждается в подтверждении личности как таковом, так же как временный пользователь из электронной почты не нуждается в подтверждении личности.
Необходимость в подтверждении личности возникает, когда реальный человек, связанный с актором ActivityPub, и другой аккаунт Discourse (как в примере с Матиасом выше) хотят консолидировать (или «примирить») свою личность. Им может не нравиться, что у них фактически есть два «пользователя» в одном Discourse. Я отмечу, что без такого примирения они могут контролировать:
- Атрибуты личности Актора ActivityPub / временного пользователя через исходный домен (например, обновляя свой профиль WordPress, эти обновления федеративно распространяются, и Discourse применяет их);
- Контент, связанный с актором ActivityPub / временным пользователем, через исходный домен (например, редактируя свой комментарий в WordPress, отправляется действие Update, которое затем обрабатывается Discourse).
Тем не менее, им может казаться «неаккуратным» иметь фактически двух пользователей в Discourse. Именно поэтому плагин имеет набор функций «Авторизация», позволяющий показать, что ваш обычный пользователь Discourse связан с актором ActivityPub и его временным пользователем. В настоящее время это делается с помощью специфичных для платформы механизмов авторизации:
- Для Mastodon это делается через OAuth API Mastodon. Требуется аутентификация вашего аккаунта в Mastodon, чтобы доказать, что вы контролируете соответствующего актора.
- Для Discourse это делается через User API. Это показано в видео в моем предыдущем сообщении.
- Есть несколько способов сделать то же самое для WordPress, например, DiscourseConnect через плагин WP Discourse. Это еще не реализовано.
Как только вы докажете, что владеете актором, связанным с временным пользователем, временный пользователь объединяется с вашим обычным пользователем, его посты становятся вашими, и любые новые действия, связанные с этим актором, автоматически становятся вашими. Однако этот набор функций больше направлен на улучшение пользовательского опыта и строго говоря не является необходимым. Реальный человек, стоящий за этими различными пользователями, контролирует как атрибуты пользователя, так и его контент с самого начала.
Да, возможно направить цель исходящих публикаций и ограничить источник входящих публикаций. Противоречит ли это цели ActivityPub — вопрос дискуссионный. Строго говоря, ActivityPub — это просто стандарт. Я считаю, что нет причин, по которым вы не можете использовать стандарт таким образом. Исторически ActivityPub ассоциировался с децентрализованными социальными сетями, особенно с Mastodon, что, возможно, и вызывает у вас ощущение, что такой подход противоречит цели ActivityPub. Но я бы провел различие между самим стандартом ActivityPub и его существующими реализациями.
Более того, в данном контексте я отмечу, что, как и в случае с электронной почтой, то, что мы называем «ActivityPub», на самом деле представляет собой набор стандартов. Документ стандарта под названием «ActivityPub» должен читаться вместе с другим документом стандарта под названием «ActivityStreams», который описывает основные объекты, участвующие в процессе. Стандарт ActivityStreams более твердо «нейтрален к сервисам», чем сам ActivityPub (то есть меньше привязан к децентрализованным социальным сетям).
Чтобы использовать другую аналогию: блокчейн как технология — это просто децентрализованный реестр; когда мне впервые объяснили его, он напомнил мне систему регистрации земель Торренса, изобретенную в XIX веке (в Австралии) по essentially тем же причинам, по которым был изобретен блокчейн (то есть для предотвращения мошенничества в сделках с недвижимостью). Но самой популярной реализацией блокчейна является Bitcoin, который имеет (другое) конкретное применение и определенные культурные коннотации. Аналогия не идеальна, но один из способов взглянуть на это: Mastodon и децентрализованные социальные сети для ActivityPub то же, что Bitcoin для блокчейна.
Действительно, одна из причин, по которой я помог создать новую рабочую группу W3C по ActivityPub для форумов вместе с NodeBB, Flarum и другими, — попытаться сместить фокус интеграции ActivityPub с существующих реализаций (например, Mastodon) на проблемы форумов, такие как те, которые вы поднимаете в контексте модерации. У нас на самом деле следующее собрание сегодня. Если у вас есть время, я был бы рад видеть там коллегу «Discourser» (это вообще термин?)
4 лайка
Я говорю об использовании инструментов модерации Discourse для модерации комментариев, которые появляются на WordPress. Технически это можно реализовать с помощью запроса к API Discourse или веб-хука — после выполнения действия модерации в Discourse можно отправить запрос для изменения статуса комментария на WordPress.
Предполагая, что будет изменено поведение так, чтобы посты ActivityPub обрабатывались через очередь проверки, всё равно останется проблема задержки между моментом первоначальной публикации комментария на WordPress и его появлением в Discourse. Насколько я знаю, это несколько минут?
В данном конкретном случае одним из основных преимуществ является «использование Discourse для модерации комментариев вашего сайта». Далее перечисляются возможности модерации Discourse: система уровней доверия, очередь проверки, инструменты модерации на базе ИИ и т. д. Эти инструменты были бы полезны для небольших блогов, но обязательны для крупных новостных сайтов. Я думаю, что лучший способ реализовать это — использовать Discourse как единственный источник истины для комментариев, вместо того чтобы комментарии хранились в двух (или более) базах данных.
Это замечательно! Не имея возможности уделить этому больше времени, я не думаю, что смогу быть хорошим представителем Discourse.
У меня есть некоторые общие опасения по поводу идеи рассматривать темы, сообщения и пользователей просто как данные. Необходимо обеспечить способ сохранения контекста того, где происходит обсуждение.
С более практической точки зрения, протокол ActivityPub получил распространение до введения законов об онлайн-вреде, которые принимаются в различных странах. Необходимо гарантировать, что серверы, потребляющие данные с исходного узла, будут уважать запросы на удаление. В противном случае пользователи, создающие контент на исходном сервере, рискуют столкнуться с юридическими последствиями, если их контент позже будет признан вредным в их стране.
3 лайка