仮にエンティティの形がFederation Protocolのものから乖離していたり未知の拡張を無視したりするならば、特定のアプリケーションと密結合という意味においてMastodon APIと大差なくなってしまうと思うけど、その点でGraphQLのデータモデルはActivity Streamsのそれと馴染まないような気がする。Persisted queriesとかも、不特定多数のクライアントに対応しようとするならば適用できないだろうし

Backend for frontend、どこかで見たようなパターンですね……

？

で、その噂の（？）AT Protocolにおいてこの辺りがどう扱われているかというと、AppViewごとのAPIで固有の形式のビューを返しつつも、拡張込みでオリジナルのレコードをそのまま埋め込んだりしているらしい（<https://whtwnd.com/did:plc:qi6xg6zplzivyu7zrylxuugk/3kwmldx2b3l22>）（知らんけど）。

これをActivityPubに適用するならば、BFFのAPIにおいて例えば全く独自の`Status`エンティティを返す代わりに`Note`などのActivity Streamsのオブジェクトを埋め込むとかになるだろうか

しかしまあBFFと言っても、例えば`app.bsky.feed.getAuthorFeed`と`com.whtwnd.blog.getAuthorPosts`が別々に定義されているみたいな状況はActivityPubのエコシステムには馴染まなそうだな。どうせ`Note`とか`Article`とかごちゃ混ぜに扱っているくせにAPIだけ分けても仕方ないだろ、的な。

というわけでパターンを真似するにしても、あちらよりはもう少し汎用的なAPIを実装を跨いで共有しやすい枠組みだと嬉しそう。それこそFEPで継ぎ接ぎ的に拡張できるような（具体的にどういうものが望ましいのかは知らんけど）

そういえばFediverse Discovery Providersは全く追えていないけど、ちゃんとActivity Streamsのデータモデルを尊重するつもりがあるのか気になっている