Yuriha

センシティブ設定がセンシティブでない画像にも使われるとオオカミ少年効果で本来の警告の役目を果たさなくなるという話のように思われる。 ネタバレ注意など、本来センシティブでない画像に対してセンシティブと同様のワンクッションをそれと分かる形で設定できることで、この問題が軽減できれば良いことだと思う。ただし、飯テロ画像をわざわざセンシティブで投稿している人は不意打ちの冗談を意図していて、「飯テロ注意」で投稿することに魅力を感じないかもしれない。 また、性的コンテンツにもR15、R18、実写、イラスト、残酷表現、女性向け男性向けetc. といった違いがあり、期待と違うとオエってなる（人がいる）という問題は（潜在的には）結構大きいかなと思う。 こういうことを考え始めると（.designのように）別途理由をCW に書く運用が妥当だと思うが、畳まれて存在感が無くなってしまうとか、テキストや同時投稿のセンシティブでない画像も表示されないのは寂しいとか、注意書きの表示が美しくないと思う人もあると思うので、閲覧注意画像の上に任意の（もしくはサーバー管理者が設定した中から選んで）注意書きが書けるとありがたい人はいるんじゃないかと思う。 ただいずれにしてもActivityPub連合だとセンシティブかどうかはbooleanということになっているので、それに配慮する必要がありそう。

$[ruby 流火 ルビ] 方式だと実装が容易である上に、漢字と振り仮名両方にMFM装飾を適用可能てす。 https://github.com/misskey-dev/misskey/compare/develop...yuriha-chan:misskey:mfm-ruby-fn

データベース管理画面へのブルートフォースアタックは非常によくあるので、公開でさらすのはあまりおすすめできないと思っている （ssh port forwardとかVPNとかでのみアクセスできるようにしたほうが安全） そういうこともあって、Dockerなら管理画面用の別コンテナを立てるのが使い勝手が良いと思う

ちょっとわがままなお願いなのですが、ノートをタイムラインが流れながらもすごい勢いでいろいろなリアクションがついていくのを眺めるのが好きなので、ポーリングの間隔は最初が短めなのがだんだん長くなるとか、リアクションがリアルタイムでついているかのように差分の更新が再生されるなどの仕組みがあると嬉しいです。（新しい種類のリアクションがついたとき、そのリアクションが最初についた時刻もデータに含まれていて、それを考慮した表示にするとよりリアルな感じになるかも。） あとポーリングというより、一定期間ためた情報を定期的にプッシュする方がパフォーマンス的に良いかも。

ちょっと冗長に書きますが ``` {igyo: {firstReaction: 03:34:00.00, count: 24}, super_igyo: {firstReaction: 03:34:00.50, count: 9} ultra_igyo: {firstReaction: 03:34:01.00, count: 2}} ``` というデータを03:34:02.00に受け取ると、3:34:02.00～34:34:04.00の間に秒速12で偉業スタンプが、3:34:02.50～34:34:04.00の間に秒速6でスーパー偉業スタンプが、3:34:03.00～34:34:04.00の間に秒速2でウルトラ偉業スタンプが、みたいなイメージです。あくまでリアリティを増すための一案で、実装してみたらいまいちかもしれませんが。

Related: https://github.com/misskey-dev/misskey/issues/11031

投稿とかリノートされた時にブワーってつく傾向にあるから、Redisで短期間のキャッシュを持ち、反応が落ち着いたらDBに反映というのが良さそう

> 問題は、RedisはJSONに対応してないからオブジェクトの特定のキーの値をアトミックにインクリメントするみたいな処理がおそらく出来ないこと できるっぽい https://redis.io/commands/hincrby/

Workerのパフォーマンスプロファイリング@13.13.2（一つだけの連合先にdeliverするテスト）  この条件ではあまりオーバーヘッドがあるようには見えない 謎

配送元と配送先が同一物理サーバーに乗っている場合での実験ですが > ratelimitを10とかにして、ジョブを200個くらい用意した状態でconcurrency 5のワーカーを3台位起動させるとたぶんおそらく何が起きてるかは見えるかも…？ 単純にジョブがゆっくり実行されるという想定された動作になるだけで特にオーバーヘッドが増えたりしている様子はなかった > queueのratelimitの仕様も変わってこっちは結構上方修正してあげないと処理が止まっちゃうかも （deliverJobPerSec と inboxJobPerSec などの設定、このlimitの適用範囲が完全にグローバルになってるので） その通りで、deliverJobPerSecとinboxJobPerSecをclusterLimit倍すればよさそう deliverJobConcurrencyはHTTPリクエストの待ち時間やDBの待ち時間に（シングルスレッドのワーカーが）ジョブを最大どれだけ並行して回すかという数なので、極端に減らさなければ特に関係なさそう。(https://docs.bullmq.io/guide/workers/concurrency) deliverJobPerSecを上げれば500 deliver/コアくらいは捌ける模様（Workerの台数を増やして分散させても、一台あたりの効率はそれほど落ちない）