It’s been a while - I’ll try to summarize the discussion.
Involved User needs
A) The need to not be easily ignore contact requests if they are spam. This is mostly a problem for classic email users, as chatmail relays block spam anyway as its typically unencrypted.
B) The need to notice new incoming messages on secondary profiles.
This is mostly a work/activist use case, especially for official contact addresses. Those are often classic email addresses, which also receive spam. But nonetheless it’s important to this use case that legit messages are not overlooked.
But contact requests also appear for users which you already share a group with, which is usually more legitimate, and is quite common also for chatmail relay users.
Status Quo:
The system shows a notification, which usually disappears after some seconds. If users have turned on the notifications center of their OS or similar logging of notifications, they can see it later; but as we don’t delete notifications after users marked the message as seen (at least on Linux), notification centers are not very comfortable to use and will most likely be ignored by users. They also can’t be turned on or off per profile, only per app.
The system doesn’t show a “new message” badge in the sidebar. This only appears for new messages by accepted contacts. This can also confuse users with many profiles, who noticed the notification, because they have to click through all profiles to see where the contact request arrived.
How many fresh messages a profile has is managed by the core afaik, so it’s a bit hard to change just for desktop.
The solution space
1) Don’t expire notifications of contact requests
The desktop client could override the expiry setting of notifications for contact requests, so that users have to manually click them away.
- pro: easy fix on the desktop client
- con: the notification doesn’t survive restarting the application, and might be seen as more annoying than other solutions.
2) Include them in the “this profile has fresh messages” badge, but make it grey if it’s only contact requests
Count how many unread contact requests a profile has, and expose this number in the core. The desktop client could add the number to the blue badge with the fresh messages number in the account sidebar.
This is what DeltaTouch is doing, with a setting in “Notifications”.
Additionally, if all unread messages in the profile are contact requests, we can change the badge’s color to grey, so users can more easily ignore it, or “Mark all as read” in the whole profile. This helps to make the “something left to do” feeling go away after you skimmed through the contact requests for legit ones.
Also it makes sense in this case to count contact requests with more than one message only as one; this way the user doesn’t get bumped if an unwanted contact they didn’t block yet writes another message to the unaccepted contact request chat.
An additional task for this would be a small badge in the chat list, which indicates that a contact request hasn’t been read yet, and counts into the counter. Otherwise it could become quite hard to hunt down the contact requests which make up the grey badge number in the sidebar.
3) Per-profile setting to “accept all contact requests automatically”
A setting in “Chats & Media” which allows users to let the profile accept all contact requests. Then they would be included in the blue badge counter anyway.
Pro:
- For official contact addresses, this makes a lot of sense anyway.
- The setting can also be desktop-only, which makes implementation easier.
Contra:
- it is not obvious to many users what the difference about this setting is
- they would need to discover it in the settings
- all the other reasons why we like to avoid additional settings, especially if they are only for one platform.