tesaguri 🦀🦝 @tesaguri@fedibird.com

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

こんな感じで……

```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>
```

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

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

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

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

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

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

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

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

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.
ともあるし

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

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

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

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

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

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

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

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