19:23:33
2023-12-21 18:29:47 Daniel Supernaultの投稿 dansup@mastodon.social
icon

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

19:23:49
icon

mastodon.social/@dansup/111617
> Soon we will be selectively enforcing authorized fetch for accounts with domain blocks so as to provide the best of both worlds.
なるほどなあと思うと同時に、むしろMastodonにおいて`AUTHORIZED_FETCH`がアカウント単位の設定でなくサーバ全体の設定になっている理由が気になってくるな。`AUTHORIZED_FETCH`のデメリットというとオブジェクトの署名の無効化によるinbox forwardingやらリレーやらの配送効率の低下であって、そのコストを負うのはサーバの管理者であるからとか? エンドユーザにとってのデメリットというと互換性の低下くらいだろうか [参照]

Web site image
dansup (@dansup@mastodon.social)
Web site image
投稿の参照(1件) by tesaguri 🦀🦝 (@tesaguri@fedibird.com)
19:41:59
icon

個人的にはリクエストを何でもかんでも署名するのはプライバシー上の問題がないか心配なのだよなあ。まあ署名には基本的にsystem actorの鍵対を使うとして、それでも問題になるとすると個人用サーバの振る舞いがその管理者による操作をリアルタイムに反映してしまうことくらいだろうけど、それは元々IPアドレスから分かることではあるだろうから、署名によって新たな問題が生じるかというと微妙かも知れないけど

19:45:16
icon

Backfill statuses from remote accounts when first subscribed · Issue #34 · mastodon/mastodon
github.com/mastodon/mastodon/i
System actorでなく個々のアカウントの鍵を使う動機のある機能の提案もあるので、そのあたりはどう実装されるか気になっている

Web site image
Backfill statuses from remote accounts when first subscribed · Issue #34 · mastodon/mastodon
20:06:50
icon

ActivityPubのC2Sプロトコル(Social API)ではクライアントが直接アクティビティを生成するからFEP-ae97 (Client-side activity signing; <codeberg.org/fediverse/fep/src>)のような面白そうなことが可能になるのだけど、その利点を活かすにはサーバはクライアントから送られたアクティビティのオブジェクトをそのまま配信する必要があるわけで、バリデーションやらデータベースにおける扱いやらがややこしくなりそうである

20:07:11
icon

トリプルストアの普及の機運か?(?)いや、JSON-LDのコンテクストはどないすんねん(?)

20:13:38
icon

バリデーションの問題についてはFederation Protocolにも言えることだし、案外同じ要領で処理できたりするだろうか。`published`の値なども任意に設定可能にするのは過激かも知れないけど、例えばproxy object(FEP-fffd)のようなユースケースではそのレベルの自由度も妥当なのでは。まあ汎用のサーバであらゆるユーザにそれを許すのは微妙かも知れないけど……

20:40:05
icon

しかしクライアントサイドの署名を求める場合において`Update`アクティビティの扱いはどうなるのだろう。`Update`アクティビティの`object`プロパティはSocial APIとFederation Protocolの間でかなり異なるわけだけど。具体的には、Social APIにおいて`object`は元のオブジェクトからの差分として扱われるのに対して、Federation Protocolにおいては更新後のオブジェクト全体を`object`に含めることが求められているし、そもそも更新後に`object`のURIを参照外しした場合はその結果は更新後のオブジェクト全体になることが期待されるわけで

20:46:24
icon

まあFederation Protocolと違ってSocial APIは<del>あまり流行っていないし、</del>互換性の影響範囲が特定のサーバとそのユーザの間に閉じているから多少は勧告と異なる要件を含めてもワンチャン許されそうだし(ホンマか?)、`Update`は部分的な更新でなく完全な置き換えとして扱う対応もアリかな? そもそも部分的な更新は特にプロパティの削除に関してRDF的に扱いに怪しさがあるし(<github.com/w3c/activitypub/iss>)。まあ部分的な更新が出来ないと何かと面倒そうな気がしないでもないけど……

Web site image
6.3.1 Partial Updates: Incompatible with JSON-LD · Issue #396 · w3c/activitypub
20:47:51
icon

はいSocialHubに書け云々でもGmail云々(?)

20:56:42
icon

クライアントAPIの仕様がMastodonだのMisskeyだのといった特定の実装に紐付いていたり、例えばリアクション機能をMastodon APIで実現しようとしたときにFederation Protocolから独立して拡張が乱立したりするのはつらみがあるからActivityPubのSocial APIももう少し流行ってくれると良い気がするけど、実際のところとしてはいまいちパッとしないのだよなあ。「インスタンス」だのドメインブロックだののようにSocial APIの枠組みでは扱いづらそうな概念も多いし

21:01:17
icon

最近でいうとThreadsも独自のAPIか