非常に大雑把なイメージとして、PDSというのは中央集権プラットフォームにおけるシャーディングされたデータベースにgitリポジトリの要領で可搬なデータ形式を与えて、それぞれを独立したサービスとして切り出したようなもの的に認識している。的を射たイメージなのかは知らぬ

Solidのpodに署名されたActivity Streams文書を突っ込んだやつと比較して、改竄耐性を捨てた後のAT ProtocolのPDSが本質的にどういう優位性を保っているのかよく分かっていない。というのも、そもそもSolid自体を全く理解していないので（？）

✨Semantic Web✨に関わりたくないというのが普通に大きそう（？）

Pleromaが絵文字の画像のURLを`id`に設定するの、すごい仕様だな……と思ったけど、そういえばMastodonの`Update`アクティビティとかも`id`を参照外ししたときにその`Update`アクティビティ自身が含まれないような文書が返ってくるのだったっけか

Just noticed @Mastodon has its `toot:indexable` value set to `false`. I wonder if it's intentional

AT Protocolの世界観では少数のAppViewの実装者が自身の所有するNSIDのlexiconをかっちりと制御するのが理想で、拡張プロパティが対等でないのはもしかして欠点ではなく機能として意図されているのではという気がしてきた。
コレクションは基本的に1つのAppView実装＆インスタンスにのみ対応するという想定で、例えば`app.bsky.feed.like`に絵文字リアクションのサポートを追加する代替／フォークAppViewのようなものを考慮する必要性は低い的な（適当）
QT: https://fedibird.com/@tesaguri/113265786190900091 [参照]

大量の実装がそれぞれ微妙に異なる拡張のセットしかサポートしていない中でいかにマシなフォールバック表現に落ち着くように拡張を設計できるかとかを考えるのが楽しいのに（いいえ）

AT Protocolの`!no-unauthenticated`ラベルとかいうやつ、エコシステムの中で一人だけ妙に浮いている気がする。他はあらゆるものを全世界に晒している中で中途半端に融通の効かないアクセス制御もどきが紛れ込んでいるというか

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

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

他人が管理する名前空間の名前を勝手に使うの、所有者本人が同じ名前を使おうとした時に困るというアレがありそう

「ありそう」というか、名前空間というものがそもそもそういうものか……

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

そういえば名前空間の所有権とはまた別の話だけど、FEP-268dを書いていたときにこれを見かけたのだけど、結局この`searchableBy`は実用されたことがあるのだろうか。あるならターム名の衝突だし、ないとしてもニアミスで、いずれにしても現行のFediverseにおいてJSON-LDの名前空間の仕組みが実質的に死に体になってしまっていることの弊害の例をなしていそう
QT: https://blahaj.zone/notes/9ev0kge0aj [参照]

feat: ノートの閲覧にログイン必須にする設定 by syuilo · Pull Request #14799 · misskey-dev/misskey
https://github.com/misskey-dev/misskey/pull/14799
参照されているissueの「AI、検索エンジンといったクローラーを避けたい時などに使えそう」というユースケースはどう満たしているのだろうか。
いわゆるauthorized fetchを強制したりしているのかな。斜め読みをした限りよく分からなかったけど

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

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

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

取りあえず署名付きオブジェクトの転送については考えないものとして、理屈の上では配送当時のフォロワー（⊂過去全てのフォロワー）と過去に受けた`GET`リクエストの署名のkeyidの`owner`を覚えておけばかなり網羅できそうな気もするけど、例えばMastodonの`StatusReachFinder`を見た感じではそこまではしていなそう

実際に投稿数×（フォロワー以外の）`GET`リクエストを送ったアクターなんて覚えようとしたらかなり厳しそうだしなあ

FedibirdのWeb UIの詳細表示で参照とリプライのいずれもスレッド表示に含まれて見た目では区別が付かないの、いまだにどうすれば良いのかよく分かっていない

典型的に`Error<T::Error, U::Error>`のような形で使われる多相な`Error`の略記として、`type FooError<T, U> = Error<<T as Trait1>::Error, <U as Trait2>::Error>`のような別名を定義したいのだけど、しっくり来る名前が浮かばない

取りあえず滅茶苦茶雑に`ErrorFor`とか命名しておいたけど、いくら何でも雑すぎる。一応`type Result<T, U, V> = core::result::Result<T, ErrorFor<U, V>`も定義して典型的な例では雑命名を避けられるようにしたものの、やはりエラー単体で名指しせざるを得ない場面もある。
一応`Error`自体の定義を`enum Error<T: Trait1, U: Trait2>`に置き換える手もあるだろうけど、柔軟性が下がるし、持ち回すときに無駄なトレイト制約パズルが発生しそうなので、これも避けたいところ

Bluesky Announces Series A to Grow Network of 13M+ Users - Bluesky
https://bsky.social/about/blog/10-24-2024-series-a
"raised a financing by foo"を"now owned by foo"と読み替えて拡散しているのを見かけるなどした。批判するにしても言葉は正確に使って欲しい

つまりFediverse is owned by the NGI Foo Fund, a fund established by NLNet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technologyということか（？）

Fediverse is owned by Me–（炎上）

Add more explicit explanations about author attribution and `fediverse:creator` by ClearlyClaire · Pull Request #32383 · mastodon/mastodon
https://github.com/mastodon/mastodon/pull/32383#issuecomment-2418975448
> renchap commented Oct 17, 2024
> We are following the discussions in https://github.com/swicg/activitypub-html-discovery and will add support for the standard once it has been defined.
ふむ

AT Protocolは初めからブロックチェーン技術の利用をはっきりと否定しているし（<https://atproto.com/guides/faq#is-the-at-protocol-a-blockchain>）、件の発表でも"This does not change the fact that the Bluesky app and the AT Protocol do not use blockchains or cryptocurrency, and we will not hyperfinancialize the social experience (through tokens, crypto trading, NFTs, etc.)."と書いているのは注意に値するのでは。その上で信用できないというのは自由だろうけど

それはそれとして非中央集権ネットワークにおいてはブロックチェーンも自明にナンセンスとは言い切れないと思うけど。例えば分散台帳系のDIDメソッドや、Mitraがやっているような決済系とか

https://json-ld.org/playground/#startTab=tab-expanded&json-ld={"@context":["https://www.w3.org/ns/did/v1","https://w3id.org/security/multikey/v1","https://w3id.org/security/suites/secp256k1-2019/v1"],"id":"did:plc:ewvi7nxzyoun6zhxrhs64oiz","alsoKnownAs":["at://atproto.com"],"verificationMethod":[{"id":"did:plc:ewvi7nxzyoun6zhxrhs64oiz#atproto","type":"Multikey","controller":"did:plc:ewvi7nxzyoun6zhxrhs64oiz","publicKeyMultibase":"zQ3shunBKsXixLxKtC5qeSG9E4J5RkGN57im31pcTzbNQnm5w"}],"service":[{"id":"#atproto_pds","type":"AtprotoPersonalDataServer","serviceEndpoint":"https://enoki.us-east.host.bsky.network"}]}
`plc.directory`の"DID"文書、何故ところどころベースURI依存の記述があるのだろう。ベースURIを`https:// plc.directory/:did`とすると特に`"type": "AtprotoPersonalDataServer"`とか意味不明になる気がするけど

そこで"DID"を引用符で囲むのやめなさい（？）

https://www.w3.org/TR/2022/REC-did-core-20220719/#relative-did-urls
> The base URI value is the DID that is associated with the DID subject
あー、DIDエアプのボロが出たな（？）。それにしてもやはり`"type": "AtprotoPersonalDataServer"`は変な気がするけど

人々ブリッジしてくれーと念じながら無限に`app.bsky.graph.getRelationships?actor=did:plc:xbifsywyv5pka5jlknhv5yv3&others[]=…`を叩いている

あまりBluesky AppViewのAPIを当てにしすぎるのもアレだけど、Bridgy Fedのエンドポイントを叩きまくって負荷をかけるのもアレなので

（Blueskyなら負荷をかけて良いという意味ではなく、`getRelationships`は一度に30件まで取得できるのでリクエスト数を減らせるという意味）

推敲中にいくらグッと睨んでも見えなかった誤字が送信した瞬間にいきなり光って見え始めるの本当にやめて欲しい

投票所入場券、未達――

feat: bring back `TryFrom<Bytes>` implementations by tesaguri · Pull Request #470 · hyperium/http
https://github.com/hyperium/http/pull/470
`http`の型から`Bytes`を取り出してえ〜という気持ちになるたびに手慰みにこれのコンフリクトを解消するなどしているのだけど、まさか特に動きがないまま3年も経つとは思わなんだ（？）