このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
"An ID explicitly specified as the JSON null object, which implies an anonymous object"（JSON-LDとしては不正）なあ……
ActivityPubの仕様すらJSON-LDを真面目に扱っていないのだとしたら素人の我々はなおさら雰囲気で扱っても許されるということだろうから勇気づけられる（いいえ）
@tell_me_fedi_jp TwitterでＡからＢにメンションした時、ＢをフォローしてないＣのホームタイムラインには、そのＡのメンションは表示されなかったと思うのですが、マストドンだと表示されるようです。
そのような仕様になった理由はあるのですか？
Activity Streamsとしては`to`や`cc`を使い分けろという話なのだろうけど、Mastodonのオブジェクトを見ると`inReplyTo`を持つ投稿と単にメンションを持つ投稿とでは特にaudience targetingに違いがないっぽい？
ところで、メンション先のアカウントが`Group`の場合はその`followers`コレクションを`cc`に入れるなんて挙動があったのか
Add basic support for group actors by noellabo · Pull Request #12071 · mastodon/mastodon
https://github.com/mastodon/mastodon/pull/12071
Thunderbirdが何やら起動後しばらくするとメモリを食い尽くしてハングするようになって困った
菜食主義の動物の殺生を禁ずる的なやつ、現代の動物も植物も生命であるという科学によって命に順位をつけてしまう主張になってしまったので道徳的優位性が損なわれてる
現代の科学を持ち出さずとも、西洋的な菜食主義の普及より以前から遅くとも細胞の発見の時点で植物の動物との類似性なんて知られていただろうし、それは初めからあまり問題ではなかったのでは。
一般的な卵乳菜食主義だって生命というよりはより限定的にsentienceとかを重視するからこそ（ヴィーガニズムなどと独立して）成立する立場だろうし（知らんけど）
いや、ヴィーガニズムも植物はsentient beingに含めていないだろうから比較対象としては不適か
BlueskyとかいうSNS、想定利用者層のリテラシーレベルを低めに設定していそうな雰囲気の割に、全員がほとんどのアクティビティを否認不可な形で公開するとかいうnostrみたいな上級者向け仕様なのが面白い
どうせデータの流れの末端ではJetstreamやAppView経由の未署名のレコードを信用する場合が多いなら、実際のところ否認不可性はどれだけ必要なものなのだろう。PDSすら信用しないという脅威モデルを取らない限りは、リレーとPDSの間のやり取りならTLSで十分だろうし
逆にFediverseはいい加減LD Signaturesをどうにかするべき（？）
そこらへんの馬の骨でも気軽に信頼性の高い魚拓を運用できるの、夢があるよね（？）。しかもおまけに`delete`の`repoOp`まで拾えるときた（？）
Introducing Mostr: a Fediverse Nostr bridge | Soapbox
https://soapbox.pub/blog/mostr-fediverse-nostr-bridge/
> Nostr is a better protocol, […]. It seems like only a matter of time until it overtakes the Fediverse, […]
へえ、そりゃ恐れ入った。より優れたプロトコルのネットワークの一員にしていただけて光栄でごさいまさあ
Copyrightの年度更新スパムプルリクエスト
https://zenn.dev/dalance/articles/7ecaf9369324c1
> 最終的には1/2の10時ごろにPR作成者のアカウントが削除され、その時点でPRも消えました。（本人が消したのか、運営が対応したのかは不明です）
単にアカウントが削除された場合は"ghost"によるPRになるはずだから、PR自体が404になっているということは凍結っぽいな。PRの削除は作成者本人でも行えないようだし
昔は凍結されたアカウントに表示するUIらしき`/suspended`というページ（<https://web.archive.org/web/20240715203519/https://github.com/suspended>）があったけど、今は単に`/`にリダイレクトされるようになっているのか（<https://github.com/suspended>）。
ちなみに@suspendedは実際に登録されているユーザ名なのだけど（<https://github.com/search?q=@suspended&type=users>）、自分のプロフィールページも開けなくて不便そう（？）
/suspended.keys で SSH keys 見えるかなと思ったけど駄目で、ちゃんと / にリダイレクトされた (?)
このアカウントは、notestockで公開設定になっていません。
まあそれはそうと過去に荒らしてたみたいなしょうもない属性で警戒してたら Jia Tan にサクッとやられますよ
貢献者の過去の行動が気になる気持ちは分からなくもないけど、あからさまに悪意のあるコードを取り込まないのもメンテナの責任の範囲内だろうし、プッシュ権限のない貢献者まで気にしていたらキリがないとも思う（"A user you’ve blocked has previously contributed to this repository."を眺めながら（？））
（この"A user you’ve blocked […]"は全く無関係のリポジトリの話）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
（ぶっちゃけ私も4段落くらいで既に自分の読解が追いつくのか不安を抱き始め、結局14段落くらいで脱落した）
非母語の文献のうち日常的に最も読む英語の技術系の文書やその他の説明文については大抵翻訳に頼らずとも労せず読める一方で、自力では文化的背景や言葉遊び等を読み解けない物語文では機械翻訳も当てにならないので、結果的に個人的に機械翻訳には用がないのだよな。
なので個人的な立ち位置としては、機械翻訳を含めたエーアイによる知的財産の利用の規制については別に良いんじゃないですか〜？ などと無責任なことを気軽に言える（？）。というか実際個人的に一番困るのが、商業水準の翻訳の衰退だし
まあ個人的に本当に欲しいのは翻訳というよりは、非母語話者にとって読みづらい文に注釈を入れてくれるような何かなのだけど
現存のツールで最もそれに近い機能を果たしているものは（自動）字幕かもしれない。これは読解の補助ではなく聞き取りの補助だけど
それはそれとして日本語と英語以外については注釈があろうが快適には読めない程度の習熟度しかないので、翻訳に頼るしかないわけだけど。
そしてそもそもその英語を習得しているのもある種の言語帝国主義的な不公正な環境の結果であるというのもそれはそう
そういえば、独学したプログラミング言語としてはCに次いで2番目に学んだRubyについても、日本語の公式ドキュメントの存在には助けられていた気がするな。
別に当時の語学力でも普通に他の言語の習得には不自由しなかっただろうけど（実際、当時未翻訳のTRPLを読みながらRustに入門したのも同じ年のうちだったはずだし）、参入障壁の違いのようなものはあったのかも知れない
`mastodon.social`は`momostr.pink`と`mostr.pub`をsuspendしているのか
テレスクリーンじゃん（「1984」以外の喩え方を知らない人（未読））
「Xのアルゴリズム」は数日であなたの政治的意見を変えられる――米スタンフォード大が1000人以上で検証：Innovative Tech - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2412/09/news046.html
ActivityPub サーバとクライアントの特殊化のミスマッチ - waf_thread
https://waf.nopth.ink/articles/0194335c-4be7-7f03-97be-e132bf56fdb2/
書いた
標準のC2S APIが普及したとしても、現状のActivity Streamsの枠組みだと受信者側でのコンテンツのフィルタリングが曲者そう。
現状でも`Note`と`Article`といった区別くらいはあるけど、例えば`Video`に加えて「ショート動画」のようなものは当然ながら標準では用意されていない。この例ではヒューリスティックに判定という手もあるかも知れないけど、そんなどのクライアントで何が見えるのかはっきりしない環境で発信者・受信者ともに嬉しいのか微妙そう。`"type": "ex:ShortVideo"`のようにアドホックな拡張型を用意する手もあるけど、今度はショート動画とその他の動画の区別を気にしないような受信者との互換性が問題になる。いずれにしても中央集権プラットフォーム（やAtmosphere）のように「ショート動画」が満たすべき解像度等の要件の合意を成立させるのは困難そう。
（ちなみにこういう場面で`"type": "ex:ShortVideo"`の対案としてよく提案される解決策として、`"type": ["Video", "ex:ShortVideo"]`のようないわゆるmulti-typeなオブジェクトがある）
ところでvidzyはどうしているのだろうと思って見てみたら、何じゃこりゃ……
AT Protocolでは割と積極的にAppView固有の語彙を作る風潮がある気がするけど、lexiconに対して少数のAppViewのみを想定したAtmosphereと比較して多様な独立した実装間の相互運用を尊んでいそう（ホンマか？）なFediverseにおいてはそこまでの割り切りは馴染まなそうというのが個人的な感想。
読書とアニメ視聴記録というユースケースがあるなら`my.skylights.rel`と`app.netlify.aniblue.status`を作るのがAtmosphereだとすれば、「作品とその閲覧と評価」のような共通項を見出して共有できる語彙は共有するのがFediverseっぽいというか（実際には例えばBookwyrm拡張は「本」しか想定していなそうだけど（`inReplyToBook`とか）……まあ、あくまで概念的な話として、はい）。
TwitterクライアントでRedditは見たくないけど、YouTubeでTikTokを観るくらいは（その逆を防ぐ仕組みさえあれば）良いんじゃね、的な
どうでも良いけど、`app.netlify.aniblue`ってびっくりNSIDだな。実際にそれでも困っていないのだろうけど、将来的にlexiconの解決とかが策定されたときにどうするのかとかは気になる。例によってatprotoエアプなので知らんけど
まあ何はともあれまずは成熟した汎用ActivityPubサーバが欲しいよなあ。実際のサーバを用意する前からあれこれ課題を想定するより実際に運用して問題にぶつかる方が楽しいだろうし（？）
個人的な感想、というか、普通にこれを引用すれば良い話だった：
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#activities
> When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type.
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#extensibility
> implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
（というかmulti-typeなオブジェクトは普通にMUSTな要件で言及されているレベルの事柄だったな）
いつでも内容が書き換わる可能性のある実際のサーバのオブジェクトへのリンクよりも、対応するソースコードへのリンクを張るべきだったな：
https://github.com/vidzy-social/vidzy/blob/1068f64f1264ebd0b8252d27b2ee4028790b19c7/app.py#L880-L906
QT: https://fedibird.com/@tesaguri/113773137545779149 [参照]
そういえばLoopsも`loops.video`上の1アカウントだけ連合を開放しているのだったな：
https://loops.video/v/2hltW5wx00
何の変哲もない`Note`だ（あと`Video`） [参照]
https://www.w3.org/TR/2018/REC-activitypub-20180123/#client-to-server-interactions
> If an Activity is submitted with a value in the `id` property, servers MUST ignore this and generate a new `id` for the Activity.
以前から思っていたけど、これ、クライアントサイドの署名と致命的に相性が悪いよね。実際FEP-ae97（Client-side activity signing）ではあえてこれを破っているし（<https://w3id.org/fep/ae97#sending-activities>）
しかしActivityPubが既存のWebサイトに適用するユースケースを重視している以上はサーバ実装固有のHTML表現のURL形式に引っ張られるのは避け得ないよなあとも思う。
いや、正確に言えばHTML表現のURIとActivity StreamsオブジェクトのURIの間で紐付けさえ出来るならAS側のIDがHTML側のURLと一致している必要はないだろうけど、いずれにしてもHTML表現のURLを`url`などでASオブジェクトから指したいことには変わりないし。……今からでもこの役割をWeb Linkingあたりに押し付けられません？（？）いや、これが署名の対象にならないのはやはりまずいか
雑に推敲しているうちにHTML表現の"URL"と"URI"が表記揺れしてしまった
ActivityPub: _misskey_contentがない投稿にはHTMLとしての処理だけを行うべき · Issue #15217 · misskey-dev/misskey
https://github.com/misskey-dev/misskey/issues/15217
MFMとして壊れないかみたいなことをいちいち気にしながら投稿するの、正直言って面倒くさいと思っている
Issueのタイトルの`_misskey_content`の表示が崩れるの、高度な皮肉か？（？）
しゅいろの投稿
syuilo@misskey.io
このアカウントは、notestockで公開設定になっていません。
こういう「困る」ケースを見つけて対応する方針なのだとしたら、かなり大変そうだなあ
microformat、 microdata よりさらにキツいやつなのでキツい
MicroformatsのRDFaに対する優位性をよく理解できていない
Microformatsといえば個人的にはIndieWebが使っているやつというくらいの印象しかないな
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ctx.
Musk steers X disputes to conservative Texas courts in service terms update | Elon Musk | The Guardian
https://www.theguardian.com/technology/2024/oct/17/elon-musk-x-terms-of-services-texas
(2024-10-17T23:13:40.000Z)
そして細かいけど、"President-elect"でなくあえて"President"と表記するのか
このアカウントは、notestockで公開設定になっていません。
"golden chains"とは何のことかと思ったら、プロフィール画像のことか
このアカウントは、notestockで公開設定になっていません。
このままcage fightもせずに自称D*GE（某暗号通貨の相場操縦の疑惑があるので伏字）の軍門に降るというのか！？（？）
巨大テック企業のあからさまな権力者への阿り、どこかで見たことがあるような気がしていたけど、あれか、既に中国とかでやっているやつ？
腐敗した権力による「腐敗撲滅」運動 » p2ptk[.]org
https://p2ptk.org/monopoly/antitrust/5021
今さらだけど、これについては正式に大統領になった後の予定の話と考えればまあ整合はするか。「次期大統領」の段階で何かをするつもりではないとも取れるだろうし。
そもそもこの観点で引き合いに出すなら<https://www.threads.net/@zuck/post/C9YovoOvisQ>や<https://www.threads.net/@zuck/post/DCCYlzUPKvy>の時点で十分だったか。特に当選後のはまだしも選挙前の投稿における表記は普通に意味が分からないし [参照]
このアカウントは、notestockで公開設定になっていません。
旧Twitterの取り柄の一つに充実したキーボードショートカット体系があるけれど、それで調子に乗って「`gnghjjjjjjjjjjjkjjjjjkkkgg`！！！」とかやるとGrokとかいうやつに飛ばされて最悪の気分になる（最近`gg`がGrokとかいうやつに割り当てられたらしい）
Fedibird（というかそのベースのMastodon）も一通りのショートカットを備えてはいるものの、旧Twitterはページを遷移して戻ってもフォーカスの位置が保たれたりと細かい部分の完成度が高いように感じる。
これでpinned Listsを切り替えるショートカットがあれば完璧なのだけど（有償でTweetDeckを使えという話なのかも知れない）
このアカウントは、notestockで公開設定になっていません。
Rust 1.84.0 has been released!🌈🦀✨
This release includes Cargo's new MSRV aware resolver, a new trait solver for checking coherence, new pointer provenance APIs and docs, integer square root methods, and more!
Check out the blog post and release notes: https://blog.rust-lang.org/2025/01/09/Rust-1.84.0.html
このアカウントは、notestockで公開設定になっていません。
共有参照に由来するポインタに対する書き込みがUBということを考えればそりゃそうか
このアカウントは、notestockで公開設定になっていません。
その本質からして不自由な中央集権プラットフォームから最低限モデレーションされているという体裁すら取ったら何が残るというのか
このアカウントは、notestockで公開設定になっていません。
スクリーンショットに映っているのは1つを除いて全てファーストパーティの``||events.bsky.app^`ドメイン決め打ちのフィルタのようだし、セルフホストが容易でドメインの拒否リストでブロックしようにもキリがないMastodonとの比較は不公平では
Some metrics by estrattonbailey · Pull Request #7294 · bluesky-social/social-app
https://github.com/bluesky-social/social-app/pull/7294
ちなみに、スタックトレースの当該部分のblameによるとこれっぽい
フロントガラスがバキバキに割れたiPadを直そうと半年以上前に購入したまま放置していたパチモンのデジタイザをようやく取り出し、6時間くらいかけて（なおiFixitによる想定所要時間は55分から2時間）元のデジタイザとLCD、ホームボタンを取り外したところで接着剤が足りないことに気づき、追加で注文したパチモンっぽいB-7000の配達でさらに10日以上の待ちが発生した。
外したデジタイザ等は戻してまた解体しなおすというのもアレなので、宙ぶらりんのままになっている
横着してろくにスペースを確保せずに作業していたこともあり、LCDの上にうっかりデジタイザを置くとかいう最悪のミスでLCDに一筋の傷が入ってしまった
作業時間のほとんどが、ダメージを入れることなくフロントガラスの接着を外すためのヒートガンの当て方のコツを掴むところで費やされていたので、もう一度やるならもっと速く作業できそうだけど、そもそももう一度やる必要なんて発生させるべきでないのでアレ
というか外して中身を見た感じだと、カメラとアンテナとディスプレイの配線とホームボタン周辺を除いて繊細な部品はあまり密集していないようだし、ヒートガンを当てるのにそこまで慎重にならなくても特に問題なかったのではないかという気がしている（実際にどうなのかは知らぬ）
`<*const T>::addr`がポインタからprovenanceを引っぺがしてアドレスを取り出すメソッドであるのに対して`ptr::addr_of!`が左辺値からprovenance付きのポインタを作るマクロなの、命名規則のブレを感じる
"Zero-Days" Without Incident - Compromising Angular via Expired npm Publisher Email Domains – The Hacker Blog
https://thehackerblog.com/zero-days-without-incident-compromising-angular-via-expired-npm-publisher-email-domains-7kZplW4x/
これはうっかりによる失効だろうけど、例えばドメインの所有者の死亡からの失効は気を付けたところで避け得ないよなあ
自分が死んだ後のコンテンツの保全とかまで面倒を見たいとは思わないけど（それはそれとしてIPFSとかはもっと流行っても良いと思うけど）、一方で自分が死んだ後に成りすまされて不正を働かれたりしたら死んでも死にきれない気がするので、ドメインを取得するならそのあたりの対策も考えておきたいな
現状のActivityPubはドメインを取られたらやりたい放題なのがなあ
オリジンに基づく認証も否認可能性を留保したい場合とかには有用だとは思っているけど、それはそれとしてFEP-ae97を使う場合とかにオプトアウトする選択肢もあった方が良いよなあ……とは思いつつも、アクティビティは署名できてもその副作用として生じるコレクションにまでは事前に署名するのは現実的でないだろうから、さてどうしたものか
コレクション、単なる静的なActivity StreamsオブジェクトとしてのそれとActivityPubの意味論におけるアクティビティの副作用から動的に計算されるそれという側面が存在してややこしい。
副作用という仕組みがあることで、例えば`Accept(Follow)`を観測したら`followers`コレクションを再取得しなくてもその差分を計算できるという利点があるわけだけど
ActivityPubがActivity Streamsの後付けで規定されていることによるものなのかも知れないけど、副作用というものの処理がアクティビティの種類ごとにいまいち一貫しないのが微妙な気がしている。
例えば`Follow`というアクティビティの`object`が`actor`の`following`というコレクションに対応していたり、`Like`というアクティビティとその`object`がそれぞれ`object`の`likes`というコレクションと`actor`の`liked`というコレクションと対応していたりといった具合で、場合によって何が（アクティビティ自体もしくは`object`）どのコレクションに追加されるのかがアドホックに規定されていて、副作用を計算するには事前にアクティビティごとに固有の意味論を把握しておく必要がある。これは特に未知の拡張の処理で困りそう。というか、`replies`コレクションの副作用に至ってはActivityPubで規定されていないし
それならむしろ副作用の方を主役として、`Add`と`Remove`と`Accept`と`Reject`で陽にコレクションを操作する意味論（<https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723/63>）の方が都合が良かったように思っている。これなら例えば操作対象のコレクションがリプライのコレクションであると知っていれば普通にリプライとして処理できるし、リプライという意味論を知らなくても一般のコレクションに対する操作にフォールバックできる。
ただ、そうすると今度は例えば`example.com/object/42/replies`のようなURIのみを与えられた場合にそれが何のオブジェクトとどのような関係を持つコレクションなのか（この場合は「`example.com/object/42`に対するリプライ」）が判定できないという問題があるので（<https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723/48>）、特定のオブジェクトと紐づくコレクションは（アクターの公開鍵について既に一般的に行われているように）大元のオブジェクトのURIにフラグメントを付したものにするという慣習だったら良かったのではと思っている。例えば`"replies": { "id": "https://example.com/object/42#replies", … }`のような感じで
仮定法で書かれていることからも分かるように、今からこうするべきと考えているわけではない
フラグメントを使ったとしても、コレクションのURIをいちいち記憶しておく必要が生じるという指摘の解決策にはならないか。コレクションのURIから大元のオブジェクトを特定するまではURIからフラグメントを外すという雑な変換処理でも可能かも知れないけど、`replies`のような関係性の特定については参照外しするかキャッシュを引っ張る必要があるわけで
しかしコレクションのURIの指定を求めるとなると、対象のオブジェクトがそもそも該当するコレクションを持たない場合に表現が不能になるという問題があるか。
これはサポートしない操作を拒否できる能力という利点とも取れなくもないけど、現行の副作用を伴うあらゆる操作についてそのような能力の存在が嬉しいのかは疑問が残るな。例えばリプライ制御のユースケースのうち「あらゆるリプライの拒否」という意思表示についてはこの仕組みで自動的に解決されるとも考えられるけど、一方でデマの指摘のように宛先人が拒否することを承知でリプライを表明するということが不能になる。
まあこの例の場合はリプライでなく（コレクションへの追加を伴わない）「引用」でやりええという立場もあり得るか？ うーん
そもそも未知の拡張の副作用を扱えないことの何が困るかというと、拡張の可用性がサーバによる実装状況に依存することでサーバを透過的に扱いづらくなることだがあると思う。副作用がサーバによらず統一的に処理されたならば、拡張の解釈は送信側と受信側のクライアントの実装間の合意によって完結できただろうと考えられるので
特定のFEPの組み合わせであるアクティビティの副作用がTuring完全になる回（存在しない回）
毎度のJSONやめてバイナリにしたいだのMisskeyはMisskeyとだけ連合する方が幸せになる可能性があるだのの発言が実行に移されたためしは無いけど（失礼）、今回は文脈抜きで英語圏にまで拡散していてアレ
まあ今回のThe Fediverse Reportについては正直Hof氏の持論の引き合いに出されているという側面が強いような気がするけど
そういえばドイツにおけるgGmbhの立場を取り上げられていたのだったか
結びが「Join Mastodon.（`mastodon.social`のサインアップページへのリンク）」なのがいまいち締まらないな（？）
Today Mastodon is taking another step towards its founding ideals: independence and non-profit ownership. We're transferring ownership of key assets to a new, European not-for-profit entity, ensuring our mission remains true to a decentralised social web, not corporate control. #MastodonNonProfit
https://blog.joinmastodon.org/2025/01/the-people-should-own-the-town-square/
このアカウントは、notestockで公開設定になっていません。
winnow::_tutorial::chapter_0 - Rust
https://docs.rs/winnow/latest/winnow/_tutorial/chapter_0/index.html
チュートリアルが docs.rs にあるパターンなどもある
ブログをクレートにすることでサンプルコードに対してdoc testが実行できる！
の投稿
maia@crimew.gay
このアカウントは、notestockで公開設定になっていません。
かなり粗末な陰謀論だとは思っていたけど、実在のDittmann氏らしき人物が見つかっていたのか
の投稿
maia@crimew.gayこのアカウントは、notestockで公開設定になっていません。
の投稿
maia@crimew.gayこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
比喩を適切に調整するのが面倒だから不適切な喩えのまま書くと、これまで中央集権プラットフォーム残っていたような人々が求めるのが自由より統制された檻だったとしても別に突飛な発想ではないように思う。
発言を削除するのでなく文脈を付加する類のファクトチェックがそもそも検閲の定義を満たすのかについてはさておくとしても
「倫理的なWebの原則」と入力しようとして誤って「倫理的なWebのげんくそ」と入力してしまい全てがどうでも良くなった（？）
ブリッジへの言及があるけど、A New Socialとの関係はどうするつもりなのか気になる
本当に「検閲が無くなる」のだったらそれも一つのあり方だったかもしれないけど、実際に起こっているのはPixelfedなどの競合プラットフォームへの言及の規制だったりして、要はモデレーションは面倒だけど利益になると判断した検閲はなりふり構わず行っているだけなわけで……
ブリッジ、せっかくPDSがあってもブリッジのためのレコードしか書き込めないのでは正直面白味が微妙だけど、かといってActivityPub側の`outbox`に好き放題アクティビティを突っ込めない現状でAT Protocol側のPDSに好き放題レコードを詰め込めても仕方がないだろうしなあ
仮にAP側にまともにSocial APIを実装したとしても各種アクティビティとlexiconの間に割り当てるべき対応関係が非自明だし、というかPDSには`inbox`相当の仕組みが無いのでその違いの扱いもややこしそう
アイデンティティについても、真面目にDIDを共有したりしようとするとFediverse/atprotoの両者で合意できそうなメソッドが今のところ`did:web`くらいしかなさそうなのがまた微妙だな……
@kussy_tessy ははは、今は隠し機能っていうかテスト運用しかしてないんだけども、
フォローしてる人のアカウントカラムを最後まで遡ると、追加取得ボタンがあるよ。
これってFedibird固有の機能だったのか。いや、まあupstreamは<https://github.com/mastodon/mastodon/issues/34>がopenだし、それもそうか
このアカウントは、notestockで公開設定になっていません。
Misskeyのように`Like`をフォロワーに送りつけるフォロイーがいるのなら、愚直に実装するなら`inbox`にそれらの`Like`を貯めるのが正しいということになるのだよな。さながら旧TweetDeckのActivityカラムのような感じだろうか
ちょっと言葉足らずだった気がするけど、`inbox`に`POST`するのは今もごく当たり前に行われていることであって、それに対してここで想像していたのは`inbox`に対する`GET`への応答にそれらの`Like`を含めるといった挙動の話
FOFの<del>あの`margin: 0px; padding: 0px;`の謎レイアウトの</del>公開状にDoctorow氏が署名しているのがちょっと意外に感じたけど、氏は"there's *still* no fire exits on Bluesky"（<https://pluralistic.net/2024/12/14/fire-exits/>; 強調は引用者）という意見だったから、後は"fire exit"を追加するだけで良いという考えだろうか
というかpluralistic.net、場合によってJavaScriptとCookieを要求する？ ページを開くとdeflectなる何かが"Please turn on JavaScript and reload the page."などと表示してくることがある。"no ads, trackers, or data-collection"だったはずでは？（うるせえ）
ああ、最新の記事（<https://pluralistic.net/2025/01/14/contesting-popularity/>）で普通に"We can install our own fire-exits in Bluesky."と主張されているな
個人的にはshared pileをダブらせたところで独占が寡占になるだけで、一定の意義はあるものの根本的な解決にはならないように思うのだけど
みんなの手でshared pileをまとめる新しい郵便局を建てようというのは実に結構なことだけど、よしんばその郵便局の運営に「みんな」の意思が最大限適切に反映されたとしてそれはマクロな事象でしかなく、そのミクロな構成要素であるところの「私」の意思が有意に影響を及ぼせるとは限らないしなあ。結局は全体の意思が自分の意思と相容れなかったらお終いという問題は解消されない。
とはいえ現実の民主主義制だってそんなものだけど、別にこのインターネットの場においてまで国家の資源の集約と分配をモデルにする必要はないわけで。ここは物理的な距離に縛られないインターネットなのだから、郵便局なんて建てずに素直に相手の家の郵便受けに直接投函しにいけば良い
<https://dustycloud.org/blog/how-decentralized-is-bluesky/>は必読なので（？）、この記事で使われた"post office"などの比喩は特に断りなく流用するものとする
Bridgy Fedに微妙なところで打ち切られそうな文だなあと思いながら投稿していたのだけど、実際冒頭の"shared"の部分で打ち切られているな（<at://did:plc:lffon5yhpjy26636i2xjl6as/app.bsky.feed.post/3lfqgumo2gj42>）
QT: https://fedibird.com/@tesaguri/113829383265936570 [参照]
一人の金持ちによる支配というのは単なる（極端な）一例に過ぎなくて、本質的には金持ちだろうが合議だろうが関係なく、個人の制御が及ばないところに問題意識があるのかも知れない
"Pile"じゃなくて"heap"だったわガハハ（ｽﾞｺｰ）
Idea: Annotations / Labeling of content · Issue #4 · swicg/activitypub-trust-and-safety
https://github.com/swicg/activitypub-trust-and-safety/issues/4
既知の権威を購読するようなファクトチェックならまだしも、匿名の意見の集計の上に成り立つコミュニティノート的な仕組みは正直ActivityPubに馴染まないように思うのだよな
まあ中央集権的なサービスでも別に真に匿名でないことには違いないけど、かと言ってそこら辺のセルフホストのノードとそれらが同じかというと、少なくとも一般的な捉え方とは言い難いだろう。
というか非中央集権ネットワークでは自らが選択したノードとその他のノードではある程度信頼度が違って、一方で中央集権プラットフォームでは選択の余地がないだけでプラットフォーム自体が前者に相当する地位にあると言えなくもないだろうし
Blueskyのために作ったアカウントをそのまま他のAT Protocolのサービスに使えるというのはやはりonboardingの面で強そう。ActivityPubのエコシステムもC2Sのサポートがもっと普及していたらなあ（いつもの）
では例えばWhiteWindとかは実際どうなのかというと、ぱっと見atprotoオタクばかり集まっているような印象があるけど（失礼）。
旗艦のWebクライアントのトップページに集約した記事を並べられると、初期に形成された雰囲気のようなものから外れた記事を投稿しづらくなるみたいなところがありそう。丁度こちらでいうところの各サーバのローカルタイムラインのように。知らんけど
今はPixelfedが強そうだけど、今後どうなるのかね。私はInstagramも使ったことがないので個人的には特に関係ないけど
逆にまだPDSにアカウントを持っていない場合は……ここでBlueskyに誘導してonboardingに余計なステップを挟むことを厭ったAppViewの胴元が自前でPDSを用意したりすればPDSの分散のインセンティブになるか？ 知らんけど
PDSレベルのモデレーションに責任を持ちたい開発者がどれほどいるのかがアレかな（アレとは）
We just released Mastodon 4.3.3, 4.2.15 and 4.1.22. Tmastoadminn a few bug fixes as well as a security fix (medium severity, https://github.com/mastodon/mastodon/security/advisories/GHSA-5wxh-3p65-r4g6)
We recommend every instance administrator to update as soon as possible.
If you are using our nightly releases, a container image with the fix has been published with the `nightly.2025-01-17-security` tag.
Full release notes and update instructions are available on our GitHub release page: https://github.com/mastodon/mastodon/releases/
リリースノートで言及しているGHSAを公開状態にしてからリリースしてもろて
Partial Denial of Service due to insufficient validation of remote actors · Advisory · mastodon/mastodon
https://github.com/mastodon/mastodon/security/advisories/GHSA-5wxh-3p65-r4g6
このアカウントは、notestockで公開設定になっていません。
API v2から晴れて（？）"Tweet"が正式名称になっている。"Status"はもはやURLに名残が残っているのみ。
あーん、わざわざ`developer.twitter.com/en/docs/twitter-api`でリンクしたのにリダイレクトで書き換えられている（？）
このアカウントは、notestockで公開設定になっていません。
対応している拡張の交渉云々についてはこれに尽きると思っている
対応している拡張をサーバに宣言させるのはSocial APIをまともに実装した汎用のActivityPubサーバのようなものとも相性が悪そう（最近この話ばかりしているな）
大前提としてNodeInfoの`software.name`で何かを判断しようとするなというのはそれはそう
"ActivityPub"サーバとしては`inbox`に届いたアクティビティを概ねそのままクライアントに見せるだけであって、引用だのリアクションだのといったものに対してサーバレベルで特別な解釈をするとすればそれはActivityPubでなくMastodon API等のサーバに属する性質なのではないだろうか。つまり、NodeInfoより`GET /api/v2/instance`とかの領分な気がする（そもそもActivityPubはNodeInfoというプロトコルの存在についても特に認知はしていないわけだけど、それはそれとして）
fedibird:references のように副作用でコレクションに追加されるみたいな拡張機能であればまぁActivityPub拡張の対応等にはなるかもしれない
引用もリアクションも特にActivityPub上の副作用を持たないという想定で書いていたけど、そういえばFedibirdがいたな……
`fedibird:references`コレクションについては確かオブジェクトに付いた参照でなくオブジェクト自身が他のオブジェクトに対して持つ参照のコレクションだったから関係ないと思うけど、`fedibird:emojiReactions`コレクションは受け取ったリアクションが副作用として追加されるものだから、思い切り該当する
better service landing pages by bnewbold · Pull Request #2959 · bluesky-social/atproto
https://github.com/bluesky-social/atproto/pull/2959
プレーンテキストのアスキーアートはアクセシビリティが悪いからHTMLにしたほうが良いのではなどと横槍を入れていたものの、華麗にスルーされたね（？）
Fediverseにおけるデータの可搬性は、寄り合い所帯サーバの運営者の誠実性が信用できないからというよりは、寄り合い世帯・自前ともにサービスの継続が不能になった場合に備えたバックアップとしての有用性が大きそうな気がしている
ロックインついてはそれなりにコストはかかるもののセルフホストで十分に回避できるし、そうでなくともサーバの選択肢だけは多いので
今 archive.org 上で表示してるアーカイブのページ内にあるログインフォームに archive.org のログインIDとパスワードが自動入力されて怖～となった (とりあえず Bitwarden で該当の認証情報の自動入力を off にした)
そもそもWayback Machineがクライアント側でJavaScriptを実行するのはどういうセキュリティモデルなのだろう
今さらだけど、話題のFlashesはサービスというよりは単なるBlueskyクライアントか。まあFlashesの話とは明言していないのでセーフということで（？）
QT: https://fedibird.com/@tesaguri/113835943890296396 [参照]
このアカウントは、notestockで公開設定になっていません。
しかしそれっぽいドメインまで取得しているのに、実行させようとしているコマンドが明らかに本物のそれよりゴテゴテしていていかにも怪しげのは何故なのか
ログインとかするわけでもないのにCookieを拒否しただけで壊れるサイトを禁止してくれEU〜
それはそれとしてCookieを拒否すると`window.localStorage`とかのゲッターが例外を飛ばす仕様もアレだけど
Mozilla Developer NetworkとかいうサイトすらCookieを拒否すると検索ページが壊れるので、最早この世に救いはない（？）
About MDN
https://developer.mozilla.org/en-US/about
そういえばこのページすら"MDN"が何の略であるかとか述べていないし、もしかして今はMDNって正式には何の略称でもなかったりする？
Mozilla Developer Network の略でMDNだったけどもはやMDNは"MDN"だよみたいなこと言ってる？
“Mozilla Developer Network” simply isn’t accurate. Furthermore, pretty much no one refers to MDN as “Mozilla Developer Network.” It’s always “MDN.” However, there is a lot of love for the name “MDN” and we don’t want to get rid of all of that, which is why we’re giving it the IBM / KFC treatment and keeping the iconic abbreviation and commonly used name, while no longer using the words that the acronym used to stand for. We’re not getting rid of MDN, we’re being clear about what it is – it’s MDN Web Docs.
The Future of MDN: A Focus on Web Docs - Mozilla Open Design https://blog.mozilla.org/opendesign/future-mdn-focus-web-docs/
🐾の投稿
torighang@misskey.io
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://www.kaikatsu.jp/info/detail/ddos.html
当初は公式に「原因：DDoS攻撃によるネットワーク輻輳」とされていたっぽい
分散かはともかく、サービス拒否を伴う不正アクセスというのはどういうものがあるのだろう
TikTok、そもそも1期目に自身に対する規制を進め始めた大統領の2期目でご機嫌を取らなくてはならないの普通に可哀想
このアカウントは、notestockで公開設定になっていません。
Gitの既定ブランチについては当初はGit公式の`init.defaultBranch`の既定値が変わってから追従するつもりだったな。しかし考えてみると`init.defaultBranch`の設定が追加された時点で好むと好まざるとにかかわらず既に既定ブランチというのは`master`であるという前提は崩れていて、機械処理においてはきちんと`HEAD`などを指すべきだし、となると既定ブランチというのはもはや人間のためのラベルに過ぎないわけで、どうせ人間のためのラベルなら人間にとって当たり障りのない表現の方が良いかということで結局`init.defaultBranch = main`にしている
他国の過去の奴隷制のツケを当然のように支払わされることに思うところがないわけでもないけど、現実に影響を受けている人がいるのだとしたら仕方ないし
それはそれとして、ならばついでに例えばnukeとかいう言葉もやめてくれないかなとか思ったりはするけど
`List-Unsubscribe`の無いマーケティングメールを禁止してくれEU〜（何でもかんでもEUに禁止させようとする）
細谷氏が荒らしであるという陰謀論の「根拠」のうち最有力とされていたのが：
- 荒らしのTwitterのメールアドレスが`ke***********@outlook.jp`だった
- これが`kemonofriends@outlook.jp`であるという仮定のもとでOutlookのパスワードリセットを試みたところ、所有者の電話番号の末尾がXXだった
- 細谷氏のFacebookアカウントにパスワードリセットを試みたところ同氏の電話番号の末尾もXXだった
という、仮にメールアドレスの仮定が正しかったとしても100分の1くらいの確率で冤罪を引くアレだったわけだけど、そもそもそのメールアドレスの仮定からして間違っていたことが判明している。というのも、Twitterにて連絡先インポートで`kemonofriends@outlook.jp`の所有者のTwitterアカウントを探したところ、荒らしとは別の、2017年に登録された無関係そうなアカウントだったという結果が出ているので
QT: https://misskey.io/notes/a3cs29xbr9nd0af0 [参照]
まさか5年も経ってこの陰謀論の話を目にするとは思わなかったな
Adversarial interoperability = PvP相互運用性
北朝鮮はとっくにRed Star OSでデスクトップLinux元年を迎えているというのに、西側のこの体たらくは何だ
Red Star OSのバイナリを持っている人はGPLに基づいてソースコードの開示を請求できるのだろうか
の投稿
lynnesbian@fedi.lynnesbian.space
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
「サイコパス」とかもそうだけど、本来は「メンヘラ」もあんなにカジュアルにレッテルとして使うべき言葉ではないよなあ。
辛うじて「サイコパス」などと違うところがあるとすれば、精神保健的な困難を抱える当事者自身による謙遜的な言及としてなら成立しうるかも知れないという点くらいだろうか（それをアイデンティティ化することが精神保健上望ましいかの議論はさておくとして）
特定のオブジェクトと関連して副作用として生じるコレクションをフラグメント付きURIをもつオブジェクトとして元のオブジェクトに埋め込むの、筋の良いアイデアのように思っていたけど、`totalItems`が副作用で変化するからオブジェクトの署名と致命的に相性が悪いな。うーむ
QT: https://fedibird.com/@tesaguri/113810078390191293 [参照]
というかそもそもActivity StreamsのオブジェクトにActivityPubの副作用として生じるコレクションのURIを書く時点でクライアントがどうするべきか非自明なのだけど。
ActivityPubとしてはクライアントが指定した`id`をサーバが上書きすることは規定しているけど、その他のコレクションについては特に言及していない（Primer <https://www.w3.org/wiki/ActivityPub/Primer/Server-Managed_Collections>で`Update`で変更しないように推奨していて、これが`Create`についても準用されるとも考えられるかも知れないけど）。しかし実際にこれらにクライアント側で任意のURIを指定されたら困るサーバ実装が多いのでは
まあ個人的にはそもそもあらゆるユーザがあらゆるオブジェクトに署名する必要が本当にあるのかとも思っているけど。特に、DIDがアクターオブジェクトを署名する必要があるのは当然として、そのアクターオブジェクトが指定するサーバがサーブするオブジェクトにも署名する必要性がよく分かっていない。
サーバがDIDのコントローラに成りすましてオブジェクトを生成するシナリオもまあ想定可能ではあるけど、万人にとって全てのオブジェクトを否認不可にしてまで防ぐべきシナリオなのかと思わないでもない
署名済みのダイレクトメッセージを否認不可な形で晒し合う修羅の世を見たくないかといえば……いや、普通に見たくはないな（？）
そもそもこのシナリオはサーバに鍵を預ける運用ではあまり意味のない想定だし
FediDBは結局`threads.net`を統計から除外したのか。しかしまだ連合が開放されていない`loops.video`は入っているのか
Threadsにおける連合していないアカウントと、その他のサーバにおけるいわゆる鍵アカウント的な運用のアカウントの間に、外部から見たときの違いがどれほどあるのかというのは疑問に思わないでもない
「Fediverseのサーバ」としての評価においてはともかく、アカウントのポピュラーさという観点では例えばPOTUSのフォロワーの多くが連合していなかったとしてもPOTUSがポピュラーであることに変わりはないよね、的な話
いつの間にか`rust-tools.nvim`のメンテナンスが止まって順当にアクティブなフォークが生えていたけど、それに先立ってNeovim 0.10でLSPのinlay hintのネイティブ対応が入っていたので、じゃあそもそも個人的にあえて`rust-tools`を使う理由ももう無いなとなり、移行するのでなく素の`lspconfig`に戻すなどした
`#![deny(warnings)]`でなおかつClippyが通らないコードベース、困る
デフォルト有効の`deny_warnings`リントが求められる（？）
@lo48576 ありがとうございます。普通ならそうするところですが、今回はちょっとしたPRを投げるために手を入れているだけのコードなので、CIについてわざわざ口を出すのも正直面倒、もとい気が引けるのですよね……
@tesaguri Lint Levels - The rustc book
https://doc.rust-lang.org/rustc/lints/levels.html#expect
#![expect(warnings)] とかでどうでしょう。
Rust 1.81 https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#expectlint で導入された lint level です
Add limited clippy to CI · Issue #2977 · hyperium/hyper
https://github.com/hyperium/hyper/issues/2977
`#![deny(warnings)]`する程度には潔癖なのにCIでClippyを走らせないのは不思議なので、ひょっとすると見落としかとも思ったけど、意図的か……
`clippy::pedantic`を`rust-analyzer.diagnostics.warningsAsInfo`で控えめに表示させているのだけど、`#![deny(warnings)]`をされるとrust-analyzerがinfoに変換する前に全てエラー扱いになって開発体験がオワる
NitrokeyのAdmin PINをアレしたので`nitropy nk3 factory-reset`をかけたら、何か例外を吐いたものの一応リセットはされたっぽいという非常に微妙な挙動をしている
PINをアレしたのはセットアップ作業中のことなので、鍵の喪失などには至っていない……が、先行きは怪しすぎる
教訓としては、`gpg --edit-card`等ではPINの誤入力でも単に"Error"としか出力されないことがあるので、一時的なエラーかと思って同じ入力を繰り返しているとそのままロックされかねないということですね、はい
gpg: update primary key · tesaguri/dotfiles@ddc8409
https://github.com/tesaguri/dotfiles/commit/ddc8409f137a6aeccd7c8e4e2479a03e5102fae1
Nitrokeyを調達してから、ええと、何週間経ったか……とにかく、ようやく鍵を新調したり何なりの設定が完了した
"Initial commit"するならどうせなら綺麗な鍵で署名したいよななどという理由で鍵を設定していたら、"Initial commit"することなく一日が終わった
この黒魔術がCurve25519の鍵に通用しなかったので代わりの方法を探るのに時間がかかった。結論としては、<https://dev.gnupg.org/T5110#183785>の方法で`addkey`することで指紋を保ったまま主鍵を別の主鍵の副鍵として追加できるらしい。"Existing key"でkeygripをを使いまわせることは知っていたけど、`--faked-system-time`で指紋も保てるのね。
しかしこれだけだとbinding signatureの時刻が矛盾しているせいかusageが空の副鍵として認識されるようになってしまうので、`--ignore-valid-from --ignore-time-conflict --edit-key`で`change-usage`することで何か良い感じにする必要がある（本当にそれで問題ないのか？？？）
QT: https://fedibird.com/@tesaguri/112535898825987759 [参照]
予備key（ただしYubiKeyでなくNitrokey）に鍵をバックアップする関係から完全に清潔とは言い切れない環境で生成することになってしまったけど、今までの鍵より1024倍は綺麗だろうから良しとする
SKS Keyserver Poolが終了して久しいけど、`pgp.mit.edu`は何かずっと応答しないし`keys.openpgp.org`も"Under construction as of 2019-06-07"とか言っているし、鍵サーバのエコシステムが心許ない
このアカウントは、notestockで公開設定になっていません。
このレベルの放言が例えばLemmer-Webber氏の例の記事などより拡散されているの、まあ大衆ってそういうものだよねというだけの話ではあるのだけど、やはり何だかなあ
データの流れが少数のノードに依存する構造であるというのはその通りとして、その設計意図が企業による支配にあるかのような表現は普通に筋の悪い憶測でしかないし。わざわざ存在の怪しい悪意なんて仮定せずとも、実態として寡占のリスクが高いといった程度の表現で十分なわけで
まあ通信プロトコルとしての分散性についての批判としては概ね良いとしても、ストレージシステムとしての分散性についての検討を省いているのはAT Protocolに対する評価としては不十分に思う。この観点ではFediverseはとてもAtmosphereを揶揄ってなんていられない現状だし（ただし例によってPLCの分散性を仮定した場合の話）
というか図中のCORPORATION同士の双方向の繋がりは何を表そうとしているのか普通に汲み取れない。そしてFediverseもこんな平均頂点間距離が発散しそうな（？）トポロジーだとしたら使い物にならないでしょ。
（これは揚げ足取り気味ではあるものの、実際に下手したらデータが発信元のサーバの協力なしに何ホップにもわたって転送されるかのような誤解を与えかねない図ではある）
それはそれとしてnon-archival relayはそこまで高コストでないという反論（<https://indieweb.social/@laurenshof/113901014672558283>）については、ソーシャルメディアとしての機能が高コストな集約に依存しているという主張として汲むなら単にAppViewも含めるものと読み替えれば良いだけの話だし、そこまで本質的でないような。これらを一まとめにBGSとでも指せば良かったか？（？） [参照]
このアカウントは、notestockで公開設定になっていません。
「ソーシャルメディアとしての」というか、より厳密にはリプライなどの通知を伴うようなコミュニケーションの機能とでもいうべきか。特定のユーザの投稿を購読するだけならPDSを直接叩き続ければ良いだけなので
Agent PKSIGN (Using the GNU Privacy Guard)
https://www.gnupg.org/documentation/manuals/gnupg/Agent-PKSIGN.html
これは生の暗号プリミティブによる署名と同様の結果を得られるのだろうか。例えば、Verifiable Credentialsにも使えたりする？
スマートカードでActivity Streamsオブジェクトを署名してみてえ〜（謎の欲求）
一方の`did:plc`は今のところsecp256k1とNIST P-256しか対応していないようなので、少なくとも手持ちのEd25519の鍵では無理そうである
@aumetra tbh a fraction of me is convinced by that conspiracy theory around NSA and NIST curves
https://x.com/davidtolnay/status/1883906113428676938 #tw
何のために Rust 使ってんねん案件だ……
https://twitter.com/davidtolnay/status/1883906113428676938
依存しているライブラリの保守が止まってそのフォークが現れたときに、単に何らかの保守が行われているっぽいというだけの理由で深く吟味せずにフォークを採用するという判断をしたことがなかったと問われると自信がないので、あまり他人事でないな
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
男性同性愛に紐付けて例えば「汚い」や「嘘つき」などの表現が共起するような符牒である上に、その果てに出演者の個人情報の特定や社会的地位の毀損などが行われていたという背景があるので、通じなければ良いというのも矮小化かなあと
まあ件の「ミーム」と主張されている語彙の中には文脈抜きでは一般的な日本語表現でしかないようなものも含まれているから、仮にそういうものが偶然に被った、あるいはネットミーム的な意識があったとしても来歴について無知だったような場合にまで批判されているのだととすれば焦点がズレているようにも思うけど（ただし広報などの場面では後者も職責として意識されるべき範囲ではある）、本件については文脈について自覚的でなければ意味をなさない表現だし、公僕としては批判されて当然かと
SocialHub Community Values Policy - Community / SocialHub Policy - SocialHub
https://socialhub.activitypub.rocks/t/socialhub-community-values-policy/1391
今さら軽く目を通したけど、これは、うーむ……
個人の行為が対象だったならばまあせやなという感じだっただろうけど、"project"が対象となると<https://socialhub.activitypub.rocks/t/policy-proposal-socialhub-community-values/1453/9>のような解釈の余地が気になってくるよな。このコメント自体は<https://socialhub.activitypub.rocks/t/policy-proposal-socialhub-community-values/1453/54>で解決しているようだけど
"CIDs v1.0 is a W3C Candidate Recommendation"という文字列を見てContent Identifiersかと思ったらControlled Identifiersだった（？）
Controlled Identifiers (CIDs) v1.0
https://www.w3.org/TR/2025/CR-cid-1.0-20250130/
Multibaseとかいうやつ、要はbase32やbase36、base64、base58とか色んな基数と文字集合の変種があるからそれらに識別子を振って全てサポートできるようにしよう仕組みで、それ下流の仕様でちゃんと書式をただ一つに指定できていたら不要な仕組みだったのではと思ってしまう
