9 ms·

Matrix doesn't even support server-to-client message pushing, only polling. Which means, if you want your phone to receive a message while your client is in the

Matrix doesn't even support server-to-client message pushing, only polling. Which means, if you want your phone to receive a message while your client is in the background, you have to use a non-Matrix protocol to receive those. This protocol is XMPP in 99% of the time, both Apple and Google use XMPP to connect the phones to their push notification service. On Android, some Matrix clients offer the option to use non-Google push notification channel via UnifiedPush. UnifiedPush needs a distributor, a service that runs on the phone and manages the delivery of push notifications. Conversations, a popular Android XMPP messenger, can be used as such distributor. So if you want digital independence with Matrix and thus do not want to use Apple/Google push, you might end up installing an XMPP messenger, so that your Matrix messenger actually can show notifications. Matrix alone just doesn't provide what is needed for digital independence.

_flux 23d ago
The protocol of Matrix does long polling though. Is there a big difference? You want at least heartbeat to detect a broken connection (at least from client end), and it looks like XMPP does not come with server-originated hearbeat for that purpose, so it's back to client-side pinging?
- pixelschubsi 23d ago
  Well, apparently long polling is so bad on battery that Matrix clients for phones prefer to just not provide background notifications without any external push service. From what I understand, many Matrix services give their long polling a timeout of 60 seconds, which would prevent a phone from entering deep-sleep states. XMPP uses a persistent connection. These are kept alive using TCP keepalive (both from server and on the client, but client side will be handled by the MPU and thus doesn't need CPU wake-up) and client initiated application protocol pings at intervals of 5 minutes or even less. Client initiated pings are much better on the application protocol, because they can be synced with other operating system tasks and thus don't need any active wake-up.
tcfhgj 23d ago
> Matrix doesn't even support server-to-client message pushing, only polling. Which means, if you want your phone to receive a message while your client is in the background, you have to use a non-Matrix protocol to receive those. (aside long polling which I cannot comment) why is this a even an issue? Centralized push services (may it be FCM or unified push) are at this point well established. As a user using a specific messenger app as a push service doesn't gain me anything, it only makes it more difficult to switch messenger app if i choose to use it and mostly use an additional push service (hurting battery life), because most receive push notifications via Google anyway.
pkulak 23d ago
What mobile OS do you use that allows an app to maintain a persistent TCP connection forever? Honest question. Last I checked, even Lineage/Graphene/etc will kill a background app after some amount of time. Doesn't matter if it's an hour or three days; if it ever happens, that's a deal breaker. I think the right solution is to use a different notification service, not controlled by Google or Apple, not to get rid of the concept altogether.
- account42 22d ago
  I've not had any issues with my Samsung Android killing the Conversations client. It does have a persistent notification which is probably needed for this.

_flux 23d ago

The protocol of Matrix does long polling though. Is there a big difference? You want at least heartbeat to detect a broken connection (at least from client end), and it looks like XMPP does not come with server-originated hearbeat for that purpose, so it's back to client-side pinging?

pixelschubsi 23d ago
Well, apparently long polling is so bad on battery that Matrix clients for phones prefer to just not provide background notifications without any external push service. From what I understand, many Matrix services give their long polling a timeout of 60 seconds, which would prevent a phone from entering deep-sleep states. XMPP uses a persistent connection. These are kept alive using TCP keepalive (both from server and on the client, but client side will be handled by the MPU and thus doesn't need CPU wake-up) and client initiated application protocol pings at intervals of 5 minutes or even less. Client initiated pings are much better on the application protocol, because they can be synced with other operating system tasks and thus don't need any active wake-up.

tcfhgj 23d ago

> Matrix doesn't even support server-to-client message pushing, only polling. Which means, if you want your phone to receive a message while your client is in the background, you have to use a non-Matrix protocol to receive those. (aside long polling which I cannot comment) why is this a even an issue? Centralized push services (may it be FCM or unified push) are at this point well established. As a user using a specific messenger app as a push service doesn't gain me anything, it only makes it more difficult to switch messenger app if i choose to use it and mostly use an additional push service (hurting battery life), because most receive push notifications via Google anyway.

pkulak 23d ago

What mobile OS do you use that allows an app to maintain a persistent TCP connection forever? Honest question. Last I checked, even Lineage/Graphene/etc will kill a background app after some amount of time. Doesn't matter if it's an hour or three days; if it ever happens, that's a deal breaker. I think the right solution is to use a different notification service, not controlled by Google or Apple, not to get rid of the concept altogether.

account42 22d ago
I've not had any issues with my Samsung Android killing the Conversations client. It does have a persistent notification which is probably needed for this.