#556 - fep-044f: Switch from FEP-e232 object links to bespoke `quote` and `quoteAuthorization` attributes - fediverse/fep - Codeberg.org
https://codeberg.org/fediverse/fep/pulls/556

Standards（<https://xkcd.com/927/>）状態（？）

まあ`as:quoteUrl`は論外として、`fedibird:quoteUri`や`misskey:_misskey_quote`との比較としてきちんと`"@type": "@id"`として定義されているという優位性はあるな

リプライとかいう他人の投稿に自分の投稿をぶら下げる激ヤバ機能に制限がない状態で引用に制限をかけても仕方ないだろと思っているので、現状の引用の許可云々周りの議論にあまり興味がなかったりする

まあFEP-044fはGtSの機能の拡張っぽくて、その元の仕様としてはリプライとかにも対応できるものらしいけど、どうせ色々な副作用にも応用したくなるような概念だろうに、制限対象の副作用ごとにいちいちポリシーや許可を記述する語彙がアドホックに定義されるのがやはり微妙に思える。FEP-5624周りの議論にも通ずるところがあるけど

これは暴論なのだけど、そもそも標準の副作用がそれぞれ`Like`のようなアクティビティの型と`likes`/`liked`のようなコレクションのプロパティで二重に語彙を定義しているのが微妙なのではないか。標準のアクティビティならまだ良いけど、拡張がこのパターンに倣ってしまうと副作用を処理するためにいちいち個別の拡張に関する知識をサーバに要求することになってしまって良くない

やはりActivityPubは汎用のサーバが処理しやすい拡張の枠組みについてあまり考慮されていないのではないかという気がするのだよな。まあ意図はさておいても、現状の多くのFEPがサーバによる特別の対応を要求するものであることを踏まえれば、そのような枠組みが意図されていたとしても少なくともそれが成功していないのは確かである

まあ現実の拡張が汎用のサーバに配慮ない傾向にあるという偶有的な状態についてはさておいて、原理的にも汎用の`Add`や`Remove`相当の操作だけであらゆるソーシャルネットワークの機能に対する需要を満たすのは無理がある気がしていて、そうすると汎用のサーバに対してクライアントがそれぞれの拡張を意識したクエリを行うにはやはりSPARQLのような仕組みが必要になってくるのだろうか

少し前までは最低限の標準の副作用をサポートした上で`outbox`と`inbox`にプレーンなJSONを出し入れするだけみたいな極限まで単純化したサーバがあっても良いのではみたいなことを考えていたけど、こういうわけで3周くらい回って最近は結局Semantic Webからは逃れられない（？）のではという気がし始めていて、そうなると結局ActivityPodsで良いじゃんみたいな話になり、自分が成せることは何もないのではと思い始めていてアレ

まあそのActivityPodsも"business logic"の実現のために出入りするアクティビティを購読する外部のプログラムを走らせる運用をしている雰囲気があり（まだ勉強していないので詳細は知らぬ）、それならプレーンなJSONでもまだ同様の形でやりようはあるのではという気持ちは残っているけど

そもそもSPARQLのような汎用のクエリではfan outのような最適化の余地が少ない問題もあるだろうけど、そこに関しては個人的にはセルフホストできるように設計されているならばそこまでのスケーラビリティはそもそも不要というごり押し思想に傾きつつあるので、はい（？）