Role-based visibility rules for better community management

[arikantr]

Türkçe:
Misskey’de rollerin koşul özelliği ile belirlenen rollere ek olarak, topluluk yönetimini kolaylaştıracak bir “rol bazlı görünürlük” özelliği eklenmesini talep ediyorum.

Bu özellik ile:

Bir rol, yalnızca belirli rollerdeki kullanıcıları görebilecek şekilde ayarlanabilir,

Veya belirli rollerdeki kullanıcıları göremeyecek şekilde sınırlandırılabilir.

Bu sayede farklı topluluklar aynı instance üzerinde daha düzenli, güvenli ve sağlıklı bir şekilde yönetilebilir.

Örnek kullanım senaryosu:

XX rolüne sahip kullanıcılar, XY rolündeki kullanıcıları göremesin.

Böylece farklı topluluklar birbirinden ayrıştırılarak çatışmalar veya istenmeyen etkileşimler engellenebilir.

---

English:
I would like to request a new role-based visibility feature in Misskey that extends the existing condition functionality of roles, to improve community management.

With this feature:

A role can be configured to see only users with specific roles,

Or to not see users with specific roles.

This will allow communities on the same instance to be managed in a more organized, safe, and healthy way.

Example use case:

Users with role XX cannot see users with role XY.

This makes it possible to separate different communities and avoid conflicts or unwanted interactions.

---

日本語 (Japanese):
Misskeyのロール機能において、既存の「条件」機能を拡張し、コミュニティ管理を改善するために「ロール間の可視性制御」機能を追加していただきたいです。

この機能によって：

特定のロールは、指定したロールのユーザー のみ を見られるように設定できる

または、指定したロールのユーザーを 見られない ように制御できる

これにより、同じインスタンス上の複数のコミュニティを、より整理された、安全で健全な形で管理することができます。

利用例：

ロール「XX」を持つユーザーは、ロール「XY」を持つユーザーを見られないようにする。

これによって、異なるコミュニティを分離し、衝突や不要なやり取りを防ぐことができます。

[eternal-flame-AD]

From a computational standpoint this feels pretty difficult... I don't even think large social media platforms can do this arbitrary user subset intersection problem with real time consistency. I think it is more pragmatic to try eventual consistency (i.e. a "virtual blocking list" that we update in the background) or focus on a subproblem only.

The are 4 different cases of this problem ("X cannot see Y" can simply be understood as a request of "X can only see ^Y"):

• A large role being configured with a non-selective filter. - What we do currently for account blocking - hash joins.
• Small but diverse roles being configured with a selective filter. - the most difficult: probably dedicated index structure and needs a lot of research if not out-of-band solutions
• A large role being configured with a selective filter. - Misskey® Fan-out Timeline Technology™ (FTT) (a materialized list of visible IDs), heavy insertion cost
• Small but diverse roles being configured with a non-selective filter. - What we do for Home timelines - bitmap/linear scan, but we already have problem with that if the selectivity estimation is just a little off タイムライン読み込みでタイムアウトする #15923.

And this is before considering some roles are dynamic (i.e. assignments are not persisted and evaluated on the fly in TS and size or selectivity in its associated filters can change drastically in one instant).

Implementing this feature requires a generic (and deliverable) implementation to solve on the fly queries where it isn't obvious which strategy is the best, feels like a whole project on its own to me (basically an adaptive query engine).