静的サイトのActivityPub実装についての議論

静的サイトのActivityPub実装についての議論

以下https://socialhub.activitypub.rocks/t/static-file-activitypub/2785/20から機械翻訳
ちなみに議論の途中で「静的サイトにActivityPubを実装するよりfediverseアプリにRSSリーダを組み込んだほうが早い」という話がありまっすが、それを言っちゃあおしまいよ。

私は最近ActivityPubを頻繁に研究しており、採用を容易にする方法を見つけようとしています。, 操作する方が安全です。, そして、スケーリングと私が得た結論が得意なのは、静的なファイルに対応できるようにプロトコルを適合させる方法が必要であるということです。.

現在、ActivityPub(マストドンなど)を使用するサービスをホストする場合は、POSTリクエストとURLパラメーターを受け入れて応答できるサーバーを実行する必要があります。. これは一部のユースケースでは問題ありませんが、多くの潜在的な採用者にとって幅広い採用には及ばないでしょう。.

ほとんどの人はサーバーの実行方法を知らず、サーバーを固定する方法を知っている人はさらに少ない人です。. これは、AcivityPubを使用するサービスの潜在的な責任です。. マストドンで発生する最初の主要なCVEは、何千ものサーバーが更新されないため、大きな評判の影響を及ぼします。. Wordpressなどのように、これを何度も繰り返し見てきました。.

既存のサーバーは、何百万ものユーザーやフォロワーに拡張されません。. その量の要求を処理するために必要なスケーリングの量は、処理能力にコストがかかりすぎて、個人または企業がその負担を負うことを可能にすることができません。.

これを発表やニュースに使用したい政府や大企業は、加入者数を維持して拡大するのに苦労するでしょう。. サーバーコンポーネントの複雑さは、停止して利用できない可能性が高いことも意味します。. サーバーに保存されているIDキーも、それらのキーが抽出された場合のなりすましの可能性のために懸念されます。. 企業や政府は、キーの保存方法(オフラインまたはハードウェア)の基準が高くなる可能性があります。.

ActivityPubプロトコルに追加を提案して、100%静的ファイルホスティングをフレンドリーにするにはどうすればよいですか。? インターネットでコンテンツを提供する最も信頼性が高く、最も安く、最速の方法は、静的ファイルを使用することです。ActivityPubは、公開採用の規模に達する場合、そのホスティングオプションをサポートする必要があります。.

これにより、ActivityPubの上に構築されたアプリケーションの一部が変更される可能性がありますが、新しいプロトコルオプションを長期間にわたって採用できます。.

何が可能かを発見していたので、最近このブログ投稿を書きました。. 引き続きビルドしたい場合は、少なくとも受信トレイ用のアクティブなエンドポイントと、フォロワーの受信トレイにメッセージをPOSTする方法を作成する必要があります。.

プロトコルを将来にわたってより持続可能なものにしたいのですが、それをどのように提案できるかに関する情報は見つかりませんでした。.

ActivityPubの全体的な目標は、pubsubモデルを使用してリアルタイムの相互作用をサポートすることです。. それが1日目の基本的な設計目標でした。. Atom、RSS、indiebプロトコル(マイクロフォーマット)など、配布のクロールに依存する他のプロトコルがあります。.

とはいえ、サブスクリプションとパブリッシングを処理するための半集中型の「アグリゲーター」を備えた自己ホスト型静的ファイルの目標も目標の一部でした。. これはMastodonが調査したものではありませんが、静的ファイルホスティングに興味がある場合は、それが私が調べ始める方向です。自己ホスト型の静的コンテンツですが、いいね/フォロー/返信を集計するための信頼できるサービスです。.

Mastodonは、これらの動的URL(受信トレイ、送信トレイ、フォロー中...)を別のサーバーにポイントすることをサポートできます。.

それも私が欲しいものです。. 私は自分でIDファイルをホストしますが、サーバーの実行を気にする人が動的な部分を行います。.

ポイントはパブ/サブなので、もちろん完全に静的になることはできません。.

Governments and large companies that want to use this for announcements and news would have a hard time maintaining and scaling to the number of subscribers. The complexity of the server components also means it is more likely to have outages and be unavailable. Identity keys being stored with servers is also concerning because of the potential of impersonation if those keys are extracted. Companies and governments will likely have higher standards for how their keys are stored (offline or in hardware).

RSSフィードをフォローできるようにしたいのですが、そのための提案があります。 RSSのフォローを許可・発行#15350・マストドン/マストドン・GitHub。 2

私もそうしたいので、RSSフィードアイテムをブーストして返信することができます。.

Mastodonは、これらの動的URL(受信トレイ、送信トレイ、フォロー中...)を別のサーバーにポイントすることをサポートできます。.

そうでないと思う理由。?

デフォルトで機能しますか?? 私は例えばアカウントを持っています. 「mastodon.social」はこれを取ることができます: https://mastodon.social/@Ciantic.json。 2

私のサーバーに保存して持っています。 @ciantic@example.com but still use Mastodon.social as my inbox/outbox/following/UI etc?

デフォルトではサポートしていないと思います。.

別の問題もありますが、Mastodon.socialでその秘密鍵を自分で入手することはできないと思います

最初の目標についての説明をありがとう。. 現在(少なくともMastodonの場合)、ネットワークのリアルタイム部分はWebソケットを介して行われていますが、これはサーバーのオプションの実装です。. ActivityPubの上に構築された他のアプリでそれが必要かどうか、またはそれが将来ますます必要になるかどうかを知っていますか。?

リアルタイムのデータ交換がプロトコルの望ましい目標である場合、それをより静的なファイルフレンドリーにしようとする私の試みは意味がないかもしれません。.

はい、受信トレイを任意のURLにポイントしても、送信トレイ(静的ファイル)を制御できますが、送信トレイアイテムをフォロワーにPOSTする責任もあります。.

投稿に署名できなかったため、ユーザーキーを抽出できないことが最大の問題ですが、私が知る限り、投稿の署名はとにかく検証されないため、サーバーが検証を行うまでは問題になりません。.

フォロワーに何も投稿する必要はありません。.

一部のフォロワーにメッセージを投稿したり、他のフォロワーにメッセージを投稿したりするクライアントもいます。. 1つのインスタンスが、これからサークルと呼ばれる機能を作成しました。. https://qoto.org。 3 それをします。.

すべてのメッセージを送信トレイのみに追加できます。誰かがあなたのプロフィールを表示すると、これらはフェッチされると思いますが、他の人の受信トレイに押し込まれているようには見えません。.

Appleのようにリスナーと実際には相互作用しない企業にとっては、彼らに合うと思います。. 彼らは偽のフォロワーを持ち、送信トレイで公開メッセージをリリースする可能性があります。.

人々はまだメッセージをブーストし、返信し、好きなだけかもしれません。.

マストドンは実際にはそのようには機能しません。. ユーザーが検索され、mastodonが古い投稿をプルしない場合、送信機はフェッチされません(私のブログ投稿を参照)。. 静的ユーザーを検索すると、ユーザーが投稿しても投稿が表示されません。.

これらの要求を処理し、ポストのメタデータをインクリメントするには/ inboxが必要であるため、ブーストと返信も機能しません。

mastodonはメタデータを検証しないため、投稿のブーストと返信の数について嘘をつくことができます(100万人のフォロワーがいる私の投稿を参照してください)。

他の人の投稿をフォローしていなくても、投稿をブースト、返信、表示できます。. 多くのクライアントがそれをサポートしています。. Webクライアントは「元のリンクに古い投稿を表示する」というリンクを表示するだけで、古い投稿を検索バーに配置することでブーストできます。.

私は「カウント」について話しているのではなく、それらが間違っている可能性があることを知っていますが、誰が気にしています。.

公式のクライアントは、古い投稿の表示もサポートできます。これは、彼らが行わないイデオロギー的な決定です。.

APサーバーが2つの変更を駆動して、静的なファイルベースのサイトがFediverseに統合しやすくなるようにしたいと思います。

WebFingerルックアップには、使用してください。 /.well-known/webfinger/acct/domain/username.json before /.well-known/webfinger?resource=acct:username@domain

アクターが受信トレイURLを提供しない場合は、フォローイベントを受信できないため、フォロワーに投稿をプッシュできないと解釈します。. このような場合、フォロワーのAPサーバーは、RSSフィードリーダーなどの定期的なプルに切り替える必要があります。.

これら2つの変更により、HugoやJekyllなどのソフトウェアは、静的ブログ用のActivityPubフィードを簡単に構築できます。. 重要なことに、これらはどちらも機能強化であり、ActivityPub仕様を破る必要はないと思います。. これらが広く採用された後、それらを標準化できます。.

1つ目は、webfinger仕様の違反です。クエリパラメーターを取得して応答する必要があります。 application/jrd+json and a valid JRD as described in the webfinger rfc.

2つ目は技術的に可能ですが、「俳優」(オブジェクトを含む)の定義に関する保証に違反します。 inbox + outbox).

ただし、activitypubは「フィードリーダー」またはシンジケーションプロトコルを意図したものではないことも指摘しておきます。. メッセージ通過プロトコルです。. フィードを公開する場合は、RSSのようなものがこのユースケースにはるかに適しています。.

実際、アクティビティパブサーバーには一般に「定期的なプル」の概念がありません。これを行う必要があるのはアクティビティパブクライアントであり、アクティビティパブフィードリーダークライアントを想像すると、当然、それがRSSフィードリーダーとどのように異なるのか疑問に思う必要があります。.

また、受信トレイがないと、メッセージを受信できないため、アクティビティパブ全体がまったく役に立たないことがわかります。. ポイントは何ですか。?

できることは、同じURLでライブするActivityStreams 2.0ドキュメントを生成することです(コンテンツネゴシエーションを実行できない場合は、.jsonを追加したままにします)。 Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams" as you are required to do for ActivityPub). This would still require you to generate an actor and a webfinger JRD, though. at least the actor can be static (if your consumers don’t check for content-type), and the webfinger can probably be static too if you don’t care to serve multiple actors (again, if your consumers don’t check for content-type).

ただし、専用のサービスでこれを処理することをお勧めします。「静的アクティビティパブ」を求めることは、「静的電子メール」または「静的ウェブメンション」を求めるようなものです。. 基本的に動的な要求に静的に応答することはできません。.

ええ、アクティビティパブサーバーには一般に「定期的なプル」の概念がありません。これを行う必要があるのはアクティビティパブクライアントであり、アクティビティパブフィードリーダークライアントを想像すると、当然、それがRSSフィード領域とどのように異なるのか疑問に思う必要があります。

私の静的なブログをFediverse内で消費できるようにしたい。. つまり、APユーザーは私の投稿を読んだり、プロフィール/バイオを確認したり、返信/いいね!投稿をブーストしたりできるはずです。返信を送信できない場合でも。. これはすべて実装することで達成できることに同意します。 this 2 but that seems like a more complex undertaking than the changes I suggested.

WebFinger仕様では、全世界のWebのすべての静的なWebサイトは除外されています。. したがって、スペック自体に挑戦するのは公平だと思います。. しかし、この特定の変更は、MastodonのようなWebFingerユーザーが下位互換の方法で実装できると思います。.

専任のサービスを利用するように依頼することは理想的ではありません。非技術的なユーザーとして、私のアイデンティティ、評判、聴衆を人質にすることによって権力の乱用につながる仲介者を信頼することを強いられるからです。.

純粋に静的な環境で最小限のActivityPubプレゼンスさえ実装するよりも、fediverseソフトウェアがRSSを消費する方が簡単です。. 前述のように、activitypubは電子メールやウェブメンションのような動的なプロトコルです。. リクエストはプロセスコールで処理する必要があります。.

仲介者を信頼することが口に合わないと思うなら、フェディバースは率直に言って良い考えではありません。. 連盟の全体的な概念は、サービスプロバイダーを信頼することに基づいています。.

私はあなたに次のようなツールを指摘することができるだけです。 GitHub-dariusk / rss-to-activitypub:RSS to ActivityPubコンバーター。. 4 またはガイドのような。 静的サイトにActivityPubを追加します。 1 または。 s3lph作成-静的サイトジェネレーターが実装できるActivityPubの量。? 2

静的コンテンツをActivityPubで利用できるようにすることが主な目的である場合は、データをRSSフィードとして利用できるようにし、RSSリーダーを使用して読ませるだけです。. 多くのActivityPub互換クライアントは、RSSフィードをインポートして、ActivityPub経由で配布できます。.

それを実装する1つの可能な方法は、Hubzillaがそれを実装する方法です。

RSSフィードを見つけます。.

RSSフィードを消費するフィードバースチャネルを作成します。. このチャンネルは公開することも、プライベートにして1人で消費することもできます。.

RSSフィードに新しいコンテンツが含まれるたびに、そのチャネルをフォローする人々は新しい投稿を表示します。. cronジョブはバックグラウンドで定期的に実行され、新しい投稿をチェックします。.

許可のある人は投稿にコメントでき、そのチャンネルまたはスレッドをフォローしている人はコメントを見ることができます。.

静的ファイルは応答できないため、静的ファイルにActivityPubを実装しようとすることは実際には意味がありません。. ただし、既存のテクノロジーでは、RSSフィードをActivityPub対応の会話に変換できるため、データの発信者がfediverseサーバーを実行する必要なく、情報がfediverseに入ることができます。.