ダイレクトメッセージ（投稿）はやっぱりFediverseでもend-to-endで暗号化しないとなぁという意見。
アクセスする機械がたくさんあると、デバイス間で秘密鍵を共有したり、複数の公開鍵をアナウンスするのが難しいけれども。
RE: https://kolektiva.social/users/admin/statuses/110637031574056150
ダイレクトメッセージ（投稿）はやっぱりFediverseでもend-to-endで暗号化しないとなぁという意見。
アクセスする機械がたくさんあると、デバイス間で秘密鍵を共有したり、複数の公開鍵をアナウンスするのが難しいけれども。
RE: https://kolektiva.social/users/admin/statuses/110637031574056150
これ、スクレイピングを締めだそうとするなら、ログインユーザーのなかで通常ユーザーとスクレイピングしてるユーザーの区別がサーバー側でできれば、レートリミット下げられるだろうけど、そんなこと可能ではなさそうなので(おもいつかない)
* 今後もレートリミットをつけて制限内でtwitterしていくぞ！
* API利用料を下げる(スクレイピングしてるやつらをAPI利用促す)
* スクレイピングを排除するのを諦める
くらいしか出口ない気がするな。
アプリだとなんとかなりそうだけど。
スクレイピングによってAPI利用料の価値が毀損されるからスクレイピング締め出しはわからなくないけど、そうするとAPI利用料の価値を担保するにはかなり閉じた世界を構築する必要があるわけで、いまさらそういう閉じた世界に急速に展開するのとか無理そうな気はする。
そうすると高額なAPI利用料を売りつけるというビジネスモデルで上手くいく道筋は見えないなーとおもった。
サーバーからユーザーとして取得した情報は、ユーザーが自由に加工・表示していいはずだというイデオロギーと、ユーザーへのサービス提供を商売上の手段として捉え、抜け穴を塞ぎしかるべきところからはがっつり取ろうという企業の緊張関係が常にある。
そもそもWeb API自体が実質上、スクレイピングのWin-Winな代替案（利用者は安定した扱いやすいインタフェースを提供され、提供者は負荷の軽減と常識的なレートリミットを依頼できる）として導入されてきたわけで、こういう暗黙の合意を一方的に破棄すると混乱が生じるのは目に見えていた。
私はオリジナルと自家用両方維持してますが以下みたいな感じです。
・git remoteに本家(origin-dev)と自分のレポジトリ(origin)の両方を指定する。
・自家用バージョンへは定期的に本家のdevelopをマージする
・本家への機能追加の予定の有無にかかわらず、基本的に feature ブランチは本家のdevelopから切る
・そのブランチを自家用バージョンにマージしたり、本家にPRしたりする
自家用のバージョンをリリース単位でデプロイするのではなく、developを直接運用するという発想なのでこの方法でうまくやれています。そうでない場合はちょっと大変かも。
RE: https://post.naskya.net/notes/9govadt2imhedqsm
Misskeyには「照会」というナゾの機能がありますが、中小サーバーでは結構使う機会の多い機能です。アカウントやノートのURLもしくは「@アカウント名@サーバー名」を張り付けることで、他のサーバーでみつけたユーザーをフォローしたり、ほかのサーバーで見つけたノートを表示して、返信したりリアクションをつけたりできます。（検索機能にURLを入力しても同じことができます）
このよく分からない機能、なんだろと思って押すと説明のない入力ボックスが出てきて、さらに謎が深まるのですよねｗ
単純に新しいインスタンスはスパム対策が弱かったり、動作が不安定だったり、すぐに運用終了する可能性が高いからはじかれているっぽい。
問題がなければじきに連合してもらえるようになる。
RE: https://msk.seppuku.club/notes/9gp091ogb8
