[Android App] Notification does not go away when message deleted from Web application

[x80486]

The title says it all. If I receive a message and I just happen to have the Web application open at the same time, when I delete the message using the Web interface, the mobile notification never goes away.

I can confirm that works as expected, for instance, in FastMail, Outlook, Gmail, etc...so there should be a way to fix this one in Tutanota :wink:

Not a show-stopper, but a nice to have.

PS: I have a Nexus 6P (Android 8.1.x).

[charlag]

@x80486 this would be nice to do of course but it may be harder because of the encryption. We may do this in the future, thanks!

[charlag]

There's another part of the problem reported by the user: we expect notificaitons to be timely delivered. When the user deletes an email and after the the phone connects for some reason the user may receive unwanted notification. Currently we don't track for which email notification was received, only the number of them.

[sunbladehub]

This issue is affecting me as well. I currently use the newest F-Droid Android app and the Linux desktop.

These are the specific problems I encounter when receiving an email:

1) If I open the email on Android while the desktop app is offline, then when I open the desktop app later (i.e. laptop is asleep) the notification pops up even though there is no new mail. 2) If I open the email on the desktop, the Android notification persists even though there is no new mail.

Problem 1 creates confusion because I wait for the new email to come in on the desktop but it never does because there isn't a new email. Problem 2 is quite annoying because I always have to clear the "new mail" notification even though there is no new mail.

These issues end up wasting the user's time and creating confusion and frustration. I don't see why this hasn't been fixed yet - it shouldn't be hard to implement in the code. I have never seen another app that misbehaves this way. It comes across as an amateur mistake and tarnishes the app as "unprofessional". It is one of the few issues that is holding me back from a paid premium account.

Please fix this issue.

[charlag]

Hi As stated above, there are some constraints (is it okay to send out which emails are read without full authentication") and other infrastractural difficulties which complicate implementation. You think it's a simple mistake because you have a wrong assumption of how it is implemented.

[sunbladehub]

Here is how it should work:

1) New email comes in. Notifications are sent to online devices. 2) If email is opened, server adjusts "new email" notification count. Any online devices should be notified of these changes (i.e reactive architecture). If new device comes online, no "new email" notifications are sent as server is aware that new email has already been opened.

If you can't make it work this way because of "how it is implemented" then I would say that it is implemented incorrectly and an oversight was made on how multiple devices should interact with the servers. We live in a multi-device world. You need to account for that and ensure the app is not misbehaving with stale data.

I actually like what Tutanota is trying to accomplish and acknowledge the achievements to date. I just think that the various existing annoyances deserve more attention as opposed to prioritizing new features. New users will be put-off by these types of oversights and will go to existing services (encrypted or not) that behave as expected.

[charlag]

That's how alarms work now. The difference is that alarms are end-to-end encrypted (you set an alarm, you get update) but email notifications are not not (because server sends them out). We could encrypt each read notification for other devices but that's a lot of work for the client considering how often emails are read.

There are two real-time updates system: websockets for the case when you are authenticated and push notifications for less sensitive data when you are not (yes, reactively). That's not the problem.

There are some annoyances which we would like to fix ourselves but implementation of security affecting feature in an end-to-end encrypted multi-device setting should not be taken lightly. This is something we have to allocate resources to. It's not intended to stay like it is and I'm not trying to defend the way it is but rather "we did not implement this yet". We both want this implemented and we both want it to not compromise any data, I hope we agree on that.

[sunbladehub]

Fair enough. Thank you for your timely responses and acknowledgement of the opportunity for improvement. I look forward to future releases of Tutanota and hope you continue to see a growing user base.

[MadByteDE]

Any news on that front?

I don't quite get the gist of the discussion about read notifications since all what has been proposed is that e-mail notifications should be removed from remote devices when an email has been marked "read" on another device (or at least on Android / iOS devices). Maybe I just don't understand the security issue with that change properly..

I actually like what Tutanota is trying to accomplish and acknowledge the achievements to date. I just think that the various existing annoyances deserve more attention as opposed to prioritizing new features. New users will be put-off by these types of oversights and will go to existing services (encrypted or not) that behave as expected.

I'd like to second that quote.