tesaguri 🦀🦝 @tesaguri@fedibird.com

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

投票所入場券、未達――

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

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

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

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

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"`は変な気がするけど

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

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メソッドや、Mitraがやっているような決済系とか

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.)."と書いているのは注意に値するのでは。その上で信用できないというのは自由だろうけど

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.
ふむ

つまり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ということか（？）

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"と読み替えて拡散しているのを見かけるなどした。批判するにしても言葉は正確に使って欲しい

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

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

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

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