Mastodon APIというのはActivityPubのSocial APIほどには拡張性を考慮していないと思われるので、上流に存在しない機能を追加するならPleromaのようにMastodon APIを拡張しようとするよりMisskeyやThreadsのように独自の体系を使う方がまだ健全なのではと思っている

いや、本来ならSocial APIを使える場面ではそれを使うのが理想だろうけど、Social APIというのは基本的にFederation Protocolに流すアクティビティをクライアントが自ら書いてそれをサーバに転送してもらうという仕組みで、例えば「ブックマーク」機能のように連合と無関係な機能を表現しづらいので、結局はMastodon APIのようなものと併用するしかなさそうに思っている

C2S APIに求められる要件としてはもう一つ、リモートのオブジェクトをローカルのサーバにプロクシしてもらう役割というのがあって（さもなくばクライアントがリモートのサーバにいちいちIPアドレス等を晒すことになる）、実はSocial APIはこれを行うための`proxyUrl`というエンドポイントを定めているのだけど（<https://www.w3.org/TR/2018/REC-activitypub-20180123/#proxyUrl>）、規格で細かい挙動が規定されていなくていまいちパッとしないように感じられる。
まあPrimerはあるのだけど（<https://www.w3.org/wiki/ActivityPub/Primer/proxyUrl_endpoint>）

ActivityPub、規格の行間はPrimerで補うという運用が多い割にPrimerへの導線が弱い気がする

このアカウントは、notestockで公開設定になっていません。

Third-party cookies have got to go | 2024 | Blog | W3C
https://www.w3.org/blog/2024/third-party-cookies-have-got-to-go/
> We’ve been working with Chrome’s Privacy Sandbox team […]. This announcement came out of the blue, and undermines a lot of the work we’ve done together to make the web work without third-party cookies.