ActivityPubのクライアントからサーバへの通信(C2S)の話

#1

仕様としては、このあたりになります。
https://www.w3.org/TR/activitypub/#client-to-server-interactions

#2

そろそろMastodonでもC2Sについて再考してもいいんじゃない? っていうissueがあがっていました。

各サーバ実装に対してそれぞれにクライアントソフトの開発・対応が必要な状況より、ActivityPubで接続できる汎用クライアント実装ができた方が、幸せになれるんじゃない?(意訳)というような話です。

これについて、C2Sでは機能が不十分と指摘されています。

また、ある意味でサーバはFediverseのクライアント機能を担っていて、各サーバ実装がクライアントに代わって様々な便益を提供しているので、それに乗っかる方がメリットがあるという見解もあります。

以前SubwayTooterでもC2S実装は可能か検証されていたと思いますが、時期尚早という判断になっていたかと思います。

これについては、どういう機能が不足していて、どう解決可能か、あるいは仕様の拡張や別のプロトコルの支援が必要か、などの個別議論が行われないと、使えないね、で終わりそうだなと思っています。

また、一般的なクライアントアプリのようなものではなく、こういう使われ方ならC2Sが生きるんじゃない? という話も必要かなと思います。

みなさまの見立てはいかがでしょうか?

#3

汎用的なActivityPubクライアントはあってもいいのかなとか思ったりもしますが、
HubzillaとMastodonとPixelFedを同じUIで提供するのはえぇ…ってなりますよねー

#4

a
オイゲンさんのコメントはだいたい妥当。通知ない。検索ない。カスタム絵文字一覧ない。通常の絵文字のバージョンも定義されない。公開TLない。タグTLない。

b
認証まわりがまるっと個別サービス依存。共通の認証方式などはない。

c
リストやオブジェクトから別のオブジェクトへの参照がインラインてはなくuriだけにできるので、たとえばタイムラインやフォローリストを読むのにコレクションを見たら内部のエントリが全てuriだけ書かれてる状態だったりしてHTTPリクエスト回数が膨大になるサービスなどある。クライアント相手の最適化が考慮されてないケースが多々見られる

aのせいで公開TLもタグTLもないので個人からフォローグラフを辿るしかなく、
bのせいで現時点ではビューアー程度しか作れず、
cのせいで特にモバイルで通信量が過大になる。
そんな印象です。

1 Like
#5

認証系とかは共通化できるので、まぁ楽になるかなぁっていうのは思うけど、結局UI周りはプラットフォームごとに変えないとしょうがないしなぁ…
実用に耐えるようになったらTheDeskとは別のプロジェクトで作ってみてもいい

#6

認証がないというか「ログインユーザと投稿者の関係」がないのでブロックやミュートは反映されないし、プライベートな要素がロクにない、公開プロフィールのページを読めるだけのアプリになると思う。
記録の残らないnotestock。ありがたみがない。

#7

C2Sでまともにクライアント実装できるなら最初から個別APIなんて用意しないのでは?

#8

問題は標準化を進める人が不足してる事だから、外人さん頑張れというお気持ち。

でもまあAPプロトコルがモバイル最適化を考慮してくれるとこまではいかないと思うかな。

1 Like
#9

Fediverseに投げたモノとその反応を引っぱってきておきます。

【noellabo】101899453912474249
ActivityPubには、クライアントとサーバで通信する仕様もあるのですが、Mastodonなどのサーバでは採用されていません。

通常は、各サーバの用意しているAPIでアクセスします。

そのへん、再考してもいいんじゃない? どうなの? という話がでていたので、機運にのって話題出しです。

クライアントを開発している人の立場ではどう見えるか、サーバ側としてはどう見えるか、などの意見がいただけるとありがたいです。

【h3poteto】b706cb3b-815f-4a3d-ab88-0345d35dec4e
あったらあったで楽になると思います.現状でもMisskeyほしいとか言われることはあるので.ただ,今でも各SNSでActivityPubに乗ってない機能,APIを作ることはあると思うので,それらはやっぱり独自APIとして残るの?というのは気になります

[noellabo】101899518133258723
クライアントが複数のサーバ実装に対応する際の、汎用アクセス手段として使えそうですよね。機能は限られていても、とりあえず動くことが大事なこともあるし。

サーバ側から見ると、そういうサブセット的なものにはあまり価値を感じないと思いますが、クライアント側からはメリットになるかもしれません。






#10

やっぱり認証が無いと進められないですよね。
notestock作ろうと思ったときも、クライアントとして取りに行けばいいのかって思ったんですが、認証は各アプリに依存するって書かれていて、結局コードを投稿してもらう形式にしました。
しかし、それでも投稿権限のOAuthを持つ人間から登録できてしまうという穴があるので、なんらかの共通した認証機構が欲しくなりますね。

#11

どもです!ほぼほぼ重複ですが

  • ActivityPub対応サーバーに対して共通実装でミニマルな機能だけでも対応された状態にできるとすればそれは嬉しい
  • 現実的には既に議論がなされている通り、C2Sの仕様が不十分で工数削減にもユーザー体験にもメリットが薄い懸念があるように思われる
    という感じでしょうか。

ちなみに個人的に最も先んじてC2Sに(というかMastodonでもですが)欲しいのは、「このサーバーがどの機能に対応し、どの仕様に準拠しているか」という機能セットの定義を取得する方法かなと思ってます。
認証セットはこの仕様、投票には対応、クオートURLには非対応、みたいな情報が簡便に取得できると、クライアントで対応するにせよ非対応を警告するにせよ助かります。
各ドメインでネームスペース切ればオレオレ拡張を宣言することもできるし、夢が広がりそう。

分散型である以上、機能分岐していくことがある種の必然なので、共通化と共に共通化できない箇所を上手く取り扱っていく術を備えていけると良いなという話でした。

2 Likes