Don't send push notifications to users who are clearly active on a device

[dbkr]

This is a bug to track the various different bugs related to aspects of tracking what we've seen/read between clients:

High priority:

• accurate synchronised unread state per-room (ie. number of regular messages unread or in vector, room boldness) (critical);
• accurate highlight state per-room (subset of notif counts) (hopefully we have it already);
• accurate badge counts on the favicon of the client

Lower priority:

• accurate notification counts per-room (not that we show them in the UI currently, so it could be skipped)
• self-read-up-to-marker
• jumping to arbitrary message offsets (unrelated, basically)
• push notification badge counts (not a blocker for v0)
• synchronising whether you push a user with whether they are currently active on a device, or have sent a read receipt, or whatever (not a blocker for v0)

Also need to show highlights somehow for rooms that are scrolled out of view on the RoomList or in a collapsed RoomSubList.

Immediate priorities:
Tracking unread per room, tracking highlights per room, ensuring they are synchronised between clients, and maintaining a favicon badge

App specific issues

• Android shouldn't notify me of a new message if I have the window open in another app element-android#3855

[dbkr]

What we need now for the unread / bing counts:

• Unread notification count per room in event stream
• Notification actions attached to each event in event stream

[ara4n]

One other aspect here could be only setting reset pushes for messages that you know the user has actually read. E.g. if I read messages in one room, I expect them to disappear from my list of mobile pushes. But it's unintuitive if other messages I haven't read yet then disappear from my mobile push list.

[dbkr]

Note that APNS has no concept of a reset push for a message: you can set the badge count to zero which causes all the notifications to disappear, otherwise they all stay.

[dbkr]

https://matrix.org/jira/browse/SPEC-303 tracks how we decide whether a given room is unread

[ara4n]

[Matthew]
so: suggestion is that we handle 3 different custom room states in vector-web: unread, notify and highlight
unread is calculated on the client, and would make the room title go black & bold.
the rules for what message types count as unread are hardcoded for now (everything except for: membership changes, call candidates/hangup, and m.notify?)
but in future could be defined as part of the pushrules.
notify == event you would be pushed for. these make room title go green and bold.
highlight == event you would be highlighted for. these make the room title go red and bold
by default highlighting are messages which reference you by name, or are 1:1
you can also configure custom things to cause a 'highlight' in push rules, as we do already today.
finally, we either track 'badge counts' for notify or highlight events.
and this is done serverside to avoid having to shove loads of explicit notify/highlight events down the eventstream
by default 1:1 convos would be highlit already.
so additional highlights within that convo would do nothing, unless you somehow turn off highlighting for your 1:1s, which presumably could be a configuration option via push rules.
so the only open question, assuming Amandine agrees with this, is whether badge counts should show highlights (aka mentions) or notifies.
for now, i suggest badge counts show the number of pending notifies, but we perhaps make it configurable in future depending on how it feels.
as intuitively I really think that I expect the badge count on an app to show me the number of pushes i've missed
rather than the number of i've missed.
"missed pushes" is basically how FB and Twitter do it, aiui.

[Amandine] ok, and let's see because I suspect it can really become useless at some point
[Matthew] quite possibly. but it should be trivial to change
[Dave] what amandine's suggesting is essentially a count of things which are directed at you personally, or individual events you've asked to be called out
[Amandine] but agreed athat "number of pushes I missed" is a clear explanation

[ara4n]

deprioritising from p1 to p2 as the 'jump to old read receipt' behaviour isn't a hard hard blocker on v0

[dbkr]

Badge counts are fixed on https://github.com/matrix-org/synapse/tree/push_badge_counts but requires the new notification code which is currently disabled.

[dbkr]

Should this still be v0?