SUMMARY NeoChat appears to be repeatedly calling a [QueryNotification endpoint](https://spec.matrix.org/v1.7/client-server-api/#get_matrixclientv3notifications) that seems excessive when compared to other clients. Based on the description of the endpoint, it seems like this endpoint is mostly meant for paginated lists of notifications instead of minute-to-minute notification querying. I'm not 100% familiar with the matrix spec but I believed that other clients primarily rely on push notifications. This might result in undue stress on Matrix servers that are on lower power devices STEPS TO REPRODUCE 1. Login to Account via NeoChat (23.11.70) on A Matrix Server (Dendrite - 0.13.1) 2. Monitor Dendrite logs 3. Log out of the NeoChat or close the application 4. Note the immediate absence of QueryNotification calls 5. Compare Server behaviour between Element, NeoChat, and Nheko Clients for reference OBSERVED RESULT A large number of calls to the Query Notification endpoint on the Matrix server (~3/second) EXPECTED RESULT A push notification instead of calling the Query end point SOFTWARE/OS VERSIONS Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.6-200.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 590 Series Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X470 AORUS GAMING 7 WIFI ADDITIONAL INFORMATION Below is a snippet of matrix logs from my Dendrite Server ``` Aug 03 23:10:09 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:09.475954094Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=WYlVT8PdQ1q1 req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:11 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:11.904456064Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=oZq1JaNyYlJ1 req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:12 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:12.035785674Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=Tjo8yAEaGoXC req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:17 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:17.494735833Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=TAGn9zQxwt2c req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:18 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:18.732933884Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=gxIhttgLZ44c req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:19 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:19.102445739Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=sQMZogx1YAxB req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:19 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:19.652499093Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=lE78OBdlHxEZ req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:20 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:20.133270022Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=xPDoHz4IZ4rU req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:20 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:20.310603076Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=FJ6TAl1oOQND req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:20 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:20.457044935Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=kBdt1gXMKPFD req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:20 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:20.924745627Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=Ram8snqbiHgZ req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:21 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:21.648464100Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=q1JYAh27nJYk req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:21 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:21.937484140Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=qoMUqIxEx9B7 req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:22 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:22.098886906Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=7sdBuIKUKGBy req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:22 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:22.421637482Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=c15VHeWyls0V req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:23 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:23.019193719Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=Fpttg0zfrxMj req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:23 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:23.403763628Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=aXvVWUI0Q8F1 req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" Aug 03 23:10:23 hermes dendrite-start.sh[554851]: time="2023-08-04T04:10:23.727667997Z" level=info msg="QueryNotifications: len 0" from="" limit=0 next="" only="" req.id=bTYn6s5f9q3y req.method=GET req.path=/_matrix/client/v3/notifications user_id="@timaeos:matrix.nexaeos.io" ```
Desktop clients don't usually use the push notifications API, since that requires extra infrastructure for the app maintainer (i.e., a push distributor), which is a lot of effort and not required. We do indeed probably call that API more than we'd strictly need, since that's the easiest thing for us to do. It's only being called in response to sync responses arriving at the client, which should only happen when a message arrives for your account. Looking at your log, it indicates that you received e.g. 4 messages at 23:10:20, and a bunch more in the seconds directly after - does that look plausible to you, considering how many messages you typically receive on your matrix account? otherwise this could also point to an error in dendrite, where the server sends sync responses for syncs that haven't timed out yet
(In reply to Tobias Fella from comment #1) > Desktop clients don't usually use the push notifications API, since that > requires extra infrastructure for the app maintainer (i.e., a push > distributor), which is a lot of effort and not required. > > We do indeed probably call that API more than we'd strictly need, since > that's the easiest thing for us to do. It's only being called in response to > sync responses arriving at the client, which should only happen when a > message arrives for your account. Looking at your log, it indicates that you > received e.g. 4 messages at 23:10:20, and a bunch more in the seconds > directly after - does that look plausible to you, considering how many > messages you typically receive on your matrix account? otherwise this could > also point to an error in dendrite, where the server sends sync responses > for syncs that haven't timed out yet I'd say that it would be accurate during heavy periods of usage that it could line up with the activity of channels I'm in. That especially makes sense for the gaps in time frame. It does seem like that would be too frequent in my estimation if it's being called on every received message. I mention this because P2P Matrix Servers are expected to be run locally on phones and other low power devices which could become problematic down the road. (This is all a guess, though. If most of those instances are only one user, and they're not running multiple instances of NeoChat on the device, it's probably trivial) I'm still not 100% clear on the other implementations of notification systems so I'd have to ask around for the "suggested" method of handling this. I was also under the impression that the server includes the number of unread notifications in the [sync response](https://spec.matrix.org/v1.7/client-server-api/#get_matrixclientv3sync) so would the client just be able to parse that directly? I assume that NeoChat calls the sync endpoint on a regular basis. It sounds like if you set a `pusher` for the client then the server will add those to the `sync` response for that particular type of event (https://spec.matrix.org/v1.7/client-server-api/#receiving-notifications) It doesn't seem like that would require push notification infrastructure since the server would be handling the trigger of the notification and you could parse it through the sync response
Ok, so not a dendrite bug then :) I wouldn't worry about the P2P part here - realistically, the overhead of the client-server syncs and the server-server API is much larger than what the notification queries would consume. Nevertheless, we probably can optimize this a bit