I think adding these hacks to the permissions system is a really bad idea. The permissions system is already incredibly complex, and a huge cause of confusion / bugs / problems. If there's one place we should be thoughtful about technical debt, it's the permissions system

The permissions system for thick threads is completely isolated from keyserver threads. So I don't think introducing hacks here makes our permissions system introduce a tech debt that has significant interest rates. The thick thread system doesn't have any mechanisms like permissions inheritance, prefixes, etc. that caused bugs in the past. Introducing these would make the system a lot more complicated. So I think the current approach is better for now, and can be easily replaced in the future, but I'm going to scope the right solution to make sure how expensive it is - https://linear.app/comm/issue/ENG-9361/scope-the-right-solution-to-permissions-of-thick-sidebars.

Add a comment

I am also thinking about adding viewerID to ProcessDMOperationUtilities, as it seems like the right place to put it and could simplify it, curious also for @tomek's perspective.

Deduplicate

Improve performance

This solution feels a lot more complicated than it should. Maybe it has to be that complicated, with canceling and flushing, but I'm not sure.

It might be a better idea to clear the messages when a device is removed from the device list.

Fix edit message condition

Update reaction message condition

Delete logs

In D13349#376126, @ashoat wrote:

Where would we document? Maybe @tomek was thinking of something like a function function isCalendarEntryHistoryEnabled(threadType: ThreadType): boolean