Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v12: ワードミュートの再実装 #6092

Closed
EbiseLutica opened this issue Feb 26, 2020 · 14 comments · Fixed by #6594
Closed

v12: ワードミュートの再実装 #6092

EbiseLutica opened this issue Feb 26, 2020 · 14 comments · Fixed by #6594
Assignees
Labels
✨Feature This adds/improves/enhances a feature

Comments

@EbiseLutica
Copy link
Member

無くなっていたので

@EbiseLutica EbiseLutica added the ✨Feature This adds/improves/enhances a feature label Feb 26, 2020
@syuilo
Copy link
Member

syuilo commented Feb 26, 2020

クライアントサイドではなくてサーバーサイドで実装したいけど、面倒そう

@EbiseLutica EbiseLutica self-assigned this Mar 9, 2020
@syuilo
Copy link
Member

syuilo commented Mar 9, 2020

SQLでやるのは重そうだから一旦普通にクエリして、その中にミュートにマッチするノートが含まれていたらそれを捨てて、足りにゃくにゃった分さらにクエリして持ってくる、という処理を繰り返していくのが良いのかにゃぁ

@rinsuki
Copy link
Contributor

rinsuki commented Mar 9, 2020

それでもミュートしまくってるとクエリ発行回数が無限になって終わりそう

@syuilo
Copy link
Member

syuilo commented Mar 10, 2020

除外するのではなくて、CWにするというのが良さそう

@EbiseLutica
Copy link
Member Author

現在実装中の仕様では、足りなくなった分をクエリするのも微妙だなあって思ってそのまま弾いてしまっています。数が揃わないと微妙だなあとは思うものの割り切っても問題ないような気がしています

@tamaina
Copy link
Member

tamaina commented Apr 19, 2020

#6149 での発言引用…

なんか私の考える良い感じの実装が見えてきたので私が適当に実装するかも
一応私の考えとしては

  • UserProfileにミュートワードカラム追加で良さそう
  • ワードミュートで引っかかったノートにはisMuted: trueを追加してクライアントサイドで非表示
  • isMuted: trueに対応していないサードパーティクライアントのことを考えて強制CWもする

https://github.com/syuilo/misskey/pull/6149#issuecomment-603844627

@tamaina
Copy link
Member

tamaina commented Apr 19, 2020

私も↑の方針が合理的だと思うのですが、実装はいつになるのでしょう?

わりと使われている機能なので、従来通りのクライアントサイドでの実装で実装を早くした方が良いという考え方も出てきています。

@syuilo
Copy link
Member

syuilo commented Jul 26, 2020

クライアントが複雑になることを考えると、やはりどうしてもサーバーサイドでやりたいので、サーバーサイドで上手いことできないか検討してみて無理そうだったら https://github.com/syuilo/misskey/issues/6092#issuecomment-616164134 でやる

@syuilo syuilo self-assigned this Jul 26, 2020
@syuilo
Copy link
Member

syuilo commented Jul 26, 2020

あー、クライアントにしろサーバーにしろ、ミュートされたノートがあると「あなた宛」とかで未読のノートがあると判定されたりする問題が出てくるな
解決策としては、ミュートをアンテナみたいな処理にすれば良さそう
つまり、あるノートが作成されると、全ての(ミュートが設定されている)ユーザーに対してそのノートがミュート対象かどうか判定する処理を行い、対象だったらMutedNotesみたいなテーブルにレコードを追加する。タイムライン取得時などは、そのレコードに入ってないノートのみにフィルタリングすれば良い。これはクエリのみで完結できる。
あなた宛に未読があるかどうかも、クエリでMutedNotesを参照してフィルタリングして判定すればよい。
また、この方法なら手動で「このノートをミュートする」のような機能(https://github.com/syuilo/misskey/issues/2227 )も実装可能になる。
さらに、この方法だとスパムと思われるメッセージを自動でフィルタリングするような、将来的に必要になると思われる機能の実装も容易になる。
他にはこの機能に付随して、アンテナごとにワードミュートを適用するかどうかの設定や、メーラーが迷惑メール一覧を見れるようにミュートされたノート一覧を見れる機能とかも実装すると良さそう

@syuilo
Copy link
Member

syuilo commented Jul 26, 2020

↑の方法で、なにか懸念点とか有れば教えてください
アンテナと同様、ワードミュート設定しても過去のノートには適用されないのは留意点ですが、そこまで問題にはならなそう。

@tamaina
Copy link
Member

tamaina commented Jul 26, 2020

ワードミュート設定しても過去のノートには適用されないのは留意点ですが、そこまで問題には

対策しないとわりと問題になる気がするわね……ワードミュートって、めっちゃRenoteされるミーム的なノートをミュートするのにも使うと思うから。
対策として、Renoteやリプライに遡ってMutedNoteかどうかを判定したり、#2227 を実装したりすればあまり問題にならなさそう

@syuilo
Copy link
Member

syuilo commented Jul 26, 2020

ただやっぱり、すでにタイムラインにある、またはこれから遡っていくノートにも適用されて欲しいので、ソフトミュートとハードミュートという概念に分けようと思う

ソフトミュート … タイムライン取得時にフィルタリングする(多分クエリで)。これなら過去のノートもフィルタリングされる。クエリで実現することになると予想されることから、パフォーマンスを考えておそらくキーワード指定のみ。
ハードミュート … MutedNotesにレコード追加。過去のノートには適用されないが、ソフトミュートと違い、正規表現やAiScriptも使えるようにすることができる。

@syuilo
Copy link
Member

syuilo commented Jul 26, 2020

もしかしたら↑のソフトミュートの実装方法では重いかもしれない。そしたらソフトミュートはいつか言及したように「isMuted: trueを追加してクライアントサイドで非表示」にするしかない(そうしたらソフトミュートでも正規表現やAiScriptも使える)

@syuilo
Copy link
Member

syuilo commented Jul 26, 2020

ソフトミュートは全部クライアントでやっちゃう手もある

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨Feature This adds/improves/enhances a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants