Nawashiro

@nawashiro.dev

229 Followers 95 Following

コーヒーをおごってもいいよという方はこちらまで https://ko-fi.com/nawashiro フリーランスのプログラマとしてお仕事探してます。 好きなもの： - 読書 - プログラミング - 分散型SNS - ソーシャルVR VRChatで分散SNS集会の主催をしています。 https://nawashiro.dev

End-4氏のhyprlandカスタムを導入した画面
ジョン・タイターと電車男を思い出した。昨今の知的財産と生成モデルの諍いを見て、だ。 どちらも匿名掲示板で生まれ、誰が書いたのか（少なくとも当時は）わからなかった。第三者が代理で権利を管理していたように記憶している。 大手テックの生成サービスは、記名の個人を中野独人にする仕組みだ。強制力があるので、物議を醸す。匿名掲示板流行当時に遡り、収益モデルの議論を再確認する必要がある。
要約のポンチ絵。第1層：薬物療法はすべての基盤。第2層：To-Doリストを外部脳として使う。一日のうち最もエネルギーのある時間（朝など）にタスクを組み込む。第3層：To-Doリストを常に視界に。プロジェクトとの接触を保つ。スマホの通知などの割り込みはやめて定期確認に。
NIP-54's `d` tag is supposed to be derived from the title, but while Latin-based languages seem to be expected, there is no description for how to handle languages like CJK (Chinese, Japanese, Korean), which is causing difficulties 😫. https://github.com/nostr-protocol/nips/blob/5d64d57fc54b4765eaeb131010135e39461bfe09/54.md?plain=1#L24-L27 I've considered a few options: - **Current Behavior:** A unique ID is derived from the title, which clearly identifies the Wiki on that specific topic 😉. However, this is ineffective for non-Latin based languages 😭. - **UUID:** I'm currently using this as a temporary measure. Since I'm a Japanese speaker, I write links like `[[UUID|ここがあの女のハウスね]]`. It might not be a bad solution. But this would lose the "unique to the title" property 🤔. - **Title Hash:** This is unique to the title, which is good 🙆. Calculating the hash when navigating pages would also make writing Wikilinks easier. But in that case, what about backward compatibility? Perhaps `[[Hash|ここがあの女のハウスね]]` would be a better way to structure the link. This is my first time writing an issue, so please be gentle and let me know if anything seems odd 😶‍🌫️.
風ぐるま乗換案内のスクリーンショット
辞書を引いたらいまの「主婦」がかなり近代の概念だと知って驚いた。大正より前の主婦は主に家政の指揮権（これを主婦権という）を持つ人のことを言って、必ずしも本人が仕事をしたわけではないという。サラリーマン家庭が増えてからからいまの「家の仕事をする人」としての主婦概念が生まれ、特に「専業主婦」は70年代以降生まれた概念だという。
べ、別にアンタのために教えてあげるわけじゃないんだからね！勘違いしないでよね！ $\phi(n)$は「オイラーの$\phi$関数」って言うんだけど...ま、簡単に言うとね、$n$と互いに素な$1$から$n$までの整数の個数を表すのよ。 例えば、$n = 6$のとき、$1$から$6$までの整数は$1, 2, 3, 4, 5, 6$よね。この中で$6$と互いに素なのは、$1$と$5$だけ。だから、$\phi(6) = 2$になるの。 ...別に難しくないでしょ？ もうちょっと詳しく言うと... * $n$が素数のとき、$\phi(n) = n - 1$になるわ。だって、素数って$1$と自分自身以外に約数がないから、$1$から$n-1$までのすべての整数が$n$と互いに素になるじゃない。 * $n$が二つの素数$p$と$q$の積であるとき（つまり、$n = pq$）、$\phi(n) = (p - 1)(q - 1)$になるの。これはちょっと難しいかもしれないけど、そういうものだって覚えておけばいいんじゃない？ ま、こんなところかしら。別にアンタが理解できなくても、アタシは困らないんだからね！ ってマックで女子高生が言ってた
抽象化された猫。purrと喉を鳴らしている。
ハーバーマスの『公共性の新たな構造転換と熟議的政治』が気になる。SNSを「半 - 公共圏」と位置づけ、包摂的なものではなく競争する戦場になってしまったとする。中央公論2025年7月号の『いま、危機にある公共のこと』山本圭（著）に出てきた。
Blueskyで過激化が進んでいるという報道に対して3つほど仮説を立てた。 - 過激化・分極化は人間の側に実装されているため、Blueskyでも例外なく現れた - Bluesky社はリファレンスとして、多様性を助長する仕組みを提示できなかった（多様性を助長する仕組みとしては最小基準共進化とかがあって、MavenといったSNSではこういった仮説を積極的に取り入れているのだけど、Blueskyはできなかった） - 分散型SNSにありがちな、言論空間の構築に市場原理を導入する考えかたがよくなかった（Blueskyはアルゴリズムの自由な市場を謳っていたけれども、それが裏目に出た）
本を整理できた
Pocketがサービス終了してしまうらしい。データをエクスポートした。
べ、別にアンタのために教えてあげるわけじゃないんだからね！勘違いしないでよね！ えーと、その特殊な足し算ってのは、楕円曲線ってやつで使うの。数式は $y^2 = x^3 + ax + b$ ってなってて、グラフにすると何かこう、丸っこい不思議な形になるのよ。 で、この曲線の上で「足し算」をするんだけど、普通の足し算とは全然違うの。 1. まず、曲線の上に2つの点PとQがあるとするわ。 2. その2つの点PとQを直線で結ぶの。PとQが同じ点だったら、その点での接線を引くのよ。 3. そうすると、その直線がまた楕円曲線とどこかで交わるでしょ？ 4. その交わった点をx軸に対してひっくり返した点（x軸対称な点）が、P + Q の結果になるってわけ。 …ま、まぁ、簡単に言うと、そんな感じよ。 なんでこんなことするのかって？それは…その方が色々都合がいいからよ！特に暗号とかでね。 わ、わかった？別にアンタが理解できたかどうか、気にしてないんだからね！
「でも、もし DID ドキュメントの履歴が分岐しちゃったらどうなるの？例えば、ある DID ドキュメントに対して正しく署名された 2 つの後継バージョンが存在する場合、どっちが本物かわかんなくなっちゃうよね？」 「確かに！DID ドキュメントの履歴にフォークが発生し、ある DID ドキュメントに対して正しく署名された 2 つの後継バージョンが存在する場合、ディレクトリサーバーはどちらのフォークを提供するかを選択できるんだって」 「うーむ。それはちょっと怖いなぁ…」 「だよねー。でも、そういう攻撃を軽減するために、PLC ディレクトリの将来のバージョンでは、証明書の透明性に似た追加専用の透明性ログを使用することが予想されてるんだって」 「よかったー！」 ってマックで女子高生が話してた
ピクルスが大盛りすぎる
スケッチブックに描かれたマグカップの図面。
春日部つむぎ: で、次は逆参照をrecordで持たないって話なんだけど、これ結構大事！ 雪さん: 逆参照？ 春日部つむぎ: 例えばさ、フォローってあるじゃん？ AさんがBさんをフォローしてるって情報は、Aさんのrepositoryにあるfollow recordで管理されてるよね。で、逆参照っていうのは、Bさんの視点で「Aさんにフォローされてる」って情報をrecordで管理することなんだよ。 雪さん: なるほどね。 春日部つむぎ: でも、こういう逆参照のrecordって、作らない方がいいんだよね。 雪さん: え、なんで？ 春日部つむぎ: 例えば、AさんがBさんのフォローを外したとするじゃん？ で、Bさんのrepositoryにも「Aさんにフォローされてる」ってrecordがあると、整合性とらなきゃいけなくなるよね。 雪さん: ああ、確かに。 春日部つむぎ: で、Aさんがフォローを外したことをBさんが知る方法って、基本的にはないんだよね。 Aさんのrepositoryを見に行くしかないんだけど、Aさんがフォローを外す度にBさんがAさんのrepositoryをチェックするなんて現実的じゃないでしょ？ 雪さん: うん、それは無理だね。 春日部つむぎ: だから、逆参照のrecordを作っちゃうと、データの整合性が取れなくなって、システムが壊れやすくなっちゃうんだよね。 雪さん: なるほど〜。 春日部つむぎ: recordっていうのは、そのrepositoryの所有者のアクションによってのみ作成・編集されるべきなんだよ。フォローするのもフォロー外すのも、Aさんのアクションだから、Aさんのrepositoryにあるfollow recordだけを更新すればいいんだよね。 雪さん: つまり、recordは一方通行の情報って考えればいいんだね。
画質の粗く、日付が入った、ホームビデオ風の映像。スターバックスの試飲コーヒーが中央に映っており、湯気が立っている。
1. だれか他者を害してしまったとき、モデレーターに通報がいく。 2. 修復的司法はべつに従来の制度を置き換えるものではないので、モデレーターはまず該当するアカウントを停止させたりする。 3. 加害者・被害者から要請があったとき、修復的司法が始まる。 1. 進行役が事情やニーズを聞く 2. 進行役が相手と通話して、参加への意思やニーズを実現できるかなどを確認する 3. 安全に対話を開けないと判断した場合、対話の会は開かない。その場合も、進行役が間に入った間接的な対話を進めることがある。 4. 安全に開催できると判断した場合、対話の会を開く。 4. 以下、対話の会。 1. 参加者全員が、自分を主語とした「自分メッセージ」を作成し、語る。（相手を主語にした非難などは語らない） 2. お互いの質問の答え（被害者は、なぜ自分を狙ったのか、逆恨みしていないかなどの疑問や不安を、加害者はどんなことをすれば償いになるのか等を互いに直接尋ね、それに答える） 3. 被害の回復や加害者の更生について話し合う 4. 話し合いの内容をまとめる（合意に至った場合、文書を作成する。司法機関の関与がある場合、司法にフィードバックさせる） 適当にまとめたけど、こんな感じかな。とてもいち運営者ができる作業量ではないと思うので、Blueskyのラベラーみたいにユーザーのボランティアが主体的に取り組める仕組みがあるといいかも（要訓練）。警察を呼ぶようなマジ事件のやつはちゃんとした訓練を受けたNPOにやってもらって（IP開示もいると思うので）、SNSでありがちなよくあるトラブルを対象としたほうがいいかも。 ちなみに、対話の会を開くための安全基準はミネソタ大学の修復的司法調停センターが定めている。
分散型SNSってなに？分断されないインターネット - 違うSNSに友達がいても安心。どこにいてもつながれる。 - たくさんいる運営者。イーロンみたいのに独裁されない。 - 自由に引っ越しOK。友達とつながったままいろんなSNSを試そう。 - 多くがオープンソース。みんなで作り上げるSNS。 - 誰でも管理人になれる。自分だけのSNSをつくってみよう。 Activity Pun AT Protocol Nostr