https://github.com/tesaguri/userscripts/commit/fae29bf35351c3cc1ea62744d877dad0723a67dd
> fix(fedibird-hook-bsky-app-links): oh shoot `RequestInit.referrer` uses correct spelling
今日のクソコミット

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

Blueskyは「ActivityPubはスケールしない（笑）」（<https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:vpkhqolt662uhesyj6nxm7ys/post/3l3gvrir5bu2u>）という立場だから、「ActivityPubに対応」するようではそもそもの存在意義が薄れるわけで……。それを"decentralized"と呼んで良いかはアレとして [参照]

例えばZennがGitHub以外のGitリポジトリからもデプロイできたとして、それを「分散」と呼んで良いのかみたいな（適当）

AT ProtocolのAppViewをGoogleに喩えると一般のWebと大して変わらないように思えるけど、恐らくAppViewというのは検索エンジンだけでなくgoogle.com/ampのようなキャッシュレイヤーでもあって、しかもGoogleのそれと違ってキャッシュされていないWebページ、もとい`at:` URIへのアクセスを許すようなものでもないっぽいので、重要な要素を取りこぼした喩えのように思っている

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

やはりRDFが嫌というのが第一の理由か。しかし根本的なアーキテクチャの違いなどと比べると、既存のエコシステムとの相互運用性と天秤にかけるには軽すぎるように個人的には思えるけど、まあこれはBlueskyにとっての一般のWebエコシステムとの相互運用性の重さというのがその程度でしかないという話なのだろう
QT: https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:ragtjsm2j2vknwkz3zp4oxrd/post/3juunh2s5gh26 [参照]

元の質問（ブリッジされていないけど、リプライ先の<https://atproto-browser.vercel.app/at/did:plc:linxaw3dwjjlqxyiit6vbapy/app.bsky.feed.post/3juumhkeuag2z>のこと）がActivity Streamsについてだったのに対して、途中からはActivityPubの話になっているな。
まあ既存のActivityPubのエコシステムにおける純粋なActivity Streamsのサポートが渋くて、純粋なActivity Streamsを露出しても中途半端な扱いになったかも知れないというのはそれはそうかも知れないけど……

既存のnormが相容れないことについては、データ形式ごと放棄せずとも例えばFEP-ef61 portable objectsのように`id`の名前空間を仕切り直して、新しい名前空間で新たなnormを打ち立てることを目指すとかでも良かったのでは。どうせaccount portabilityの関係から名前空間を分ける必要性はいずれにせよ生じたものだろうし。
どちらもそのままでは相互運用できないことに変わりはないけど、完全に非互換なデータ形式と比べれば`id`が非互換なだけだったなら既存の実装が対応することも容易だっただろう。まあ、そうなるとActivityPub実装が一方的にBlueskyを読むだけというパターンが多くなったかも知れないし、それがBluesky側にとって望ましかったかは知らんけど

たらればの話をしても仕方ないけど、それはそれとして僕の考えた最強のプロトコル設計の話は楽しいので（？）

久しぶりに投稿したかと思ったら陳腐なMastodonオワコン論のリブログみたいな人、流石にアンフォローしちゃうよね

まあ、Fediverseに溢れているBluesky批判もAtmosphere側から見れば大概似たようなものか（？）。同じことでもそれをあえてFediverseにおいて他人のインフラを使いながらやるとアレになるというだけで

@noellabo @tell_me_fedi_jp 詳細には詳しくないですが、FEP-0837: Federated Marketplace (<w3id.org/fep/0837>)が近そうな気がします。Mitraの有償購読機能（<https://codeberg.org/silverpill/mitra/src/commit/f678698eb31832c417166e774377c54201ed1332/FEDERATION.md#subscriptions>）がこれによるもののようです

アクティビティの配送、いちいち`Host`ヘッダごとにHTTP Signaturesを生成しなおすのでなく、オブジェクトに署名を埋め込んでHTTP Signature抜きでそれを使い回すとか出来ないだろうか。MastodonとかはHTTP Signatureがないと受け付けてくれなかった気がするけど……

否認不可になるのが嬉しいとは限らないかも知れないけど、そもそもHTTP Signaturesだって恐らく受信者が特定の`Host`に特定のメッセージを送られたことを否認不可な形で証明できてしまうよね

Fediverseでは使われていないと思うけど、TLSのクライアント証明書とかはそのあたりどうだったっけ（うろ覚え）。セッション鍵の確立までの認証だとしたら、その後のやり取りは否認可能になるだろうけど

Issueにかなりどうでも良い長文two centsを投げつけていたらタイミング悪くメンテナのコメントと被ってしまって、マジで邪魔なコメントを投げただけの人になってしまった

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

"outsource traffic and storage costs"の部分は私も疑ったことがないでもないけど、仮にリレーやAppViewのキャッシュを抑制してAppViewがblob referenceばかり返してクライアントはPDSを直接叩きに行くような世界観だったならまだしも、実際はAppViewは今のところblobとかもキャッシュしているようだし、そのストレージコストは既知のPDSの権威的なデータ（のうち関心のあるlexicon部分？）を全てひっくるめたものと大差ないのでは

Blobs - AT Protocol
https://atproto.com/specs/blob
> It is not a recommended or required pattern to serve media directly from the PDS to end-user browsers, and servers do not need to support or facilitate this use case.
ともあるし

リレーも建てる試みは一応存在しなかったっけ？　まあいずれにせよ恐らくサードパーティのリレーの存在の有無自体は大した問題ではなくて、というのも恐らくリレーを建てたところでAppViewがそれを見てくれなければ意味がないので

エアプなので文の区切りのたびに免罪符として「恐らく」を挿入している（？）

というかそもそもリレーなんてものに関係なく未知URIを都度解決できたならば一般のWebが分散的であるのと同程度には分散的なアーキテクチャと呼べただろうに（この際1 googolplex歩譲って検閲の問題は考えないものとする）、実際はキャッシュの立場が強すぎるっぽいのが惜しいと思っている。
"big world with small world fallbacks"の"small world fallbacks"って結局何なんやねん。クライアントの手元で手作業でDIDを解決・検証してPDSを直接叩くこと？（？）

つまり、Blueskyは分散的ではなくて、ATProto Browser（<https://atproto-browser.vercel.app/>）こそが分散的ということなのですよね（？）

リポジトリの購読までは"small world fallbacks"で解決できても、例えばリプライの存在の通知といったレベルの"reach"ですらAT Protocolのアーキテクチャでは恐らくネットワーク全体の集約に依存せざるを得ないので、これもかなら極端な設計と言えるかも知れない。
<strong>個人的には</strong>フォロイーからの通知と知らない人間からの通知の扱いが異なるのはある種の思い切りとしてはありなのではと思うけど、まあ少なくとも一般的な考え方ではないよね。この辺りはSMTP的なモデルの方が素直ではある

スクリプトの内容をURLに突っ込み`eval(location.search)`することでベンチマーク上のスクリプトファイルのサイズを圧縮する技術（存在しない技術）

Activity Streamsにおける`tag`の`name`をmicrosyntaxとして扱う慣習が非常にアドホックに思えてならない。こういうのはもっとまともなマークアップ言語に任せるべき仕事でしょ。例えばRDFaとか……（真顔）

何かMisskeyで上手く表示できていないっぽいけど、まあそれはMisskeyが悪いということで（？）

こんな感じで……

```html
<a href="https://example.com/actors/1" rel="as:cc" type="application/activity+json">@alice@example.com</a>
<img property="as:tag" resource="https://example.com/emojis/1" typeof="http://joinmastodon.org/ns#Emoji" alt=":blobcat_foo:" />
<a href="https://example.com/notes/42" rel="https://misskey-hub.net/ns/" type="application/activity+json">RE: https://example.com/@Alice/42</a>
```

というかJSONにHTMLを突っ込むのもだるいので、初めから全てXMLにしません？（Atom Activity Streams 1.0の再発明）（？）

Fedibirdで`misskey-hub.net/ns/#_misskey_quote`と書こうとするとフラグメント部分が消える現象があるのだよな。<https://example.com/#foo>のように単にフラグメントがあるだけのURLでは再現しないので、条件としてはリダイレクトがあるURLとかだろうか

s!/#!#!
（`/`の有無でリダイレクトの有無が変わるので、この文脈では重大な誤字）

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

面白い脆弱性だと良いな（すみません）

複数の独立した（フォークを含まない）実装に影響するようなクラスの脆弱性でないならあまり私の関心分野ではないかも知れないけど（？）

やべえ秘密鍵をpushしてしまった、もうおしまいだ……（いいえ）

tesaguri/activitypub-type-confusion-poc: Proof of Concept for the type confusion vulnerability of ActivityPub implementations
https://github.com/tesaguri/activitypub-type-confusion-poc
というわけで、2024-02-17頃にMastodonやMisskeyなどで修正された脆弱性のPoCを今になってこっそりと公開するなどしていた

原理としては単純な脆弱性なので具体的なPoC自体は大して重要でもないと思うけど、MisskeyのPoCはちょっとしたindirectionを要しているので、そこは見所といえるかも

いや、そのハックも含めてMisskey側のGHSAで既に言及されているからやはり見所はないかも

元々スクリプトも文章も脆弱性報告に使える程度には形になっていたのに、仕上げが面倒だからといって公開を先延ばしにしていたら一瞬で9ヶ月も経っていた……（？）

AT Protocolのドメイン、名付けてatprotocom！ｗ、じゃあないんだよな

`bsky.app`のURLを踏まずにPDSを直接読む縛りをしているのだけど（？）、`app.bsky.feed.post`のレコードは自己に対するリプライへの参照を持たないので、スレッドすらろくに読めない。`app.bsky.feed.getPostThread`を実装してください（？）

`bsky.app`とかは今のところそれ単体のみから`at:` URIを再構築できる形式のURLだから良いけど、`whtwnd.com`はrkeyでなく`title`しか含んでいないこともあるので困る（何が？）

「（何が？）」じゃあないんだよ、AppViewが落ちたらどうするのだ（？）

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

分散システムのサービスとしてのBlueskyに対する評価としてはこんなところだよね（スレッドの方は未読）。というか"decentralized"という自称が無用な幻想と失望を招きすぎている

これはBlueskyが"decentralized"という形容をPDSレイヤーに限定せずに用いているのが悪いのだけど、FediverseにおけるBluesky批判の多くがBluesky側のビジョンについてそれに同意するしない以前に議論ために最低限必要な理解もそこそこに「分散していない」の一点の批判に終始しがちだし、擁護者も「Blueskyは分散している」という雑な主張で返してグダグダになりがちという感想

まあもちろん細かい点で共感できない部分もあるけど。例えば自分で鍵を管理していないユーザを保護できていないことについての批判は流石に酷なように思う。
個人的にはまずはやる気があるユーザが現実的なコストで自分のデータを確保できることが重要かなと

まあこれについてもMatrixのようにもっとユーザフレンドリーながらサーバを信用しない鍵管理とかも考えられるのかも知れないけど。いや、Matrixが実際に何をしているのかは正直一切把握していないですけど……（？）。
あと詳しくはないけど、これも実際恐らく真なのだよな：
> And *even if* Bluesky delegates authority to that user to control their identity information in the future, there is still a problem in that Bluesky will *always* have control over that user's key, and thus their identity future.
"72hr window"とかもPLCサーバ自体が敵対的なら恐らくどうとでもできる程度のものだろうし（<https://web.plc.directory/spec/v0.1/did-plc>の"PLC Server Trust Model"節を参照）

あとハンドルシステムが無意味かのような評価も過剰かなと。以前に解決したことのあるハンドルについてはその"DID"との対応の変遷はクライアントが記録を付けておけば良い話だし（新規の解決はまた別問題だけど）、現実的にそのような運用を可能とするだけの枠組みは提供されているように見える。
Petnameシステムについてはこの記事で初めて名前を目にしたくらいなので、それとの比較でどうなのかについては何も言えないけど

あとこれは純粋にPDSとそのホストするユーザのハンドルの関係を勘違いしていそうな雰囲気がある
> Most users are mapped to domains controlled as `*.bsky.app` [sic] subdomains, so Bluesky can remap those to different users, and this will be true with any "Personal Data Store" [sic] provider one might use too

しかしLemmer-Webber氏もFediverseにアカウントを持っていらしたんだな。
当たり前だろ、どなただと心得ている。すみません（？）