Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-03 at 21:55 +0100, Mickaël Rémond wrote: Here is a very common example: I would like to receive push on my mobile, even if my desktop client is connected. In that situation, the message will not use offline and may not use stream management (session may have expired). This is also the case if you have N devices. You may want to receive push on all of them, or only a few of them. The only way to hint the server about this, is to have Where did the rest of that sentence go? :-) Thank you for pointing out this use case, in fact I didn't think about it. I think there are two events where a push-enabled offline user should be notified: - a push-enabled user had an open conversation with a friend then is busy with something else, the os suspends his app and server forgets about the session). After a while the friend wants to continue the conversation and sends a message to the user's full jid. (I know the standard recommends to initially send to the bare jid, but it's not illegal) - arriving message for a push-enabled user (bare jid) who's offline but before she went offline her session was the most available (as in [1]). I don't understand what you mean by registry of clients. When a client becomes unreachable it may not be able to tell the server about it. Example: The OS suspends the client app during a network outage. So I think the xmpp server has to decide whether to publish at an offline user's node by recognizing the two above events. 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. The resource is not enough as the resource is transient (In XMPP a resource only has a meaning during the session duration). It means you never know if it will be reused. Some clients like web client even use random resources to accomodate with multiple tabs, but still should represent a single device in term of push. They also can be shared between multiple devices at different moment. My point is that I think using the resource to identify a client app is not the correct artefact. Ok, the client may have another resource when it reconnects, but it will be still registered at the app server and thus will include the same node name into the enable-iq. So this will be the trigger for the server's push module to send the stored messages to the newly connected client. If for some reason the node name changes too often, the client can include a session-id in the enable-iq (like it was proposed in the old draft version) and the server can identify the client based on this (I hope this will not be necessary). Do you have more evil use cases? Christian [1] https://tools.ietf.org/html/rfc6121#section-8.5.4
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 4 Mar 2015, christian...@rechenwerk.net wrote: On Di, 2015-03-03 at 21:55 +0100, Mickaël Rémond wrote: Here is a very common example: I would like to receive push on my mobile, even if my desktop client is connected. In that situation, the message will not use offline and may not use stream management (session may have expired). This is also the case if you have N devices. You may want to receive push on all of them, or only a few of them. The only way to hint the server about this, is to have Where did the rest of that sentence go? :-) Oups, bad keyboard shortcut. Sorry about that. I was saying that the way to hint the server is tell him what are the expected online client so that he can tell which ones are offline. I don't understand what you mean by registry of clients. When a client becomes unreachable it may not be able to tell the server about it. Example: The OS suspends the client app during a network outage. So I think the xmpp server has to decide whether to publish at an offline user's node by recognizing the two above events. 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. 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). Ok, the client may have another resource when it reconnects, but it will be still registered at the app server and thus will include the same node name into the enable-iq. So this will be the trigger for the server's push module to send the stored messages to the newly connected client. If for some reason the node name changes too often, the client can include a session-id in the enable-iq (like it was proposed in the old draft version) and the server can identify the client based on this (I hope this will not be necessary). 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. Do you have more evil use cases? I will think about it more :) Thanks :) -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
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
Re: [Standards] Proposed XMPP Extension: Push
On Mi, 2015-03-04 at 22:23 +0100, Christian Ulrich wrote: 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). I'm replying to myself because my proposal wasn't very wise. Of course multiple devices with the same resource must not be enabled at the same time (they would wake up at the same time and there would be a race condition). They may be registered at the app server at the same time, so there a device id would be necessary to meet your two requirements, but registration is not defined in the XEP (I'll keep in in mind for my implementation though). So I think using the node name as a device identifier (or more precicely: an identifier for entities that want to receive the same push notifications and are thus registered for the same node) is sufficient for the xmpp server. When a client sends an enable stanza the server updates an existing record for the client's full jid with the stanza's new 'node' value. That's actually already described in the XEP. One of your requirements is still not met: you have to know the resource to enable / disable push. So what if my phone gets stolen and I want disable push notifications for it? I could log in from another device using the same full jid. But you also mentioned random strings as resources... If there was a mechanism to retrieve all enabled devices from the server and we could enable / disable push for all of them, this would completely bypass the server's routing mechanism, I don't like that. I do want to have a possibility to set the active device (the most available device where I want to be reachable) without touching other online devices, but why treat push devices in a special way? I think this is what presence priorities are for. How exactly this setting active can work with push, I don't know yet though. As I said earlier, I think the push module must check if arriving stanzas are addressed to a push-enabled device that's currently offline but *would be* the most available resource if it was still online. That's also bypassing the server's routing but in a more gentle way. One solution to the stolen phone problem would be an emergency-off switch (disable all resources of the user on all nodes): iq type='set' id='x97' disable-all xmlns='urn:xmpp:push:0' jid='push-5.client.example' / /iq
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-03 at 21:28 -0800, Lance Stout wrote: The goal for the XEP is to let an XMPP server notify the App Servers for the user's apps when something interesting happens. What those apps do once notified is up to the app's purpose and implementation. Of course, the common case we expect is for those apps to in turn publish a push notification to the user's devices which have the app installed. But that is not actually required, and the fact that multiple apps may forward their notices via the same third-party mechanism to user devices is only coincidence. It comes down to that apps have purpose and will do different things. For example, say that I have two apps which both happen to use Ubuntu Push to send data to my device. One is a typical general IM client. The other is a video call app. The App Server for the video call app will only send data through Ubuntu Push when it receives a notification that includes Jingle data. The App Server for the general IM client might only send data through Ubuntu Push when chat message data was included in a notification, and it could also keep track of all the chat message notifications it received for me during a day and send me a summary email every evening of things I might have missed. Forcing those two apps to use the same App Server will not work, because their App Servers are different, even if they do some things in common. Even if they did the exact same things now, that is not guaranteed to be true forever. Apps change, gain and lose features. App Client and App Server necessarily need to be kept in sync. That said, what you do want to do to preserve decentralization is to let the user of an app run their own instance of the App Server. Once you allow that, it remains an implementation detail how the App Client discovers and registers with the App Server. You are right, I mainly thought of typical IM apps doing my implementation. But I'm convinced a careful implementation with my approach can also fit more special applications (more below). No matter if app server and xmpp server are merged or not you brought up an important aspect. If the app server shall be able to pick only specific published items and convert them into a proprietary push notifications (ppn), there needs to be information in the published item it can base its decision on. I think criteria for these decisions are: - incoming stanza type (message, iq, presence) - namespaces of the stanza's children So these criteria must be included in the items the xmpp server publishes, e.g. iq type='set' from='u...@example.com' to='push-5.client.example' id='n12' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='yxs32uqsflafdk3iuqo' item notification xmlns='urn:xmpp:push:0' x xmlns='jabber:x:data' field var='FORM_TYPE' valueurn:xmpp:push:summary/value /field field var='stanza-type' valueiq/value /field field var='child-xmlns' valueurn:xmpp:jingle:1/value /field field var='last-sender' valuejuliet@capulet.example/balcony/value /field /x /notification /item /publish /pubsub /iq If a client only wants to be notified if jingle stanzas arrive, it could configure its xmpp server to publish only if the child-namespace criterion is met: iq type='set' id='x42' enable xmlns='urn:xmpp:push:0' jid='push-5.client.example' node='yxs32uqsflafdk3iuqo' x xmlns='jabber:x:data' field var='FORM_TYPE' valueurn:xmpp:push:0#options/value /field field var='child-xmlns' valueurn:xmpp:jingle:1/value /field ... /x /enable /iq I picked up your idea of an extra data form for configuring the xmpp server. The reason for configuring the xmpp server in this way would be of economic nature (only publish what is relevant for the app / app server). To configure the server to also publish messages, we would add value 'jabber:client' (and use XEP-0352 to protect us against the presence / chat state storm). Now to my merged servers approach. My implementation aims to notify the app on events, so no email sending ;-) If an app needs an app server with more features it can register at an app specific server and still use the xmpp server part of my implementation. With the client defining the namespaces of incoming stanzas to be considered there's a dynamic possibility for the client to define the push events, at least up to a certain degree. An alternative to define them for my approach would be to send a list of namespaces when registering but I like the configuration in the enable-iq more. So from my point above, in this case you would not search for an XMPP Push Service for Ubuntu Push. You would search for an XMPP Push Service for your app. This is an
