FediverseにおけるHTTP Signaturesとかいう、Replaced Internet-Draftのそのさらにちょっと古めの版（draft-cavage-http-signatures-06; <https://github.com/mastodon/mastodon/blob/1666b1955992e16f4605b414c6563ca25b3a3f18/app/controllers/concerns/signature_verification.rb#L3-L4>）が互換性のために使われ続けているというアレ。後継のHTTP Message SignaturesもまだInternet-Draftの段階だし

まあOStatusの頃と比べれば規格書が完全な形で残っているだけまだマシである（？？？）

ところで、RsaSignature2017の仕様の正式な記録がどこかに残っていたりしませんかね（？）

@aumetra Huh, I knew that they are different mechanisms, but it hadn't occured to me that they cannot even coexist in current implementations. That sounds, er, challenging, at best

iOSのMastodonの公式アプリのデータベースが100 MiBを超えようが過去に取得した投稿を全てキャッシュし続けるところが好きだったのだけど（？）、最新のアップデートで恐らく100件（<https://github.com/mastodon/mastodon-ios/commit/976f934df95225eda3248ec766d4c9651ba8bd21#diff-6992b0b38a4f7c7d37b5b76880847c58993cf3c4fbfa400886601d9bc92da9d1R8>）しか投稿をキャッシュしなくなっていて悲しい。なお今のところ元々データベースに入っていたキャッシュは特に掃除されずに残されている様子である

Twitterのノリで考えると投稿のキャッシュを一切捨てないなんて馬鹿らしいと思われるかも知れないけど、例えばメーラーではむしろそちらが標準的な振る舞いだし、マイクロブログでも同様の挙動をしてはならない理由はないよね。まあ一般的なメーラーのようにローカルのキャッシュに対して検索をかけられないようでは中途半端だろうけど

完全に差分だけを公開しているならまだしも、PRというインタフェースの技術的な都合によるところもあるとはいえ一応PRの差分を適用済のコードの全体をupstreamと同一の条件でAGPLライセンスの下で公開してしまっているわけで、それを「無断」で取り込むことの法的な問題は具体的に思い浮かばないな（IANAL）。人格権はライセンスの明示的な対象にならないとはいえ、著作物自体の同一性の保持に関してライセンスで明確に定められているし、後はVCSの履歴における氏名表示に関わるメタデータが保たれてさえいればそのあたりも争う余地は思い浮かばない（IANAL）

もちろん現実のコミュニティ運営としては最低限の契約を履行すること以上にクレジット周りの扱いで配慮があってしかるべきだし、さもなくば貢献者の不満に繋がって円滑なプロジェクト運営に支障をきたすことも仕方のないことではある。ライセンスが求めるAppropriate Legal Noticeを構成するかは微妙とはいえ、PRが通常のインタフェースからマージされることでITS上で貢献者がより分かりやすくクレジットされるという側面はあるわけだし

フォークとして「無断」のupstreamingに対して取れる法的な対抗策としては、フォークに対して自身への明示的なクレジットを追加することくらいだろうか。AGPLにおいて派生物のソースコードをconveyする際に追加の著作権表示を導入することは恐らく認められていて、それをさらにconveyする場合はその追加の著作権表示を維持することがライセンスの条件として求められるはずだから、upstream側としてはupstreamingに伴って追加の著作権表示を受け入れるか、さもなくば著作権表示を免除するための許諾をフォークの権利者から得る必要があって、後者に関してフォーク側として自身の望む条件を契約として強制する余地がありそう（IANAL）

本当はそういった面倒な手続きを取るよりも信頼関係を前提として良い感じに回す方が人的なコストは低いだろうし、信頼関係がないという前提においてはそもそもそこまでして貢献したいのかというところからして疑問がありそうだけど

あー、他者のコミットとまとめてsquash mergeすることを前提とすると確かに差分とVCSの履歴における氏名表示の対応が崩れるし、そのあたりとしてどうなるのだろう
QT: https://fedibird.com/@tesaguri/111927819696683699 [参照]

`Co-authored-by`のような表示を付けるのは大前提として、それでも単一のコミットに一人の作者が一対一対応する代わりに複数の作者が対応することで、どの差分が誰によるものなのかについての特定性のようなものが下がるのではないか……的な感じの気持ちですね（法律がそういうことを気にするのかは知らないけど）

極論すると、VCSの履歴を全て捨てて、「ご覧のcontributorの皆さまによって作られました」とするようなことも理論上は出来てしまうわけで

『けものフレンズ３』紹介PV日向夏美 - YouTube
https://www.youtube.com/watch?v=Ok1ptoV0gJ4
殺伐としたスレに

Lack of media type verification of Activity Streams objects allows impersonation and takeover of remote accounts · Advisory · misskey-dev/misskey · GitHub
https://github.com/misskey-dev/misskey/security/advisories/GHSA-qqrm-9grj-6v32
これを報告するなどしていた

Lack of media type verification of Activity Streams objects allows impersonation of remote accounts · Advisory · mastodon/mastodon · GitHub
https://github.com/mastodon/mastodon/security/advisories/GHSA-jhrq-qvrm-qr36
これを報告するなどしていた

これで取りあえず一段落は付いたので、ようやく枕を高くして眠れる〜。いや、お前普通に熟睡決め込んでいただろ。すみません（？）

まあ、私は重箱の隅をつつき回していただけなのでまだ気楽なものだった。それより各位はお疲れ様でしたという気持ちですね。いや、まだ各サーバによるデプロイ作業があるわけだけど……

「スパム対策」としてリモートからのアクティビティを暗黙かつ無差別に捨てるの、まっとうな利用者の混乱を招くだけでスパマーは普通にその対策を把握した上で行動を続けるだけなのではという気持ち

あと、`Delete`アクティビティはきちんと処理しているのだろうか（コードは未読）

別のサーバに引っ越したフォロイーの新アカウントに対して何故かフォローが移行されていなかった

「無差別に」というより「特定サーバ以外のアカウントに対して無差別に」が正確か

まあ、一方的なフィードとしての価値くらいはあるだろうか。Social networkとしてどうなのかは知らないけど

これって.ioのフォークに限定した脆弱性が対象なのかなとか、セーフハーバーのようなものはあるのかなとか気になる
QT: https://misskey.io/notes/9gyoevbbij [参照]

.ioのフォークは公開されているとはいえ、必ずしもローカルで.ioの環境を十分に再現できるとは限らないし

この話については昨日になって存在に気付いたやつですね。まあ、私はただFediverseの安全を守りたいだけなので、いずれにせよやることは変わらなかっただろうけど……（曇りなき眼）

個別のサービスと独立したアイデンティティの共有はActivityPods（<https://activitypods.org/>）が実現しようとしていることが近いかな。詳しくは知らないけど

Begin Silencing Unsupported Version Mastodon Instances · Issue #29283 · mastodon/mastodon
https://github.com/mastodon/mastodon/issues/29283

モデレーション上の足切り目的としては全く知らない実装は保守的に受け容れることも出来るかも知れないけど、例えばセキュリティパッチをbackportしながらNodeInfo上の見た目としてはupstreamの古いバージョンと区別が付かないフォークのような、微妙に困るケースがありそう

まあ、upstreamでサポートされているバージョンへの追従もしないならもう別実装を名乗るべきではというのはあるかも知れない

あとは、`inbox`に対する`POST`への応答ならともかく`GET`の場合はauthorized fetchを要求する必要がありそうで、しかしauthorized fetchは何も考えずに有効に出来るようなものではないよなあというのもある。まあ、モデレーション上の足切り目的としてはそこまでする動機はないか

`as:sensitive`とかいう拡張プロパティが`true`と`false`の二値しか取れないのは大雑把すぎるなあと思っている。例えば、未成年者が`"sensitive": true`なオブジェクトを全て非表示にするには現状の慣行としては過剰すぎるし、かといって年齢制限が必要なものだけにラベル付けするというのもゾーニングの仕組みとして十分とは言いがたいだろうし（旧Twitterを含む多くのプラットフォームにおいて年齢制限の有無くらいのラベル付けしか用意されていない気がするけど）

cf.
Appropriately defined properties for Content Warnings and Content Labels · Issue #583 · w3c/activitystreams
https://github.com/w3c/activitystreams/issues/583

例えば旧Twitterのいわゆる公式クライアントはWeb Appと違ってアプリ内でセンシティブなメディアの非表示を解除できないといったプラットフォームの制約によるものらしき挙動があるけど、同じことをFediverseでやるとすると未成年者が哀れすぎるという気持ちがある

（実情としては"possibly sensitive"の運用が雑な旧Twitterの方がつらい気はするけど）

???????「PDSとモデレーションの分離！　柔軟なラベル付け！」（連合が未開放）（既に単一のPDSにユーザが集中している）（その上で少なくない数のユーザが凍結されている）

？

（DIDsの利用を謳っているものの現時点で利用されているDID methodが中央集権的）

Mastodon（Fedibird）のプロフィールからSocialHubのプロフィールにリンクしようかと思ったけど、非ログインユーザにはDiscourseのプロフィールページが公開されないのか。設定でどうにか出来たりしないだろうか

RFC 9421 - HTTP Message Signatures
https://datatracker.ietf.org/doc/html/rfc9421
つい先日にHTTP Message Signatureはまだドラフトで云々と書いたばかりなのでびっくり

「つい先日」
QT: https://fedibird.com/@tesaguri/111865537036021460 [参照]

HTTP Message Signatureが正式なRFCになったのはめでたいなあ。ところで、どうやって既存の実装を最新の仕様にアップグレードするべきかという問題（<https://github.com/swicg/activitypub-http-signature/issues/10#issuecomment-1934394031>）がまだ残っていまして……