definition of "unread count" in push gateway API does not match reality

[richvdh]

The _matrix/push/v1/notify endpoint includes a parameter notification.counts.unread, defined as "The number of unread messages a user has across all of the rooms they are a member of."

Since matrix-org/synapse#793, Synapse has chosen to interpret this as "the number of rooms with unread messages".

Possibly the spec should be reworded to allow discretion on the part of the homeserver impl?

[richvdh]

according to @BillCarsonFr , the riot mobile clients don't even use this field any more. maybe we can just drop it?

[richvdh]

while we're here: the spec also has notification.counts.missed_calls, which is fairly handwavily defined, and afaict has never been implemented by synapse

[richvdh]

but according to @ismailgulek, riot-iOS does use this field.

[ismailgulek]

but according to @ismailgulek, riot-iOS does use this field.

Yes, i confirm Riot-iOS will need notification.counts.unread in the next App Store version, but not notification.counts.missed_calls

[richvdh]

but according to @ismailgulek, riot-iOS does use this field.

but we could still consider getting rid of notification.counts.missed_calls, which is unimplemented.

[richvdh]

it's now clear that element-iOS does use notification.counts.unread, whereas element-android does not. it seems like we should add a way for clients to opt in or out of receiving this field. If they have no purpose for it, there is no benefit of the HS and pushgw spending CPU cycles sending pushes, and the clients spending battery receiving them, only for them to be ignored.

[callahad]

Note that as of matrix-org/synapse#8820 in Synapse 1.24, it's possible (but not the default) to configure Synapse to meet the Spec's original definition of "The number of unread messages a user has across all of the rooms they are a member of."

[ara4n]

this just caused much confusion with the EX team (cc @stefanceriu). EX is unilaterally getting a remotely-calculated badge count from sygnal, which then fights against the locally calculated badge count, and chaos happens: element-hq/element-x-ios#2066. So:

a) the spec should be fixed to describe what the count actually means
b) clients need a way to opt out of it being set on them.