- Jul 20, 2019
-
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jul 18, 2019
-
-
Daniel Gultsch authored
* we still include DNS servers from VPNs because of edge cases where the XMPP server is hosted in the VPN * on older Android versions we don’t know if a network is active or not (activeNetwork == null) fixes #3465
-
- Jul 17, 2019
-
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jul 16, 2019
-
-
Daniel Gultsch authored
-
- Jul 15, 2019
-
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jul 14, 2019
-
-
Daniel Gultsch authored
during live messages we only store the bare real jid; on muc catch up we might get the full jid for that reason we only compare bare jids
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jul 13, 2019
-
-
Daniel Gultsch authored
-
- Jul 11, 2019
-
-
Daniel Gultsch authored
-
- Jul 10, 2019
-
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jul 04, 2019
-
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
fixes #3475
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jul 03, 2019
-
-
Daniel Gultsch authored
-
- Jul 02, 2019
-
-
Daniel Gultsch authored
-
- Jul 01, 2019
-
-
Daniel Gultsch authored
leave can be triggered on swipe and doesn’t mean we don’t want pushes
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jun 30, 2019
-
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
Daniel Gultsch authored
-
- Jun 26, 2019
-
-
Daniel Gultsch authored
when receiving a FCM push message for a channel the user is no longer in (this can happen when the disable command failed) an attempt will be made to explicitly unregister from the app server (which in turn will then send item-not-found on next push)
-
- Jun 25, 2019
-
-
Daniel Gultsch authored
-
- Jun 24, 2019
-
-
Daniel Gultsch authored
Staying connected to a MUC room hosted on a remote server can be challenging. If a server reboots it will usually send a shut down notification to all participants. However even if a client knows that a server was shut down it doesn’t know when it comes up again. In some corner cases that shut down notification might not even be delivered successfully leaving the client in a state where it thinks it is connected but it really isn’t. The possible work around implemented in this commit is to register the clients full JID (user@domain.tld/Conversations.r4nd) as an App Server according to XEP-0357 with the room. (Conversations checks for the push:0 namespace on the room.) After cycling through a reboot the first message send to a room will trigger pubsub notifications to each registered full JID. This event will be used to trigger a XEP-0410 ping and if necessary a subsequent rejoin of the MUC. If the resource has become unavailable during down time of the MUC server the user’s server will respond with an IQ error which in turn leads to the MUC server disabling that push target. Leaving a MUC will send a `disable` command. If sending that disable command failed for some reason (network outage) and the client receives a pubsub notification for a room it is no longer joined in it will respond with an item-not-found IQ error which also disables subsequent pushes from the server. Note: We 0410-ping before a join to avoid unnecessary full joins which can be quite costly. Further client side optimazations will also surpress pings when a ping is already in flight to further save traffic.
-