神楽坂しえる @Clworld@md.ggtea.org

あーでもこの変更だと言語判定完全無視なので新しい判定で様子を見た方がいいのかな…

pump.io / ActivityPub の情報が何も無さすぎる…

Rails動かした経験からすると、32bitで動かす時と64bitで動かす時でメモリ使用量1.5倍くらい違って死にました。

気休めに関してfetchmailかなんかだったかのメンテナの話で、
設定ファイルのパスワードを暗号化してほしい -> アプリが復号出来無いといけないからどこかに鍵を読める状態で置いておく必要があって、
そうするとその鍵を使って復号出来てしまうので無意味。にもかかわらず暗号化して安心なように見せるのは有害なので暗号化しない。
みたいな話を思いだした。

ポート番号変更は気休め(でも気は休まるので変える)
NginxやApacheやbindやnsdのバージョン隠すのも気休め

速度重視の寄稿ベースではやはり濃さに不満が

Referrer-Policyはとりあえず設定して外にリファラ出ないようにしておいた方が良い気がする

CSPならmstdn.jpのをぱくりました…

10万フォローしてる人がフォロー減らせと警告受けて減らそうとした結果unfollowのAPIリクエスト回数がやばくて鯖がやばいはまあそうなるよねって感じにはなる。

ねこー(きづいたらMastodonの話の比率がおおすぎる/FGOのいべんとがんばる)

迷子になったのでとりあえずメモ書いた / MastodonのToot時処理フロー https://pastebin.com/8fp6Dv6j

毎回コネクション張り直してる話はクライアント部分をなんとかしてHTTP/2かkeep-alive対応したらなんとかなってしまいそうな気がする。

どちらかというとOStatusじゃなくてローカル向けの配送で死んでいませんか？という感じが(Sidekiq N+1も主にローカル配送の話)

ふとソース見つつ思ったんだけど、そもそもOStatusって本当にそんなにスケールしない？サーバ数が1万とか10万とかあってその全部がめっちゃフォローし合ってるなら話は別なんだけどそんなに分散してる？ 毎回コネクション張り直しててオーバーヘッド大きいことは確かなんだけど。

ほんとだ公開範囲変えると!が外れる…

1.3.2からMastodonが動いてるのとは別の場所で
タグに対して origin_v1.x.y のブランチを作成 -> origin_v1.x.y を ggtea-base にマージ -> ggtea-base を ggtea にマージ -> 成功したら githubにpush -> Mastodonが動いてる場所で git pull っていう慎重な手順になりました。

git stash って意外と死ねますからね、ブランチ切ってしまった方が安全な気がする。