3 ms·
This should be solvable, although maybe a little meh. Client developers on platforms without unrestricted background connections need to run a server for push n
by toast0 12d ago
This should be solvable, although maybe a little meh. Client developers on platforms without unrestricted background connections need to run a server for push notifications. And server developers need to accept and use a push url from the clients.
If I understand correctly, Google and Apple have a way for clients to request push tokens, but in order to use the token, you have to authenticate as the app owner, so a client unaffiliated with the server can't simply send a push token to a server and have that be used ... Instead you'd need that push proxy server.
That proxy server comes with concerns about reliability and privacy and etc, but if you do pushes without cleartext content (and you should!), the footprint is minimal and you gotta do what you gotta do.
I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. It's a pretty apparent need for the last I dunno 15 years and it has a clear solution.
With the right agitation, maybe you could get sharable platform push tokens and skip the intermediary app developer pusg server, but that seems unlikely.
You probably also want something in the push system to help trace push problems. For small chat servers and smallish client push proxy servers, I expect minimal operations staffing, but when messages are being delayed because of push problems, you want to be able to let affected clients know that they need to be more agressive with periodic/background connections until push works again. You may also want to let users or the administrators of the proxy push servers know as well. Pushes might be initiated late on the origin, delayed between the origin and the proxy, queued for a long time at the proxy, delayed between the proxy and platform push, or delayed within platform push (including on device delays from Doze, etc).
You've got to be able to detect that so you can make adjustments and reduce delay. Messaging delay reduces user satisfaction.
- seba_dos1 12d ago> This should be solvable Yes, and it has been solved long time ago already and is now widely supported by both servers and clients. > I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. See XEP-0198 from 2004 and XEP-0357 from 2015.
- toast0 12d ago> XEP-0357 from 2015 Taking a quick look, this one is marked deferred; I don't know what that means, but it sounds like it's not an accepted standard?. It requires the application push server to be an XMPP server (which I suspect is challenging for client developers, compared to having a https url that takes a POST or similar) and doesn't include a method for a client to request a test push to validate the setup or discuss feedback to the client for push failure. This doesn't feel solved to me. I didn't review XEP-0198 closely, based on perhipheral ecosystem interaction, I do think that one is solved.
- wahern 12d agoBoth Monal and Conversations support XEP-0357. Each project runs their own XMPP-to-Apple/Google gateway for push notifications. It has to be that way because the gateway server and client phone application have to be signed by the same developer account. The client phone app tells your XMPP server which gateway to use (or maybe it's vice-versa, the gateway contacts your server. I forget). In any event XMPP servers like Prosody support this out-of-the-box.
- deleted 12d ago[deleted]