Fediverseにおけるデータの可搬性は、寄り合い所帯サーバの運営者の誠実性が信用できないからというよりは、寄り合い世帯・自前ともにサービスの継続が不能になった場合に備えたバックアップとしての有用性が大きそうな気がしている
Fediverseにおけるデータの可搬性は、寄り合い所帯サーバの運営者の誠実性が信用できないからというよりは、寄り合い世帯・自前ともにサービスの継続が不能になった場合に備えたバックアップとしての有用性が大きそうな気がしている
ロックインついてはそれなりにコストはかかるもののセルフホストで十分に回避できるし、そうでなくともサーバの選択肢だけは多いので
今 archive.org 上で表示してるアーカイブのページ内にあるログインフォームに archive.org のログインIDとパスワードが自動入力されて怖～となった (とりあえず Bitwarden で該当の認証情報の自動入力を off にした)
そもそもWayback Machineがクライアント側でJavaScriptを実行するのはどういうセキュリティモデルなのだろう
今さらだけど、話題のFlashesはサービスというよりは単なるBlueskyクライアントか。まあFlashesの話とは明言していないのでセーフということで（？）
QT: https://fedibird.com/@tesaguri/113835943890296396 [参照]
Blueskyのために作ったアカウントをそのまま他のAT Protocolのサービスに使えるというのはやはりonboardingの面で強そう。ActivityPubのエコシステムもC2Sのサポートがもっと普及していたらなあ（いつもの）
Blueskyのために作ったアカウントをそのまま他のAT Protocolのサービスに使えるというのはやはりonboardingの面で強そう。ActivityPubのエコシステムもC2Sのサポートがもっと普及していたらなあ（いつもの）
しかしそれっぽいドメインまで取得しているのに、実行させようとしているコマンドが明らかに本物のそれよりゴテゴテしていていかにも怪しげのは何故なのか
ログインとかするわけでもないのに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
https://www.kaikatsu.jp/info/detail/ddos.html
当初は公式に「原因：DDoS攻撃によるネットワーク輻輳」とされていたっぽい
分散かはともかく、サービス拒否を伴う不正アクセスというのはどういうものがあるのだろう
TikTok、そもそも1期目に自身に対する規制を進め始めた大統領の2期目でご機嫌を取らなくてはならないの普通に可哀想
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
「サイコパス」とかもそうだけど、本来は「メンヘラ」もあんなにカジュアルにレッテルとして使うべき言葉ではないよなあ。
辛うじて「サイコパス」などと違うところがあるとすれば、精神保健的な困難を抱える当事者自身による謙遜的な言及としてなら成立しうるかも知れないという点くらいだろうか（それをアイデンティティ化することが精神保健上望ましいかの議論はさておくとして）
特定のオブジェクトと関連して副作用として生じるコレクションをフラグメント付きURIをもつオブジェクトとして元のオブジェクトに埋め込むの、筋の良いアイデアのように思っていたけど、`totalItems`が副作用で変化するからオブジェクトの署名と致命的に相性が悪いな。うーむ
QT: https://fedibird.com/@tesaguri/113810078390191293 [参照]
それならむしろ副作用の方を主役として、`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", … }`のような感じで
FEP-5624: Per-object reply control policiesFEP-5624: Per-object reply control policiesExample Domain
それならむしろ副作用の方を主役として、`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", … }`のような感じで
FEP-5624: Per-object reply control policiesFEP-5624: Per-object reply control policiesExample Domain
というかそもそも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に変換する前に全てエラー扱いになって開発体験がオワる
