Desktop Client: show contact requests for unselected accounts

Contact requests don’t show as a blue dot on an account. If you have multiple accounts on desktop, and the contact request is on some account you rarely use, it’s easily missed.

So I suggest to include contact requests in the blue “unread message” counter, at least for unselected accounts.

(edit: originally, I thought they also don’t cause notifications. As @r10s pointed out they do, it’s just not helpful because they vanish after some seconds.)

on android and iOS, we show notifications about contact requests since some time, also as a result from discussions in this forum:

as a first step to improve things, let’s do that for desktop as well - it seems to work on android since some time. also to make things consistent.

this will already improve things significantly. maybe sufficiently, as it is possible by that to get aware of a contact request. if not, we can iterate from there and think over badge counter changes, but that is a bit more invasive and requires further considerations to keep them consistent and summing up. also, it is maybe just not wanted to have “spam” included the badge counters (some have accounts getting looooots of spam, you know :slight_smile: )

Are you sure they don’t cause notifications? Maybe I have a different setup, but I do get notifications from chats that are “unconfirmed”.
And this is confusing me a bit. I get a notification, but there is no “unread messages” dot on any of the accounts.

me? no, i am not sure for desktop (cannot test currently). only sure for android/iOS.

indeed, at least for me on macos, contact-request-notifications are shown also on desktop, so all platforms are consistent here. thanks @WofWca for the hint!

so, the original assumption “Contact requests don’t cause notifications” is not correct - or there is a bug, @missytake can you double check?

1 Like

okay, they might cause notifications. But at least on xfce, notifications vanish after 10 seconds (by default), so I can’t rely on them either. The issue is not really about the notifications, but about the blue dot. I removed the part about notifications from the original post.

2 Likes

But at least on xfce, notifications vanish after 10 seconds (by default), so I can’t rely on them either.

i can imagine that for “shortly showing banners” - but if there is no way to access notifications later, i’d say this is an issue with xfce - you will have troubles with all kind of notifications then.

the current design-balance around contact request is that they are notified, so you get aware. you can tap the notification to deal with the contact request. if you do not want to, then you’re done.

use cases of contact requests also have changed since chatmail as “cold emailing” has been degraded.

however, “just so” adding contact requests to the badge-counters still would cause another annoyances, as you then have to deal with each contact request more. also these counters cry “YOU HAVE STH LEFT TO DO!!111!!” - which is usually not true for contact requests. eg. you need to open each contact request or mark them as read otherwise. also, you might have more unread-badges that “stay forever”, so you will not really recognise contact requests by that. finally, contact request do not show bage counters but the string “Contact Request” - expectation for badge counters, is however, they sum up (eg. having a “10” on the account, you want to get that sum on the chat’s badge counters (having a greyish “muted” dot without a number in case there are contact requests but otherwise no unread messages may be an alternative))

for sure, all of that can be changed, and i see the point that you want to have the information also in-app. however, we need to be careful not to degrade other parts and look at effort and effect (as always : ) maybe i’ve overseen an easy way that does not degrade other things

1 Like

As I’m facing the same issue as @missytake , I’ve added an option to include contact requests in counters and notifications in DeltaTouch. Not sure if it is the best solution for everyone, but works for me so far.
notif-options

2 Likes

i think, that contact requests are notified is not in question in this feature proposal. contact-request-notifications are there since “forever” and more intrusive than a dot or badge - which, eg. does not sound or vibrate.

so, this issue is more about thinking about the “badge counter”.

sleeping it over, and as it does not affect chatmail but mostly classic email - and also as ubuntu touch does it already (i assume the contact-request-notifications are on by default):

maybe it is worth to think over including the contact-request to the numbers - which, however, may lead to subsequent tasks as showing the numbers beside contact requests and a way to get rid of them

nb: i removed the “desktop” tag

1 Like

a good first step would be to have an option to mark multiple/all chats as read on all platforms - on android it was just introduced at allow to mark as read selected chats by adbenitez · Pull Request #3130 · deltachat/deltachat-android · GitHub - iOS can be just the same, on desktop a right tap on an account icon “Mark All As Read” comes to mind.

that is completely unquestionable, useful also for normal chats and for chatmail, and can just be done - when we have that, it also feels easier to show badge counters more aggressively :slight_smile:

1 Like

already exists in desktop

What also comes to mind would be an option to filter chatlist by unread status (show only chats with unread messages or contact requests)

Also would the contact request get an unread badge then like other chats or would it stay in the badge counter until you either rejected or accepted it?

1 Like

ahh: it does not work for muted chats, this is why i though it is not there at all (i have many muted chats :slight_smile: )

great it is there in general!

EDIT: created an issue for the missing bit: https://github.com/deltachat/deltachat-desktop/issues/3979

i can imagine that for “shortly showing banners” - but if there is no way to access notifications later, i’d say this is an issue with xfce - you will have troubles with all kind of notifications then.

I disagree, it’s just a different notification paradigm. You can actually log notifications in XFCE, but it’s opt-in, and not very useful, as they don’t vanish when you read the message in-app, and they don’t get grouped by chat, so you can’t hide a discussion with one swipe as on Android.

Nonetheless, this paradigm is quite typical for desktop environments, I think. And it never caused me any trouble with any application, because on desktop you have no apps running in the background anyway (other than on Android), you only get notifications for apps you opened yourself. Usually you can ignore a notification, and view the whole chat later, when you look at the open application again. In Delta Chat, this paradigm just doesn’t work with contact requests, because they are hidden in the account.

As we already have “Mark all as read” on Delta Chat, we could easily just show them in the badge. We can even consider showing them in the badge only until the account is selected, and hide it when the user saw the contact request once.

nb: in my daily life, I consider a contact request as “something left to do”. Sure, if it’s complete spam, I’ll block the contact. But usually I care for requests from new people.

1 Like

gnome, kde, windows and macOS have a center where previous notifications go, like on android and iOS

indeed, if you start counting contact requests in the global counter it will be really confusing for users if they don’t see the badge counter in the contact request chat

1 Like

I’d like to throw in another option which might resolve this issue with the least disruption for users who don’t need it - a settings option to automatically accept all contact requests. I think bots do this already? I considered just setting bot=1 in my database, but then bots would ignore my messages I think, not desirable either^^

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.