新しいものを表示

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

スレッドを表示

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

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

スレッドを表示

こんな感じで……

```html
<a href="example.com/actors/1" rel="as:cc" type="application/activity+json">@alice@example.com</a>
<img property="as:tag" resource="example.com/emojis/1" typeof="joinmastodon.org/ns#Emoji" alt=":blobcat_foo:" />
<a href="example.com/notes/42" rel="misskey-hub.net/ns/" type="application/activity+json">RE: 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(<atproto-browser.vercel.app/>)こそが分散的ということなのですよね(?)

スレッドを表示

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

スレッドを表示

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

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

Blobs - AT Protocol
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部分?)を全てひっくるめたものと大差ないのでは

tesaguri 🦀🦝 さんがブースト

#BlueSky isn't decentralised or federated. The outage yesterday is the obvious proof. It may *look* decentralised and they definitely love to outsource traffic and storage costs by claiming that running your own PDS (Personal Data Server) is somehow something federated, but that's all smoke and mirrors. You have to gor deep on [1] to find "networking through Relays instead of server-to-server" as their current implementation choice. THEY run the relays. No one else.

[1] bsky.social/about/blog/5-5-202

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

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

スレッドを表示

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

スレッドを表示

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

詳細には詳しくないですが、FEP-0837: Federated Marketplace (<w3id.org/fep/0837>)が近そうな気がします。Mitraの有償購読機能(<codeberg.org/silverpill/mitra/>)がこれによるもののようです

古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。