Graber のドヤ顔インタビュー記事の翻訳が流れてきたので思い出した。
https://wired.jp/article/sz-vol57-jay-graber-the-big-interview/
Bluesky の集権性を指摘するブログ記事が出たのが2024年11月。
https://dustycloud.org/blog/how-decentralized-is-bluesky/
それから現在までで ATProto に本質的な変化があったかというとそんなことはない。初期設計に規定された部分が大きく、後から変えられる余地も限られている。
興味の中心は、Bluesky という組織が敵対的になったときに利用者に何ができて何ができないか。デフォルト設定のままの場合と利用者が注意深く事前準備する場合にわけて、いろんなシナリオを検討してみた。
結局のところデフォルト設定だと Bluesky がやりたい放題できて利用者がほとんど抵抗できない。
一方で、注意深く事前準備するとアカウントとデータを防衛できる範囲は小さくない。しかし、Bluesky でそこまで頑張るのであれば、とっつきにくさに目をつぶって Nostr を選ぶほうがトータルコストが低そう。
ATProto では (ActivityPub と同様に) 利用者 (のデータ) はいずれかのサーバにホストされることになり、そこが検閲の急所になる。ホストの中核が PDS (Personal Data Server)。もし Bluesky が PDS レベルでアカウントを停止させた場合、事前対策をとっていない普通の利用者にはほぼ何もできない。
Bluesky 開発者は2025年9月のブログ記事でアカウント停止を PDS ではなくアプリレベルで行うように改めると言っている。
https://pfrazee.leaflet.pub/3lz4sgu7iec2k
このような運用上の方針は外部からの検証が難しい。最終的にどこまで信用するかという非技術的な要素が残る。
それに、legal/network-abuse の理由では引き続き PDS レベルで停止させると述べている。この legal が曲者。例えばブラジルの裁判所があなたのアカウントを PDS レベルで停止させろと言ってくるというのは現実的なリスク。
Nostr の仕組みがまだそんなにわかっていない。素朴な疑問は非集権性にまとわりつく諸問題が解決できているのか。
Bluesky の集権性を指摘するブログ記事が参考になった。https://dustycloud.org/blog/how-decentralized-is-bluesky/
ざっくりと前半はコンテンツ集約、後半は識別子の問題。
識別子については Nostr は公開鍵を採用していて、Bluesky の手法の議論は当てはまらない。公開鍵識別子は人間にとって意味をなさず、万人受けしない。
コンテンツ集約は RSS フィード以上の機能、例えば検索や推薦や実時間通知を連合型でどう実現するかの問題。結局魔法の解決策はないし、Bluesky は集権性を採用して解決しているとのこと。
Graber のドヤ顔インタビュー記事の翻訳が流れてきたので思い出した。
https://wired.jp/article/sz-vol57-jay-graber-the-big-interview/
Bluesky の集権性を指摘するブログ記事が出たのが2024年11月。
https://dustycloud.org/blog/how-decentralized-is-bluesky/
それから現在までで ATProto に本質的な変化があったかというとそんなことはない。初期設計に規定された部分が大きく、後から変えられる余地も限られている。
興味の中心は、Bluesky という組織が敵対的になったときに利用者に何ができて何ができないか。デフォルト設定のままの場合と利用者が注意深く事前準備する場合にわけて、いろんなシナリオを検討してみた。
結局のところデフォルト設定だと Bluesky がやりたい放題できて利用者がほとんど抵抗できない。
一方で、注意深く事前準備するとアカウントとデータを防衛できる範囲は小さくない。しかし、Bluesky でそこまで頑張るのであれば、とっつきにくさに目をつぶって Nostr を選ぶほうがトータルコストが低そう。
年末年始に重い腰を上げて、学生さんのおすすめに従って Python のパッケージ管理を poetry から uv に変えた。たしかに爆速になった。
uv はプロジェクト直下に .venv を作る。コードを home に置いているので home が肥大化しがち。この振る舞いを変更するにはプロジェクトごとにUV_PROJECT_ENVIRONMENT という環境変数を設定する必要があるらしく、ちょっとめんどくさい。
Abu Dhabi に Mohamed bin Zayed University of Artificial Intelligence（MBZUAI）という、文字通りの石油王大学があって、うちの業界の人間もどんどん吸い込まれている。
最近、UAEという国の、というか実質 Abu Dhabi の政治的にヤバすぎる動きが表面化する出来事が多い。ソマリランド、イエメンの STC など。このタイミングで、欧州での情報工作 (2023年に暴露された Abu Dhabi Secrets) を蒸し返す投稿が X で目に付く。うちの業界の研究者は何の興味もなさそうだけど。
いろいろありすぎて感覚が麻痺しているけど、イラン情勢の悪化が急すぎる。
relay.nostr.band が機能していないのは SSL 証明書の期限切れが原因だから、そのうち回復すると思っていたけど、一向にその気配がない。
Windows Event Viewer を見ると、isar.dll が STATUS_STACK_BUFFER_OVERRUN (0xc0000409) で落ちていた。
誤って Nostrmo を二重起動している間に Isar DB が壊れた可能性が高い。Isar DB は複数プロセスで共有して使うことを想定していないらしい。
DB ファイルを削除して Nostrmo を再起動したら再び安定した。
Android/iOS だと通常は二重起動にはならないはずなので、デスクトップ版固有の罠っぽい。起動時に single instance チェックを入れるべきなのだろう。
Windows 上の Nostrmo 3.4.0 がちょくちょく落ちるようになった。原因を突き止めるのがめんどくさそうで困ったな。
https://quillette.com/2025/12/09/public-execution-and-masculine-virtue-capital-punishment/
X での米国右派の振る舞いを vice-signalling (英国式の綴りだ) とよんでいる。virtue signaling のもじり。
Today, toughness, cruelty, and transgression are all performed to demonstrate belonging. It is 2020 Twitter, but inverted.
この種の言語機能は扱いが難しい。集団の傾向としては確かに存在しそうだが、個人や個別の発言に対してこういう判定をやりだすと魔女狩りになる。
昨日は short text note の投稿直後にタイポに気づいたので、Nostr を始めて以来2度目の削除を試してみた。改めて仕様を確認したが、Nostr の性質上しかたないとはいえ、微妙な仕組み。
- relay が NIP-09 (kind:5) を実装しているとは限らない
- すでに拡散・キャッシュされているなどの理由からも完全には消えない
- kind:5 は ephemeral ではなく、むしろ長期に共有される前提なので、削除を試みたという不細工な痕跡が残り続ける
こっちは理学部なんで半ば他人事だけど、あかんな。
ふと Chinese Restaurant Process (CRP) という命名に文句をつけている人がいるかもなと思って調べたら、一人だけ見つかった。
https://www.tkim.graphics/CRT/Kim_WaPo.pdf
2021年の Washington Post のコラム。内容としては、Chinese Remainder Theorem、Chinese Postman Problem に続く第3の例として CRP が挙げられている。要するに、白人がアジア人を扱うとき、個人を尊重せずに dehumanize してきた、みたいな主張。
著者は Theodore Kim。知らない人だが、名前と見た目から判断するに韓国系で米国育ちっぽい。
計算機科学が本職ということで、CRP の理解は正確。まあ、「正規分布はレイシストだ」みたいなこと言ってる層が CRP に触れる機会は一生ないだろうから、観測できる事例が出てくるとしたら、こういう書き手になるのは自然。
あと、この人、Yale で Critical Computing Initiative という、名前だけでお腹いっぱいなプログラムを率いている。
Chinese Restaurant Process (CRP) は自然言語処理では失われた技術。ニューラル時代、特に LLM 時代以降に来た人は誰も知らない。
CRP は Dirichlet Process (およびその一般化である Pitman–Yor Process) の逐次的な予測規則に対応する確率過程。
自然言語処理では例えば教師なし単語分割で使われていた。この文脈ではレストランのテーブルが単語ラベル (語彙項目)、客がトークン出現に対応する。
ふと Chinese Restaurant Process (CRP) という命名に文句をつけている人がいるかもなと思って調べたら、一人だけ見つかった。
https://www.tkim.graphics/CRT/Kim_WaPo.pdf
2021年の Washington Post のコラム。内容としては、Chinese Remainder Theorem、Chinese Postman Problem に続く第3の例として CRP が挙げられている。要するに、白人がアジア人を扱うとき、個人を尊重せずに dehumanize してきた、みたいな主張。
著者は Theodore Kim。知らない人だが、名前と見た目から判断するに韓国系で米国育ちっぽい。
計算機科学が本職ということで、CRP の理解は正確。まあ、「正規分布はレイシストだ」みたいなこと言ってる層が CRP に触れる機会は一生ないだろうから、観測できる事例が出てくるとしたら、こういう書き手になるのは自然。
あと、この人、Yale で Critical Computing Initiative という、名前だけでお腹いっぱいなプログラムを率いている。
ＡＩの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）
https://www.kantei.go.jp/jp/singi/titeki2/ai_kentoukai/gijisidai/dai10/shiryo2.pdf
やばすぎると話題のこの文書、AI 事業者の定義が広すぎて、個人や大学研究者まで含まれる。
名前からも明らかだが、完全に権利団体の方を向いていて、利用者保護という観点は希薄。
だからだと思うが、ステガノグラフィを規制するような文言 (AI 生成コンテンツを人間が作ったと偽ってはいけない等) はない。
Fisher et al. 2025. Position: Political Neutrality in AI Is Impossible — But Here Is How to Approximate It
https://icml.cc/virtual/2025/poster/40157
著者 10/12 が女性という異様な偏り。有名人がガチで書いていて、引用文献を見ても強度が高い。
政治的中立性はトレードオフ関係にある (複数ある目標をすべて同時には達成できない) いくつかの手法によって近似的には達成可能だと主張している。
例えば出力レベルの reasonable pluralism を採用すると、utility, fairness, user agency は達成できるが、safety, clarity は満たさないとする。
しかし、ここで言われている指針にしたがって AI を開発し直すと、それまで疑っていた人間がその AI を信頼するようになるかといえば、そんなことはないだろう。
結局のところ、開発者自身が信頼されていないし、その開発者が持つ価値観を訓練や評価を通じて AI に埋め込むという問題に手を付けないと信頼は得られない。
改めて Fisher et al. (2025) の表1を見ると変だ。AI を統制する諸手法について、utility, safety, clarity, fairness, user agency のどれを満たしどれを満たさないかについての著者らの解釈をまとめたもの。fairness を満たして safety を満たさない手法が2つある一方で、その逆 (safety を満たして fairness を満たさない) がひとつもない。
直感的には safety と fairness はしばしば両立しないだけでなく、現実にはたいてい safety 優先で fairness が犠牲にされる。
私は最近「安全性は危険だ」と逆張りっぽく言っている。安全性は広い概念だが、安心を含む。安心は不安要因の排除と直結する。「私を不安にさせるお前は加害者だ」という論理。どう考えても公正性が保てない。
このあたりを突き詰めていけば、Fisher et al. (2025) の議論を突き崩せないだろうか。
History LLMs は、特定の年以前のデータだけで LLM を学習し、その時点の知識でシミュレーションを行う。
https://github.com/DGoettlich/history-llms
このアイデア自体はすぐ思いつくものだが、1913年をカットオフにするという決定が驚き。
4Bモデルなら、Chinchilla 則では学習に約80Bトークンが目安。そんなに大量のテキストを確保できるのかと思ったら、フィルタリング前で600Bトークンも確保したという。ヨーロッパは強い。
私はコロナ政策を再検証のためにコロナ前のデータで学習したモデルがほしいと思っているんだけど、自分でやる余力はない。
local relay が動かない問題は Nowser 1.4.1 で解消されているはず。この投稿がうまくいけば。
多言語情報抽出は昔は夢物語だったけど、いまは LLM が普通にやってくれる。最近はポリコレフィルタが緩くなっているのか、やばめの SNS まで拾ってきてくれる。以下は ChatGPT 5.2 Thinking に調べてもらった結果。
フィン語圏でポリコレ圧が弱い場としては、Vauva.fi、Suomi24、Ylilauta などが挙げられる。
Sarah Dzafce のフィン人性を疑う言説はあふれているし、「ポリコレ枠で Miss Finland に選ばれたんでしょ」といった揶揄も観測できる。
Dzafce 本人はコソボの中でもゴラにルーツがあると述べている。ゴラニは南スラブ語を話すムスリム集団なので、Dzafce もムスリマかもしれないと推測するのが自然。しかし、フィン語圏では、彼女の宗教に焦点をあてる言説はなぜか目立たない。
普通のフィン人党の政治家がこの件に乗ってきた動機として、ポリコレを揶揄する意図が透けて見える。ポリコレで守られているはずの移民系マイノリティですらキャンセルされるなら、何でもキャンセルされるだろという論法。
Miss Finland を剥奪されたことで話題の Sarah Dzafce は名前が全然フィン人っぽくないと思ったが、調べると、父親がコソボ出身。
苗字に付加記号を戻すと Džafče になるらしい。綴りは南スラブ語的だが、語そのものはトルコ語あたりからの借用っぽさがある。Sarah も対応するフィン語形として Saara/Sara があるにもかかわらずあえて選ばれたものだろう。
https://x.com/ganrim_/status/1963988210339512426
周回遅れだけれど、この指摘は重要。共有の参照枠としての自国語の古典が例えば韓国ではついに成立しなかったことを考えると、日本の特殊性が際立つ。この文化圏は琉球氏族を完全に包摂していたりもする。みすみす手放すには惜しい遺産。
氏族 -> 士族
実用化という観点からは、文脈プロンプト共有問題を何とかしなければならない。
Ziegler et al. (2019) は、ニュース記事の最初の3文を文脈として与え、その後を言語モデルに生成させるという実験設定を採用している。
https://aclanthology.org/D19-1115/
しかし評価実験から離れて実際に使う場面を考えるとどうすべきか悩ましい。そもそもの前提として、送信者 Alice は復号化に必要な情報を事前に受信者 Bob と密かに共有しておかなければならない。この前提を踏まえると以下の2つの選択肢が考えられる。
1) 最初の3文も含めて送信する。Bob と共有しておくべきなのは、最初の3文が文脈プロンプトであるというハイパーパラメータだけで済む。しかし、最初の3文は既存テキスト、4文目以降は独自生成テキストというやり取りが繰り返されれば、不自然に思われかねない。
2) 最初の3文を除いて送信する。この場合、Bob とは最初の3文自体を事前に共有しておく必要がある。これは使い勝手が悪い。おまけに、生成部分が文脈部分を参照していると不自然なテキストになるリスクもある。
Ziegler et al. (2019) の設定は後続研究 (我々の研究も含む) で踏襲されがちだが、これは悪しき前例主義であり、そろそろ改めるべき。
この点で重要なのが SNS 設定。以前は「ウェブ時代、特に SNS 時代においては、Alice が Bob を通信相手として明示する必要がない」という主張に賛同していたが、今は考えを改めている。
https://link.springer.com/chapter/10.1007/978-3-031-49803-9_7
Liao et al. (2024) は、他の利用者の投稿を文脈として言語モデルに与え、返信をステガノグラフィに利用している。
https://dl.acm.org/doi/abs/10.1145/3658664.3659657
この設定なら文脈プロンプトを事前に共有する必要がなく、既存テキストと独自テキストの組み合わせも自然に見える。通信相手を明示するという欠点を補って余りある利点があるように思える。
実用化の課題としては、計算非決定性問題も外せない。既存論文で議論された形跡がないのに査読者から突っ込まれた。
受信者 Bob は送信者 Alice の言語モデルが生成時に参照したトークン生成の確率分布を完全に再現しなければならない。しかし Bob は当然ながら Alice とは別の計算環境を使っているはずで、本当に再現性が確保できるか怪しい。
実際には、同じ計算環境ですら GPU が絡むと決定性が損なわれがち。最適化テクニックの多くは非決定的であり、無効化しなければならない。それで十分かというと怪しい。
非決定性問題は開発者向け文書では言及されることがあるが、論文では見かけない。
https://docs.pytorch.org/docs/stable/notes/randomness.html
Atil et al. (2025) は珍しく非決定性を調べているが、温度パラメータ=0の貪欲生成設定しか調べていない。しかも、OpenAI などのクローズドモデルが非決定的な最適化テクニックを使っている (と推測される) ことに原因を求めており、手元の GPU で Llama3-8b を動かしたら決定的だったと述べる。詰めが甘い。
Testing zaps for this note… we made six attempts to⚡zap this note, at _@murawaki.org, over a period of 41 minutes. Six of the zaps were successfully paid... Please check for 6 satoshis received. Problem: we found that your lightning address server **did not* properly produce zap receipts, and/or didn't send the zap receipts to the relays specified in the zap. (The zap spec requires that the zap receipts be sent to the relays specified in the zap.) This means a Nostr user who zaps you might not see a number appearing next to the ⚡ icon after zapping.... If you wanted to fix this... you could try a free rizful account -- https://rizful.com ... if u set it up, pls reply here so we can do this ⚡zap test again.
My custom LNURL callback server, built on the python-nostr library, does send zap receipts to the relays listed in the zap request. However, the log shows connection errors for some relays. If you can share details about the problematic relay ( wss://relay-nwc-dev.rizful.com/v1 ?), I can investigate further.