💬 Commented on "コントロールパネルでMisskeyのアップデートを確認できる機能": syuilo "独自のバージョンコードを持つ実装=Misskey派生ソフトという認識だけど、そうとも限らないのかしら"
https://github.com/misskey-dev/misskey/issues/15089#issuecomment-2514249648

💬 Commented on "コントロールパネルでMisskeyのアップデートを確認できる機能": sakuhanight "> そのリポジトリの管理者の責任かと…

とはいえ、upstreamで実装された場合にその機能をないものとするならば積極的に削除を行う必要があり、不親切です。"
https://github.com/misskey-dev/misskey/issues/15089#issuecomment-2514287482

📦 New Pull Request: "ノートのリンクをリモートのサーバーのURLとしてもコピーできるように"
https://github.com/misskey-dev/misskey/pull/15091

💬 Commented on "チャット": syuilo "現在のDM、特定のユーザーとのやり取りを遡ることが困難で使いにくいわね"
https://github.com/misskey-dev/misskey/issues/12467#issuecomment-2518726156

📦 New Pull Request: "fix(backend): Let MfmService.fromHtml() accept <ruby> tags"
https://github.com/misskey-dev/misskey/pull/15117

📦 New Pull Request: "fix(frontend): MkInstanceTickerの情報がリアクティブでない問題を修正"
https://github.com/misskey-dev/misskey/pull/15123

💥 Issue opened: #15127 "96字以上のカスタム絵文字がコントロールパネル上だけ画像表示に失敗する"
https://github.com/misskey-dev/misskey/issues/15127

💬 Commented on "ベンチマークツール": syuilo "ヌァァァァァァァァァァァァァァァァァァァァァァァァァァァァァァァァァァンンンンオオオオンンオンオンオンオンンンンンンンンン゛ン゛！！！！！！！！！！！！！！！！"
https://github.com/misskey-dev/misskey/issues/1370#issuecomment-2543838422

💬 Commented on "［削除して編集］ウィンドウを閉じると、編集中の内容が完全に消えてしまう": kakkokari-gtyih "「削除して編集」をする場合は実際に投稿するまで削除は行わないとかならダメージが軽くなるかも（根本解決ではないけど）"
https://github.com/misskey-dev/misskey/issues/14498#issuecomment-2547707458

💮 Issue closed: #14504 "ユーザーが照会を行った際、失敗した場合は×しか出さないのではなく失敗理由を出して欲しい"
https://github.com/misskey-dev/misskey/issues/14504

💬 Commented on "enhance(frontend): 照会の際にエラーを表示するように": syuilo "🙏🏻 "
https://github.com/misskey-dev/misskey/pull/15147#issuecomment-2552934963

💬 Commented on "Mastodonでリンクが共有される度に猛烈な負荷がリンク先のサーバーに襲いかかるという報告": NEKOYASAN "`SummalyBot` の UserAgentの付いたリクエストが短時間に異常なほどに送られていて、調査をしていたところこのDiscussionにたどり着きました。
Misskey.io などのある程度メジャーなサービスが受けているリクエスト量から見ると「通常のアクセスの範疇内」と判断されるのかもしれませんが、平時にあまりリクエストの多くないサービスだとサーバーが貧弱なので、異常なほどのバーストリクエストによってスケールアウトが間に合わず、そのタイミングでアクセスしてきた通常のユーザーの利用にまで影響が及ぶケースがあります。

robots.txtを見てくれるのであればまだやりようがありますが、現在も見てくれていないような挙動なので残念ながらWAFでブロックするしかない状況です。"
https://github.com/misskey-dev/misskey/discussions/13787#discussioncomment-11662663

💥 Issue opened: #15176 "bull-board用のトークンのCookieにSameSiteなどセキュリティ関係の属性が設定されていない / CSRF対策がされてない？"
https://github.com/misskey-dev/misskey/issues/15176

📦 New Pull Request: "enhance(backend): 絵文字の連合でライセンス欄を相互にやり取りするように"
https://github.com/misskey-dev/misskey/pull/15182

💬 Commented on "チャンネルの連合処理を実装するに当たって考えるべきことを整理するためのスレッド": tesaguri "チャンネルのノートを連合なしにするという現在の仕様に至った理由がチャンネルのノートの文脈がチャンネル内に閉じているであろうからというものであった（#6669）ことを踏まえると、チャンネルを連合させるに当たってチャンネルのノートを照会したときにそのノートがどのチャンネルに宛てたものであるかが分かるようになっているのが望ましいと思います。これについてはFEP-1b12で[規定されている](https://w3id.org/fep/1b12#audience-property)ように、`Note`の`audience`プロパティでチャンネルを指定することで素直に実現できるかと思います。

これをさらに飛躍させたアイデアとして、完全なチャンネルの連合機能を実装する前にこの文脈指定の機能のみを実現できるのではないかといったことを考えています。具体的には、`inbox`を持たない（つまり、リモートからのフォローを受け付けない）`Group`としてチャンネルのメタデータのみを連合して、`Note`の`audience`プロパティでその`Group`を指すといった感じです。将来的に完全なチャンネルの連合機能が実現した場合はこの`Group`に`inbox`を生やすことで"不完全な"チャンネルと区別できるでしょう。飛び道具的な対応という感は否めませんが、もしこれが実現すればチャンネルのノートを連合なしにする現在の制限を早期に緩和できるのではないかと思います（#10710）。"
https://github.com/misskey-dev/misskey/discussions/14049#discussioncomment-11704276