なるほど。
かなりイライラしますね。
ActivityPubの登場をきっかけに、友人たちがDiscourseから離れていきました。
なのに、今また彼らがDiscourseを非難し始めています…
それに、ActivityPubの公式フォーラムがDiscourseに移行したので、今度はどうすべきか議論しなければならないなんて…
なるほど。
かなりイライラしますね。
ActivityPubの登場をきっかけに、友人たちがDiscourseから離れていきました。
なのに、今また彼らがDiscourseを非難し始めています…
それに、ActivityPubの公式フォーラムがDiscourseに移行したので、今度はどうすべきか議論しなければならないなんて…
Lemmyの開発者たちは、ActivityPubをコミュニティソフトウェアで利用可能にするという点で素晴らしい仕事をしています:
https://github.com/LemmyNet/lemmy-docs/blob/main/src/en/federation/overview.md
ただし、彼らはこれを拡張する必要があったため、彼らのアクティビティを実装している他のソフトウェアはありません。
私たちのフェデレーション実装はすでに機能面で完成していますが、これまでのところActivityPub仕様に準拠することには全く焦点を当てていません。そのため、Lemmyは有効なアクティビティの送受信を期待する実装とは互換性がない可能性が高いです。
LemmyがMastodonと互換性を持つようにできれば、Lemmyが使用する同じAPIを実装し、以下のようにマッピングできます。
| Discourse | LemmyのActivityPub |
|---|---|
| Category | Community |
| Watching | Follow |
| Topic | Post |
| Post | Comment |
| Like | Like |
ActivityPub の用語では、これは「Page」となります。Page 公開機能を考慮すると、この解釈は非常に理にかなっています。まず最初の部分が Page としてアナウンスされ、その後のすべての返信が Note として扱われます。
Category から Community への対応については確信が持てません。AP サポートと SSO により、これがより流動的になっているためです。私は単一のコミュニティに対して複数の Discourse インスタンスを持つことがよくあります。
余談ですが、以下の Discourse インスタンスがユーザーとトピックの両方を共有し始めました。Discourse での ActivityPub の実装は、私たち全員にとって非常に有用でしょう:
https://love.public.cat/t/what-is-at-stake-with-interoperability/96
興味深いですね。イベント企画のために ActivityPub を採用している Mobilizon にも注目すべきです。これは Framasoft が開発しており、Peertube を作っているのと同じ人々です。
Discourse が ActivityPub の実装に向けて動いていないのは残念です。すでに Discourse を利用しているコミュニティが数多くあり、それらのコミュニティは導入初日から恩恵を受けられるはずですが、その潜在能力が十分に活かされていないと感じています。彼らはまだそのことに気づいていないかもしれませんね!![]()
こんにちは @rishabh、@riking、@codinghorror さん、
(はい、下に TL;DR があります)
以前、@sl007 と @hellekin から、NGI0 の資金があっても、このフェーズ 1 は短期的には進められないと聞きました。ActivityPub に基づく相互運用性を推進する仲間として、私ももちろん残念に思います。しかし、Discourse という業界をリードし最も人気のあるフォーラムソフトウェアの視点から見れば、考慮すべき多くの力や優先事項があり、その文脈でのこのビジネス上の判断はおそらく非常に理にかなっています:
決定: 提案されたこの RFC は、優先順位付けされロードマップに載せるには魅力的ではなかった。
この RFC は、@Falco が提案した「まず、フォーラム間での Facebook 風の集約コンテンツフィードを作成することから始めよう」という MVP(最低限機能製品)アプローチを採用していました。これは、何らかの形でネイティブな ActivityPub サポートを実装することで得られる可能性のある、数多くの機能のうちの 1 つに過ぎません。おそらく、そのようなタイムラインは、通常フォーラムで見られるものから少し外れたものであり、私にとっては真のコア機能には見えません。どちらかと言えば追加機能であり、したがって「あれば良い」機能です。
ActivityPub サポートの MVP を素早く完成させる必要性を一旦脇に置けば、逆に進めるプロセスを採用できるかもしれません:
アイデア創出: 相互運用性のユースケースをブレインストーミングし、ビジネス上の利益と独自の売り(USP)という観点から実現可能性を評価する。
つまり、Discourse にあれば本当に魅力的になる機能は何か?あるいはもっと言うと、何が可能かという点で情報が入ってこない場合、Discourse は機会を逃してしまう可能性はどこにあるのか?
上記の @Falco の 最新の投稿 では、彼自身のビジネスドメインに合わせた専用リンクトデータ語彙を基盤としてゼロから構築された Lemmy について言及しています。彼らは MVP を完成させ、既に本番環境で運用しており、現在は自らのドメインに基づいて機能セットの拡張を検討しています。これには、Mastodon や Pleroma などが非常に成功しているマイクロブログという「別のドメイン」とのフェデレーションが含まれるかもしれません。
アイデア創出のアプローチは、この演習に沿ったものになるでしょう:
演習: Discourse が最初から独自の ActivityPub ベースのビジネスドメイン(リンクトデータ語彙として定義)に基づいて構築されていたとしたら、どのような姿になっていたかを想像してみましょう。
このブレインストーミングセッションでは自由に飛び回り、創造性を存分に発揮しましょう。
これらから導き出されるユースケースのリストが、ビジネス的な観点から十分に魅力的であればロードマップの一部となるかもしれませんが、そうでなくても、コミュニティがプラグインやコンポーネントを構築し、後の段階で土台を築くための刺激となるでしょう。
アプリケーションに ActivityPub サポートを持たせることの意味について、広範な誤解があることに気づきます。多くの人は、それを行う理由が「フェデビジアの一部になること」だと思っています。そして、ここで考えは即座に Mastodon インスタンスとのフェデレーション、つまりフェデレーテッド・マイクロブログドメインとの相互運用性の実装(参加)へと向かいます。
はい、ActivityPub サポートを持てばこれは非常に魅力的な機会であり、PixelFed(Instagram 代替)、PeerTube(YouTube 代替)、そして Lemmy(Reddit 代替)など、多くの他のアプリケーションもこれを目指しています。これらはフェデビジアを参加する価値のある場所にし、多くのイノベーションが形になり、フェデビジアの未来を本当にエキサイティングなものにしています。
しかし…
大規模なユーザーベースをターゲットとする Discourse のような組織は、以下のような質問をするかもしれません。「なぜわずか 400 万人ほどのユーザーがいるフェデビジアと統合したいのか?」「なぜ全く異なるドメインで動作するソフトウェアにマイクロブログを統合するのか?」。そして、その前提で ActivityPub の実装を見送ることは、彼らが正しく主張していることになります。
しかし…
ActivityPub の実装は、(マイクロブログ部分の)フェデビジアの一部になることだけではありません。独自のビジネスドメインに特化したリンクトデータ語彙を実装し、自社の製品インスタンス同士をフェデレーションさせることは、非常に理にかなっています。あるいは、業界内の競合他社が同じ語彙を採用している場合、自社の製品インスタンスとそれら競合のインスタンス同士をフェデレーションさせることも同様です。
その一例が、コードフォージ(GitHub、GitLab、Gitea、SourceHut など)が実装するための相互運用性標準を定義することを目的とした ForgeFed プロジェクトです。これを行うことは、特に GitHub(中央集権的で、次第に壁のある庭園のようなプラットフォーム化している)に対する魅力的な代替案を提供したい小規模なコードフォージプロジェクトにとって、極めて合理的です。広く採用されれば、開発者はもう、インターネット上の散らばったサーバーにある多数のフォージアカウントをやり取りして、興味深いコードプロジェクトに参加したり、Issue を立てたり、コメントしたり、PR を提出したりする必要はなくなります。
(前述のように、至る所に存在するスタンドアロンのコードフォージに対する人々の問題と同じ問題が、私や他の人々が多数の Discourse コミュニティに参加する際にも経験していることに注意してください。)
機会: Discourse は、フォーラムソフトウェアの相互運用性標準を策定し、現在の Discourse の機能セットと完全に整合する形でその標準を形成する上で、他にない立場にあります。
業界には、革新的で新しいアプローチを取り、新機能の追加を迅速に反復する台頭する競合他社がいくつかあります(Discourse の皆さんは、それが誰か最もよくご存知でしょう
)。私の見解では、機能の完成度において Discourse は、それらの製品が提供するものよりもはるかに優れています。また、製品を進化させるのを助けるコミュニティも他にはありません。
しかし、現在存在する相互運用性の機会が、脅威になる可能性もあります。競合他社が先にその機会を掴むか、あるいは EU のデジタル市場法に駆動されてビッグテックのプラットフォームがフォーラムソフトウェアドメインと重複する何かを創り出すかもしれません。どちらの場合も、Discourse がこの標準に整合し、その仕様設計において最も権威ある発言権を持つことは、より困難になるでしょう。
これは意図していたよりも長い投稿になってしまいました。申し訳ありません ![]()
要約すると、現在の ActivityPub サポートに関する立場を踏まえ、短期的な MVP 的な焦点から、長期的な USP やポジショニングという観点で ActivityPub 相互運用性が Discourse に何をもたらすかについてのより広範な評価へと移ることが賢明であるとの主張です。つまり、アイデア創出フェーズから始めて、ActivityPub 採用のビジネスケースを詳細に検討することです。
(これがどのように最善に設定されるかについては、興味があれば中身を任せますが、単に新しい AP トピックを作成し、その上に収集されたユースケースのサマリー wiki を置き、スレッド内でユースケースのアイデアについて議論することから始めることもできるかもしれません)
アーノルド、資金調達にアクセスできるなら、なぜこれをプラグインとして発注しないのですか?
機能を開発し、プラグインで実証することは、より広範な採用やコア機能への統合を促進するのに役立つことがあります。
良い例として「トピック一覧プレビュー」(プラグイン)があります。サムネイルプレビューは当初、完全に後付けで実装されていました。しかし、その人気が証明された結果、Discourseのコア機能としてネイティブにサムネイルをサポートするようになりました。
@angus と私は、そのアイデアが成熟し、十分に人気があると考えられるまで開発を進め、その結果としてコアチーム自身が実装することを決定しました。
このようなアプローチはリスクを低減し、コアのロードマップに組み込む前に実用的な課題を克服する助けになります。
単なる提案ですが…
マーケットプレイスにはすでに資金調達に関する提案があり、Discourse チームの誰かが取り上げていましたが、その後、採用された提案は却下されました。このオファーは現在も有効ですが、ヨーロッパの法人が引き受ける必要があります。The Pavilion のヨーロッパメンバーがそれを行う可能性があります。既存の提案を流用することで、資金調達の迅速化に確実につながるため、提案の作成をお手伝いできることを嬉しく思います。
オフラインで、その対応方法をどうするかについて話し合うことはもちろん可能です。
あなたの Dansup へのリンクは、ここ数年で利用可能になっている WordPress の ActivityPub プラグインを思い出させます。この人と同様に、私はこれらのプラグインがリリースされて以来、自身の WordPress で運用しています:ActivityPub プラグイン と、現在はあまり更新されていない Pterotype です。
あなたのサイトは、@latest@meta.discourse.org のようなフェデレーション上の「アクター」に変換されます。アカウントの説明を追加でき、サイトのアイコンがフェデレーションされたユーザーのプロフィール写真として表示されます。投稿は他のユーザー向けにフェデレーションされ、彼らのコメントは当サイトに表示され、そのフェデレーションされたユーザーのアイコンと名前と共に表示されます。
返信例:
@doug@mastodoon.social:
このフェデレーションに関するスレッドを追うのが本当に楽しいです!素晴らしい仕事を続けてください
これは非常に優れており、WordPress 上では単なる別のコメントとして表示される一方で、ActivityPub を通じた真のフェデレーションされたコメントとしても機能します。
追記:Prismo をチェックしてみてください。これは Ruby / PostgreSQL を基盤とした、Lemmy/Reddit のフェデレーション版であり、Discourse の設計とより密接に合致する可能性があります。
@merefield さん、こんにちは。
プラグインの開発は確かに非常に現実的な選択肢です。私の検討では、現在の製品やエコシステムにおいて「現時点で可能/実現可能/非現実的」であるかに一時的に目を向けず、オープンマインドで「すべての」可能性を探る手段として、フェデレーションを念頭にゼロから Discourse が構築された「かのように」考えることを提案しました。私たちが導き出した各アイデアは、プラグインとして実装するのに完全に適しているかもしれません。
私は現在、この Fediverse のさまざまな側面について主に取り組んでいます。私の回答は、Discourse の熱烈なファンかつ推進者であると同時に、Fediverse の擁護者としての立場からのものです。Fediverse は、あらゆる革新を備えながら、次世代で人々主導かつより人間らしいソーシャルメディアの風景となる「その」機会だと考えています。
しかし、上記の投稿では、Fediverse 統合とは完全に独立した相互運用性のユースケース、つまり異なる Discourse コミュニティ間での直接的な連携についても言及したかったのです。追記:この ActivityPub サポートの側面に対する認識を高めるため、SocialHub フォーラムでもフォローアップを行いました。Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP - Fediverse Futures - SocialHub
ありがとうございます。大変感謝しています。素晴らしいご意見です。このスレッドが、プラグイン開発者の方々に可能性を発見するきっかけとなることを願っています。
![]()
はい、素晴らしいですね。これらのプロジェクトは、Fediverse サポートに焦点を当てた場合、@merefield さんがおっしゃるような Discourse のあり方にとって、優れたインスピレーションとなるでしょう。
過去に、Discourse 間のフェデレーションには全く興味がないという結論に至っています。すでに OpenGraph を通じた基本的な相互運用性が存在し、それで十分であると考えています。もし説得力のあるユースケースがあればお聞きしたいのですが、これまで提示された例はありません。技術的な可能性についてのみ語られており、この技術が実際にどのような製品機能を可能にするかについては触れられていません。
良い指摘ですね!あるフォーラムの投稿を別の Discourse フォーラムの投稿と同期させることが目的であれば、すでに matterbabble を matterbridge と組み合わせて使用できます。
いいえ、その通りです。私が提案したのはまさにそれでした(私の TL;DR で「ActivityPub 導入のビジネスケースを、アイデア創出フェーズから始めて詳細化する」と記載した部分です)。
このブレインストーミングの提案は、このスレッドのトピックを大きく超えており、単一の機能や RFC への言及というよりは、むしろ「ビジョン」に関するものであるため、#community カテゴリに別のトピックを作成しました。
ActivityPub の Discourse への実装の意義を @riking さんに納得していただくための出発点となるビジネスユースケースの提案をご覧ください
@merefield さんもその会話に参加しませんか?もちろん、AP がサポートされていればスムーズに進むはずです!
もし誤っていたら申し訳ありませんが、なぜ feed2toot を使って RSS フィードを ActivityPub に変換しないのでしょうか?Mastodon と Pleroma のサポートがあるようです。Discourse はデフォルトでカテゴリやグループ向けに RSS フィードを生成します。また、Hubzilla と Friendica にも RSS サポートが組み込まれています。
それは「一方向」だけにならないでしょうか?Discourse から ActivityPub インスタンスへの「出力」はできても、逆はできないはずです。
@hellekin 失礼ですが、ここでの「ユースケース」があまり見えません。つまり、なぜそれを行うのか、どのようなメリットがあるのか、などです。
スレッドを再読し、Community has no boundary: Discourse-as-a-Fabric - ideation & brainstorm で議論が広がり、再び Shaping Up a Business Use-Case for ActivityPub in Discourse - Fediverse Futures - SocialHub を検討し始めた結果、ここでの理由の詳細について誰も尋ねていなかったことに気づきました。これは私を含む他のActivityPub推進者の見落としだったのでしょう。申し訳ありません。
Discourseが連邦機能についてさらに深く検討することを妨げている要因について、より詳しいご見解をいただけますでしょうか?また、ActivityPubコミュニティがさらに情報やサポートを提供できる興味深い領域はどのようなところでしょうか?