Tdesktop: Prevent most active muted groups to top the recent conversations list

[LuKePicci]

Steps to reproduce

1. Join some very active large groups, subscribe to some superdeal or news channel, start some notification bot for, let's say, periodic report of something (smart home, github issues, whatever…).
2. Mute them all, since you probably wouldn't like your notification list be filled up constantly because of them.
3. Try not to get crazy because of the continuous swapping of recent conversations in the top most part of the recent conversation list. Also consider how much you _always_ need to scroll down to reach relevant conversations.

Expected behaviour

Muted conversations (or at least groups and channels) should not be put on top of the recent conversation list when new unread messages are received. This should only eventually occur when marking those new messages as read, or the user get mentioned, as a clear expression of the user intention or requirement of an active participation to that conversation. This make sense if the recent conversation list is intended to represent recent user activities. Receiving lots of not interesting messages should not be considered as an "activity".

Actual behaviour

Most important chats, like 1-to-1 conversations or small groups where I participate more often then others, gets constantly overtaken by other irrelevant top most conversations. Top most conversations are actually a list of conversations I'm neither interested in nor an active participant, like highly active (super)groups, channels or notification bots I need to keep in my conversation list.

I'm not really sure this behavior il client-related, but it definitely needs to be reworked.

[stek29]

Open settings, type workmode.

[LuKePicci]

Did a quick search on google just now from mobile and can't get any docu about that. Anyway if there already exists something hidden that make tdesktop act as I described should be clearly visible as an option. I will investigate this mode later.

[stek29]

@LuKePicci There are no "doc" about that.
That mode would add a switch that hides all muted chats.

[LuKePicci]

Ok let me say this is somehow a workaround, what I was thinking about is something more complex. Again I'm not sure it's not a server issue, I have no idea how clients handle the lists of recent conversations, if they don't keep them sorted but is the server who send in such order may not be the case of working on it client-side.

[stek29]

@LuKePicci yeah, it was just a workaround suggestion :)

[mantono]

I think this is a duplicate of #2440.

[LuKePicci]

Wow, we all had the inspiration to come here to open an issue about the exact same thing in a timespan of a month... that should be the final proof that someone should work on it ;)

[stek29]

@LuKePicci have a look on Secret Chats issue.

[stek29]

Would #2440 suit you?

[LuKePicci]

As I explained in a comment to #2440, it is a good idea but I'm worried about what will happen when messages are read. In a pic posted by @wolfgangvc there is a script saying: "Unmuted chats push above muted ones when unread messages are present". Now what you intend to do when all messages are read and a new one is received in a muted conversation? In my opinion it should stay on top of other muted conversations but not on top of older non-muted still unread ones. Yet another critical point: what happens if I keep unread an unmuted conversation for long time? I would expect that new messages in muted conversations would still be after the unread unmuted one, which may not be the best thing to deal with.

Instead, what I expressed here in "Expected behavior" about this issue (#2590) is something more general and I think even simpler to implement and learn to use. It doesn't make a huge difference in usage since no grouping/classification of conversations occurs but only sets a different behavior of pushing up muted conversations.

For example I'll always expect that when I'm being mentioned that conversation is pushed up, with the same rational for which notifications are sent even in muted groups on mentions, but the strong grouping would not be able to work in this scenario.

I think there are a lot of little considerations that would move my preference to what I described versus what is proposed as a solution in #2440. I would like to listen other opinions on that point, maybe I'm not considering other technical or implementation issues.

[rnz]

Also:

• need groupping users and groups
• need switch beetwen groups and users

[LuKePicci]

As I stated above, three interesting suggestions ( #2440 #2590 #2632 ) to address the same issue should be enough to consider approaching a solution. I suggest to whoever takes care of this to carefully understand each proposal and to take the best from each. I really hope to see some progress on this direction.

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[SmartManoj]

Use archive