On Mi, 2015-03-04 at 17:52 +0100, Mickaël Rémond wrote: > Well, you do not have to notify the server if the server knows that you > have two mobile devices for example a phone and a tablet. When you send > the stanza to enable push after login, it will know you are online. When > the session close, it will know that device is offline. > By comparing the list of devices requiring pushes with the list of > online devices, the server knows to which it needs to send push. No need > to remind him on connection lost.
Alright I got it. So we have the list of online push clients already, it's the list of tuples (full_jid, node, device_id?) which is filled by clients sending an enable-stanza (regarding device_id / session_id see below). > > This means we have to store the stanzas we notified the user about > > ourselves (damn, I was happy thinking this wouldn't be necessary). So > > if we detect one of the events, we have to store the message and > > prevent the server's routing mechanism to route it to another > > resource. This will certainly interfere with carbon messages, but > > I'll have to dig into that. > > I think we do not need to do that: We can simply route to online users + > push to offline devices (By comparing to the list of expected online > devices). I think we have different requirements here. I'm getting headache thinking of routing message contents through untrusted cloud servers (mobile-compatible e2e-encryption [1] is not available yet), so I want to use push only as an event notifier, so the client can wake up, connect to the xmpp server and pick up new stanzas. That's why I want to have xmpp server configuration options (see the other sub-thread). So I will have to store stanzas for offline push clients. > I think the client should have a client reference in the enable IQ. It > is not a session id per say but a unique client id. If that client is > not online, then it triggers a push. > Unless, you are expecting to use the node as that unique ID for that > client. > But in all cases, the server need to have a way to know "What are the > list of devices that user should have online ?" > And I think the user should be able to retrieve it to delete devices he > does not use anymore. By session-id I meant a client reference (not the stream id), let's call it device_id. I'm still not sure if we really need it or if using the node name is ok. I'm thinking of a client starting after a crash. It forgot about its previous state and registers at the app server. Do we want to rely on the app server to reuse the same node as before? You mentioned the two mobile devices using the same full jid (not very wise but not illegal either) and the random resources in the web app. We could hand the device id to the app server during registration (this was actually proposed in the old version) and require it to always return the same node for the same device_id (within a reasonable time span), but do we want that? So I'm proposing the following: A user MAY include a device id in the enable stanza. If he does so, the XMPP server MUST distinguish between devices by the combination of full jid and device id when updating the list of enabled devices. If the user does not include a device id the XMPP server MUST distinguish only by the full jid. This means, if a user enabled push for full jid A with multiple device ids and then sends an disable (or enable) stanza for A *without* device id, all entries of A are deleted from the list of enabled devices (and a new entry without device is added in case of the enable stanza). Retrieving a list of online resources should maybe a different XEP, as it could also be usefull for other things, like [1]. Christian [1] https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ [2] http://xmpp.org/rfcs/rfc6122.html#addressing-resource
