ActivityPubプラグイン

プラグイン
,
85

まあ、Mastodonユーザーはタイムラインのコンテキストでそれを見るでしょうし、タイムラインは一般的に制限されています。Mastodonでは、デフォルトで、タイムライン全体が400投稿を超えることはありません。元の投稿を見ている場合、いずれにせよDiscourseを見ていることになります。理論的には正しいとしても、実際には混乱を引き起こすとは思いません。コンテンツを見るにはすでにフォロワーである必要があります。元の投稿へのリンクをたどるとDiscourseに入り、そこで混乱は解消されます。

完璧ではありませんが、「最悪ではない」選択肢でしょうか？

代替案として、元の投稿が所有権の移転によって上書きされたことを注釈する編集をフェデレートアウトすることは可能でしょうか？フォーラムで議論する」リンクを追加するようなものです。

確かに、それが違いではないとは主張しませんが、有用で利用されているDiscourse機能をブロックすることと比較して、許容できる違いのように思えます。

元の投稿を削除すると、アクティビティに関連付けられたアクターを編集で変更できないため（私の理解では）、他のプラットフォームにフェデレートするコンテキストでスレッドが孤立します。

代替案としては、Discourseの投稿が最初にフェデレートされたときから作成者が異なる場合、編集のフェデレーションを一切停止することかもしれません。警告付きで？「オーナーを変更すると、この投稿のフェデレーションが無効になります。本当に続行しますか？」

はい。通常のユーザーにとってDiscourseではそのように見えます。彼らは、鉛筆アイコンをクリックして変更履歴を確認できることや、権限がないことを知らないかもしれません。これらは、私の見解では、通常のDiscourseの使用に組み込まれています。

  • 投稿をウィキにすることは、他のユーザーの編集が通常の利用において自分の名前で表示されることを受け入れるということです。
  • ウィキでなくても、サイトの設定によっては、権限のあるユーザーがDiscourseであなたの投稿を編集できます。

私の視点からは、基盤となるモデルの違いを考慮すると、これは可能な限り近い同等物です。

私の見解では、「元のサイトで投稿を表示するにはクリック」は、このプラグインを無視しても、Fediverseファーストの実装間で既に異なるコンテンツを表示しています。表示されるコメントのセット、マークアップ、記事の処理方法が異なります。したがって、このプラグインを通じていくつかの違いが見られることは驚きではありません。それは避けられないと思います。

（これらのアイデアを思慮深く検討していただき、改めて感謝いたします。これらが難しい境界ケースであることは認識しており、感謝しており、私のアイデアが最善であるとは考えておらず、このフェーズまたはこの作業のいずれかのフェーズに義務感を生み出すつもりはありませんし、私が書いていることに特に応答するつもりもありません。）

「いいね！」 1
86

カテゴリの変更と同様に、シナリオによって大きく異なると考えます。たとえば、次のような状況を考えてみてください。

  1. 投稿1がカテゴリ1でユーザー1（アクター1）によって作成される
  2. 投稿1の著者が2分後にユーザー3（管理者）によってユーザー2（アクター2）に変更される
  3. カテゴリ1は、20のドメインと5つの異なるソフトウェアプラットフォームにまたがる400のアクターによってフォローされており、それぞれがタイムラインとコンテンツ検出の実装にわずかな違いがあります。
  4. 投稿1が作成されてから2分以内に、2つのノートが同一のコンテンツと異なるアクターで、それらの400人のフォロワーに投稿されます。

これは、かなりの数のフォロワーに混乱を引き起こす可能性が高いと思います。さらに、ユーザー2は、自分が書いていない重複コンテンツが20の異なるドメインにまたがって添付されていることに気づいていない可能性さえあります。管理者が単一のインスタンスでそれを行うことには同意するかもしれませんが、特にコンテンツを複製するという不完全な状況で、その暗黙の同意をFediverse全体に拡大することには非常に注意すべきだと思います。投稿の所有者を変更することは、Discourse固有の強力な管理機能であり、暗黙のうちに単一インスタンスの「ソーシャル契約」に関連付けられています。

ウィキの場合はより強力だと思いますが、すでに示唆されている点に再び注目したいと思います。ウィキは通常のDiscourseの使用に組み込まれた概念です。誰かの（スタッフだけでなく）編集を元の著者に結び付けることは、ActivityPubには類似のものがないDiscourseの概念です。標準的なActivityPubの方法を使用して、Fediverse全体にその概念を拡張することには注意が必要です。これらの更新アクティビティは、元のウィキのコンテキストから切り離され、多くの異なるインスタンスやソフトウェアプラットフォーム全体で、他のすべてのアクティビティと同様に扱われます。さらに、すでに示唆されているように、スタッフや非常に信頼されているユーザーが他者の投稿を編集できるという点で、すでに潜在的な問題があります。ウィキの質問に進む前に、より限定的な質問についてさらに検討が必要だと思います。

これらの機能について、DiscourseとActivityPubの二者択一を設けようとしているわけではありません。私が言いたいのは、結果を慎重に検討せずに、機密性の高いDiscourseの機能をFediverseにマッピングしようとすべきではないということです。これらのより機密性の高い機能は、ユーザーやユースケースのかなりの部分を損なったり驚かせたりしないという確信が持てるまで、ActivityPubの投稿ではデフォルトで無効にすべきです。

個人的には、現時点ではどちらも十分ではないと感じていますが、ウィキの場合は、まだ良い解決策が見つかっていませんが、現段階ではより可能性があるという直感があります。

「いいね！」 8
87

これら2つの項目も完了しました。@angusのOAuthによる本人確認のPRをマージしました。バグ修正とパフォーマンス改善を除けば、これによりプラグインに追加された現在の機能フェーズは完了です。

現状、このプラグインは非常に機能が豊富です。主な機能を簡単にまとめると、プラグインは以下をサポートしています。

  • ActivityPubでの「フォロワーのみ」投稿公開（デフォルトは公開）
  • 「最初の投稿」または「トピック全体」の公開（デフォルトは最初の投稿）
  • 「トピック全体」公開時の双方向同期。つまり、トピック内のDiscourseで作成されたすべての投稿はActivityPubに公開され、その逆も同様で、ActivityPubでの返信はDiscourseに投稿される。
  • 短いコンテンツサービス（Mastodonなど）向けの「ノート」または長いコンテンツサービスに適した「記事」として投稿を公開するオプション
  • 本人確認

次に、現在の機能の微調整とユーザビリティの向上に取り組みます。もちろん、フィードバックは引き続き歓迎します。特に、これらすべてが一般ユーザーにどのように機能するかを説明する方法に興味があります。これは簡単なことではありません。

私は@angusと同じ考えです。私たちの目標は、現実的で、適度な労力で達成可能なことを行うことです。そのため、現時点ではDiscourseの機能の一部を削減することを受け入れる用意があります。特定の制限に対処することが重要かどうか（例えば、プラグインユーザーはウィキとActivityPubの制限に頻繁に遭遇するでしょうか？）を判断するための最善の方法です。

「いいね！」 6
88

それでは、制限事項を明確にする段階にあると理解してよろしいでしょうか？

89

こんにちは :slight_smile:

まず、これらすべてを開発してくれてありがとう。

次に、異なるActivityPubサービスを接続することに非常に興味があります。私が読んだ限りでは、これは主にDiscourseからMastodonへのメッセージの送受信に関するものだと思います。

プロトコルはサービスに依存しないことは承知していますが、たとえば、異なるDiscourseインスタンスを接続したり、NextcloudやPeerTubeなどを統合したりするためのドキュメントはありますか？

「いいね！」 1
90

現時点では、ActivityPubトピックでの投稿者名の変更とWikiは無効にしています。これは、私がすでに述べた理由（ActivityPubではデフォルトで想定が機能しない）によるものです。これらは、この方法で一時的に無効にされた唯一の2つの機能です。その他の機能低下については、問題として報告してください。

これはActivityPub仕様に密接に従ったActivityPubプラグインなので、あなたが言及したすべてのサービス（およびその他のサービス）を含む、その仕様に従うあらゆるサービスと連携するように設計されています。Mastodonは、私たちが最初に統合に焦点を当てたActivityPubプラットフォームです。なぜなら、実際的な観点からは、一度に1つのサービスとの互換性を確保する必要があり、Mastodonが最大のActivityPubプラットフォームだからです。

「いいね！」 4
91

https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub で 2 回試しました

image
image783×143 10.8 KB

```json { "errors": ["You are not permitted to view the requested resource."], "error_type": "invalid_access" } ```

どうすればよいですか？

「いいね！」 2
92

@rokejulianlockhart 様、フィードバックありがとうございます。どのような認証フローを実行していますか？ブラウザ（どのブラウザですか？）で上記のスクリーンショットの「承認」をクリックしていますか？それともURLをコピー＆ペーストしていますか？投稿にURLが記載されているため、お尋ねしています。以下は、meta.discourse.orgで標準フローが正常に機能する様子を記録した動画です。

それとは異なることをしていますか？

「いいね！」 2
93

@angus,

  1. image
    image572×128 11.7 KB

    rokejulianlockhart@mastodon.social

  2. image
    image572×128 12.6 KB

  3. image
    image473×263 11.2 KB

    You are about to log in to the site “mastodon.social” with the username “rokejulianlockhart”, but the web site does not require authentication. This may be an attempt to trick you.

    Is “mastodon.social” the site you want to visit?

    Here I click

    Yes

  4. Log in - Mastodon

    image
    image489×495 31 KB

    Authorization required
    meta.discourse.org would like permission to access your account. It is a third-party application. If you do not trust it, then you should not authorize it.
    Review permissions

    Accounts
    Read-only access

    Here I click

    Authorize

  5. Then the previous

    Is “mastodon.social” the site you want to visit?

    prompt appears, and I do the same.

  6. https://meta.discourse.org/ap/auth/oauth/redirect?code=s2H3Og_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE

    1. .JSON

      {"errors":["You are not permitted to view the requested resource."],"error_type":"invalid_access"}

    2. Headers

      X-Firefox-Spdy: h2
content-encoding: gzip
content-type: application/json; charset=utf-8
date: Mon, 25 Sep 2023 11:39:30 GMT
referrer-policy: strict-origin-when-cross-origin
server: nginx
vary: Accept-Encoding
x-content-type-options: nosniff
x-discourse-route: o_auth/redirect
x-discourse-username: rokejulianlockhart
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-request-id: 01276bd6-77ea-42ae-8f60-6fa365a70e1f
x-xss-protection: 0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en;q=0.7,en-US;q=0.3
Connection: keep-alive
Host: meta.discourse.org
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
94

こんにちは。最新のアップデートの後、ユーザープロフィール（/u/user）が壊れているようです。ユーザー名とプロフィール写真が表示され（さらに、ユーザーの攻撃リストが一番上に表示され）ます。

プラグインリストを確認し、問題を解決するまで一つずつ無効にしました。セーフモードを有効にしても問題は解決しました。以下は、クライアントエラーの例です。

Cannot read properties of null (reading 'getBoundingClientRect')
at Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
at e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
at p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
at p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
at h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
at $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
at $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
at $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)

プラグイン有効時の表示（ご自身のプロフィール）はこちらです。

image
image1377×960 11.2 KB

別のユーザー（この場合は9pfs）の場合

image
image1377×960 78.2 KB

プラグインによって引き起こされる別の面白いバグはこちらです。

現在、こちらのコミット の 3.2.0.beta2-dev を実行しており、プラグインのバージョン 0.1.0 を こちらのコミット で実行しています。

「いいね！」 1
95

@rokejulianlockhart クッキーが無効になっているか、何らかのプライバシー拡張機能が実行されていますか？現在、認証フローは安全なセッションクッキーに依存しています。

@aboutDavid レポートありがとうございます。可能性はありますが、あなたが共有していることがこのプラグインの問題によって引き起こされているとは考えにくいです。サイトへのリンクを共有していただけますか？また、テーマやテーマコンポーネントは有効になっていますか？

「いいね！」 2
96

セーフモードでのトラブルシューティングから、以下のことが確実にわかっています。

  1. 非公式プラグインである
  2. テーマやテーマコンポーネントではない

私の知る限り、非公式プラグインは2つあります。

  1. アニメーションアバター（原因ではないことを手動で確認済み）
  2. ActivityPub

サイトリンクについては、

「いいね！」 3
97

アップグレードUIには、その2つ以外のすべてのプラグインの横にチェックマークが表示されています（これらが公式プラグインであることを示しています）。

「いいね！」 2
98

サイトの問題は、おそらく user-profile-avatar-flair プラグインのアウトレットを使用している何かが原因です。このプラグインはそのアウトレットを使用しません。しかし、アニメーションアバタープラグインは使用します。

どのように確認しましたか？

「いいね！」 1
99

@aboutDavid がプラグインにクライアントサイドの JavaScript がないことを確認しました。問題は部分的にサーバーサイドにあるのでしょうか？

「いいね！」 1
100

クライアントサイドのJSがないからといって、クライアントサイドの問題がないとは限りません。この場合、問題はプラグインのアウトレットの使用方法、おそらくテンプレート内で使用されている方法から生じているようです。アニメーションアバタープラグインを削除してみて、結果をお知らせいただけますか？

（ちなみに、アニメーションアバタープラグインにはクライアントサイドのJSがあります。例としてこちらをご覧ください）。

「いいね！」 1
101

Metaでカテゴリを編集したところ（グループアクセス権を変更するため）、activitypub関連の設定は何も変更しませんでしたが、スタッフログにこれらの3つのエントリが記録されました。

image
image1550×362 61.7 KB

技術的にはnilからデフォルト値に変更されたため、実際の動作には変更がないということでしょうか？それでも、混乱を避けるために、このログの削除を避けるべきだと思います。

「いいね！」 2
102

デビッド、レポートありがとうございます。すぐに確認します。

「いいね！」 1
103

やっちまった、今日はちょっとおバカだ、ごめんね

編集：そう、おそらくアニメーションアバターだ、時間の無駄にしてごめんね（笑）

「いいね！」 3
104

@angus、私の知る限りではありません。

image
image1920×9982 424 KB

そして、uBlock Originを無効にしたことを確認しました。プライバシーリストは使用していませんが。

しかし、今日テスト中に別の問題が発生しました。

Log in - Mastodon

クライアント認証は、不明なクライアント、クライアント認証が含まれていない、またはサポートされていない認証方法のために失敗しました。

image
image537×260 15 KB

Google Search.