Одной из распространённых проблем, с которой сталкиваются многие пользователи Discourse, является невозможность увидеть агрегированную ленту всех интересующих их групп, на которые они подписаны. Не существует простого способа потреблять контент с нескольких экземпляров Discourse в виде единой социальной ленты пользователя. Централизованные платформы, такие как Reddit, обходят это ограничение, предоставляя единый вход для всех сообществ и агрегированную ленту всех сообществ в едином потоке на главной странице reddit.com. Именно эту последнюю функцию мы хотим реализовать в Discourse с помощью протокола ActivityPub.
Например, пользователь А посещает несколько экземпляров Discourse: один для обсуждения политики, два для хобби, один для местного форума района, но не имеет возможности получать весь релевантный контент в единой ленте. В сравнении с этим, если вы вступили в несколько групп Facebook или сабреддитов Reddit, наиболее релевантные посты уже появляются в вашей ленте.
Спецификация (v1)
Мы могли бы создать прототип MVP, реализовав следующие функции через плагин для Discourse:
Генерация ленты ActivityPub по запросу (для каждой страницы, у которой уже есть RSS-лента)
Аналогично добавлению .rss к URL, это позволит получать контент с помощью протокола AP при обращении к соответствующей конечной точке.
Мы даже сможем включить это для приватного контента, добавляя ключи API пользователя к URL.
Предоставить администраторам форумов возможность включать ActivityPub (исходящий) для каждой категории отдельно или оставить включенным по умолчанию? (Полагаю, у @Falco есть по этому поводу мысли)
Найти способ потреблять этот контент на форуме Discourse / в ленте Mastodon (входящий)
Следующие шаги
Нам определенно нужно начинать с малого, поэтому сначала нам необходимо определить небольшой, выполнимый набор функций, которые войдут в первую итерацию. Я изучаю протокол ActivityPub, но пока недостаточно знаком с его внутренним устройством. Поэтому я приглашаю других участников, проявивших большой интерес к этой теме, присоединиться к обсуждению (@Falco, @hellekin, @merefield), чтобы помочь нам разработать выполнимую спецификацию для первой итерации и предложить изменения в приведенную выше спецификацию.
Я бы начал с вопроса: не стоит ли сначала сосредоточиться на том, что нужно сделать, а не на том, как? Архитектура технологии может подождать? Я говорю это потому, что слишком ранний выбор подхода может ограничить функциональность.
Я бы с радостью увидел для версии 1. список «Открытие открытий», начиная со следующего:
Список «Последнее», который показывал бы превью каждого недавнего обсуждения из включённых источников (простое объединение списков «Последнее» из всех источников);
Список «Подписки», который показывал бы превью каждого обсуждения, по которому у вас включены уведомления о активности. (Это решение основано на существующем мобильном приложении — оно расширяет уведомления о новой активности в подписанных обсуждениях до самих превью этих обсуждений).
Честно говоря, исходное предложение с аналогией Facebook мне непонятно: я не имею представления о том, что делает Facebook, и не понимаю, как это связано с Discourse.
Мое понимание поддержки ActivityPub для Discourse заключается в том, что это может помочь федерировать темы или даже делиться категориями между экземплярами Discourse. Например, одна тема с объявлениями на discourse.joinmastodon.org может быть федерирована на socialhub.activitypub.rocks в соответствующей категории #software:mastodon: там локальные пользователи смогут ставить лайки, отвечать, цитировать и т. д., как если бы это была локальная тема, за исключением того, что оригинальная тема будет находиться на экземпляре joinmastodon.
Другой аспект заключается в том, что если у пользователя есть аккаунты на обоих экземплярах, должен быть способ связать эти аккаунты, то есть использовать один конкретный экземпляр Discourse в качестве основного провайдера идентификации. Я понимаю, что это не является фокусом первой итерации, но об этом стоит помнить, так как мы можем в итоге получить функцию «Войти с помощью [вставьте здесь ваше любимое решение на базе ActivityPub]».
Из вышеизложенных предложений я понял, что речь идет о репликации приложения Discourse для Android, где у вас есть список экземпляров, и вы получаете уведомления от всех них. Кажется, немного опасно смешивать нерелевантные ответы из множества источников, особенно когда они теряют контекст.
Правильно ли я понял, и было бы мое понимание хорошим следующим шагом в вашем видении интеграции ActivityPub с Discourse?
Все текущие реализации ActivityPub ожидают, что посты будут публиковаться стабильными акторами, поэтому вам может понадобиться один из следующих вариантов:
Системный аккаунт, публикующий все посты
Один аккаунт на каждую подписываемую ленту
Один аккаунт на каждую подписываемую ленту, который делает Announce постов, которые предположительно написаны аккаунтом каждого пользователя Discourse
Первый вариант, скорее всего, проще всего реализовать; третий лучше всего согласует модели данных.
Также есть выбор: публиковать ли полный контент темы, только первые посты тем или что-то вроде твиттер-лент StackExchange, где создаются отдельные посты, продвигающие посты со страницы /top. Или это может быть просто то, как работает лента «топ-постов», а остальные ленты публикуют всё…
На техническом уровне URL не должен меняться: все серверы будут отправлять Accept: application/activity+json или его альтернативы.
Приложение-читалка, которое смешивает ленты из разных источников в разное время в ActivityPub — воссоздающее «алгоритмическую ленту» как опциональную функцию — это то, чего я хотел уже давно, и, похоже, такого решения сегодня не существует.
@hellekin: Я думаю, что кросс-доменное авторство с высокой вероятностью может фатально обойти многие анти-спам защиты Discourse. Реализация чтения более важна: в конце концов, Чтение — это фундаментально!
Я так не думаю: удалённые пользователи всё ещё могут быть размещены, если они не свяжут свою удалённую учётную запись с локальной — в этом случае анти-спам будет применяться к этой учётной записи.
Я признаюсь, что лишь бегло просмотрел комментарии. Я предлагаю, чтобы каждая категория была отдельным актором (с типом «Группа»). Тогда люди извне смогут просто подписываться на конкретные категории. Публикации в этих категориях можно реализовать, объявляя аккаунт «Группа» автором постов. Таким образом, у нас будут и категория, и автор. Именно так мы работаем в нашем собственном программном обеспечении. При использовании подписей JSON-LD это будет безопасно даже для непубличных категорий.
Вопрос в том, что делать с комментариями от пользователей извне. Я предлагаю, чтобы аккаунты групп были определены как требующие «ручного одобрения». Затем можно добавить процесс валидации для предотвращения случайного спама. Эти проверенные аккаунты смогут комментировать такие посты.
Это позволит людям из (почти) всего фидиверса мгновенно подключаться к системам Discourse и взаимодействовать с ними.
Кроме того, я считаю, что было бы отлично, если бы:
У каждой группы категорий (Category Group) был бы владелец, обладающий полномочиями управлять категорией: контролировать права на публикацию, блокировать или удалять пользователей, настраивать видимость (публичная или приватная) и т. д.
Локальные пользователи могли бы создавать категории на своём экземпляре, при условии утверждения этих категорий сотрудниками экземпляра.
Если владелец категории не справляется со своими обязанностями, сотрудники сайта могли бы сменить его.
Так работают многие централизованные форумы и сообщества. Задача состоит в том, чтобы адаптировать этот подход к федерации.
Тем не менее, всё ещё остаются проблемы:
Должны ли идентификаторы (id) акторов быть изменяемыми? В Discourse возможность изменения имён пользователей может быть включена в настройках сайта. Однако я сомневаюсь, что другое ПО, работающее с ActivityPub, сможет с этим справиться. Is Object's `id` immutable? - ActivityPub - SocialHub
(Ещё будут дополнения)
Кто-нибудь из команды Discourse приедет на SocialHub на OFFDEM на следующей неделе? Это будет отличный момент, чтобы встретиться и пообщаться с другими разработчиками AP.
Несколько быстрых ориентиров:
Friendica и Hubzilla могутпреобразовывать RSS-ленты в учётные записи, совместимые с ActivityPub/Diaspora*/OStatus в федеративной сети.
Также обратите внимание на этот плагин для WordPress, который преобразует публикации в сообщения формата ActivityPub.
@heluecht и @misaka4e21 упомянули поддержку актора Group. В SocialHub идёт обсуждение способов реализации этого функционала более или менее стандартизированным образом.
5 лайков
sl007
(Sebastian Lasse | @sl007@mastodon.social)
14
Поздравляем с получением средств от ЕС!
Есть ли дорожная карта?
Будет ли кто-то из команды Discourse на конференции ActivityPub?
Это был бы отличный повод встретиться и пообщаться с другими разработчиками, реализующими AP. https://conf.activitypub.rocks
Надеемся, что в рамках Birds of a Feather на следующей неделе, в воскресенье, во время APConf2020, мы обсудим реализацию ActivityPub в Discourse. Подробности в отдельной теме на SocialHub:
@rishabh, было бы здорово, если бы вы присоединились, хотя бы к обсуждению в теме, если не сможете присутствовать в воскресенье. Точное время пока неизвестно, но встреча состоится в воскресенье утром. Я обновлю этот пост, как только узнаю подробности.
Извини, что не смог присутствовать. Хочу сообщить, что мы не подавали заявку на финансирование NGI0, и в данный момент никто не занимается этим вопросом. Также я не лучший человек для ведения этого проекта, так как не знаком с протоколом, но я напишу @Falco, чтобы узнать, есть ли у него какие-то мысли или интерес к дальнейшей работе над этим.
Что ж, на тот момент один из членов вашей команды это сделал — даже если он больше не в команде, и вы были выбраны — значит, кто-то должен был это утвердить, так что я не знаю, к какому «мы» вы обращаетесь. В любом случае, я с нетерпением жду обсуждения с @Falco. Какая-то поддержка AP была бы очень полезна для сообщества ActivityPub, особенно учитывая, что это облегчило бы работу между экземплярами Discourse и улучшило бы интеграцию с Fediverse.
Я осознаю проблему борьбы со спамом, но, думаю, её можно смягчить, введя тестовых пользователей Fediverse, подобных незарегистрированным пользователям с электронной почтой, до тех пор, пока они не зарегистрируют локальную учётную запись.
Да, мы подавали заявку на финансирование в прошлом, но ранее в этом году мы обсудили с командой NLnet закрытие проекта и освобождение средств, зарезервированных для нас. Даже если мы тогда были выбраны, сотрудничество с NGI0 отменено на данный момент. Конечно, в будущем мы можем снова выдвигать предложения.
Только что вспомнил, что @riking тоже может быть заинтересован
1 лайк
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
Интересно.
Этот проект получил финансирование через фонд NGI0 Discovery Fund, созданный организацией NLnet при финансовой поддержке программы Европейской комиссии «Следующее поколение интернета» под эгидой Генерального директората по вопросам коммуникационных сетей, контента и технологий в рамках соглашения о гранте № 825322.
Итак: говорят ли они о другом «Discourse»?
Просто спрашиваю из-за «Собственного веб-сайта проекта: https://discourse.org»…
О, я не знал, что такая страница существует. Я напишу письмо нашему контакту в NLnet, напомню им на случай, если они забыли её удалить, и опубликую обновление здесь.
В любом случае, я с нетерпением жду обсуждения с