`Follow`や`Like`アクティビティの公開範囲（`to`や`cc`）、誰も尊重していない説があるな
`Follow`や`Like`アクティビティの公開範囲（`to`や`cc`）、誰も尊重していない説があるな
MastodonもMisskeyも`Like`を`as:Public`にaddressingしていない（っぽい）のに対して、Misskeyは見ての通り各投稿に無条件で`likes`コレクション相当の表示を持っているし、Mastodonもインスタンスによるのかも知れないけど同様の表示を持っている
各ユーザのリアクションの一覧の公開設定があるMisskeyについてはともかく、プライバシーを理由にユーザのプロフィールにお気に入りの一覧を表示しないようにしておきながら各投稿に付いた`Like`は公開するというMastodonの挙動はどっち付かずのように思える
これがあるので、お気に入りを行ったユーザの一覧をMastodon API（`GET /api/v1/statuses/:id/favourited_by`）に露出するくらいなら`likes`コレクションを公開するべきと考えている
QT: https://fedibird.com/@tesaguri/111272699931631750 [参照]
validator.w3.org、challenges.cloudflare.comのサードパーティCookieを蹴っているせいかTurnstileの画面で無限ループして萎える
たかがバリデータにファーストパーティCookieを認めるだけでも最大限の譲歩なのだから、それで適当にやりくりしてもらいたい（クレーマー）
ここでの「たかが」というのは「本質的にCookieを必要とするような性質のサービスではないよね」という程度の意味です（補足）
まあfirst-party isolationを有効にしているので、多少のサードパーティCookieの例外を追加するのも吝かではないけど
`dhall-rust`がunmaintainedになって久しいし、いい加減移行を検討しなくてはなあ。
とは言っても、元々私のプロジェクトでは直接のDhall対応はオプショナル扱いで、基本的には`dhall-json`で生成したJSONファイルを食わせる運用を想定していたから、移行というよりはそのオプショナル対応を完全に外すだけの話なのだけど
@aumetra Honestly, the unmaintained status of the Rust library doesn't affect my usecase so much because my personal preference was to preprocess the Dhall config with `dhall-to-json` before feeding it to the application anyway (because evaluating Dhall config is an infallible high-footprint operation that may involve network access etc.).
But yeah, decrease in the diversity of implementations is regrettable even so
既に手元に>2 kLoCsのDhallファイル群があるのでDhallを完全に諦めるという選択肢はない