このアカウントは、notestockで公開設定になっていません。
このアカウントは、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とかはもっと流行っても良いと思うけど）、一方で自分が死んだ後に成りすまされて不正を働かれたりしたら死んでも死にきれない気がするので、ドメインを取得するならそのあたりの対策も考えておきたいな
オリジンに基づく認証も否認可能性を留保したい場合とかには有用だとは思っているけど、それはそれとして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", … }`のような感じで
仮定法で書かれていることからも分かるように、今からこうするべきと考えているわけではない