Re: [Standards] Proposed XMPP Extension: Push
On Mar 25, 2015, at 8:34 PM, Anu Pokharel i...@monal.im wrote:
Hi all,
I make an XMPP app on iOS called Monal. Much of my comments are based on my
experiences developing an XMPP client on iOS for the past 6 years. My
concerns may be Apple specific in some places but since the intent of the XEP
is for a very general implementation, these issues should be considered.
Apologies for resurrecting this discussion.
No apologies necessary! The discussion is still underway.
The proposed XEP does not seem to address token expiration. On Apple
platforms (and likely others) the push token will change periodically. This
information is provided on a feedback channel to the App server but there is
no way for it to communicate this to the XMPP server. There is really no way
for the client to know it’s token has expired so It will not know to request
a new one from the push service and the messages will just be lost. In
addition even if the client were to somehow know, there doesn't seem to be a
way for the client to refresh its token with the XMPP server.
On iOS, and I expect this to be a general case on mobile, your app is supposed
to register itself for remote push notifications every time it launches,
precisely because the tokens/deviceIDs can expire and change.
Which means, on startup, an iOS app will need to:
1. Register with the OS/APNS for a device ID (call it DeviceToken)
2. Register itself with the App Server (e.g., 'push.monal.im') to optionally
receive AppToken.
3. Send an enable / request to the XMPP server.
Now, that enable/ request needs to include some data, and there are a few
ways to do this:
1. enable jid='push.monal.im' node='DeviceToken' /
In this case, your app server will more or less be acting as a straight proxy
to APNS. This will add a new entry to the user's set of push endpoints if the
DeviceToken did change, but old ones should get cleaned up when the app server
returns errors.
2. enable jid='push.monal.im' node='AppToken' /
In this case, the AppToken abstracts the DeviceToken so that things work even
when the DeviceToken changes, when there are multiple DeviceTokens for a user,
etc.
Note that the XMPP server can't actually distinguish between those cases, nor
should it need to. The semantics of that node value are meaningful only to the
app server ('push.monal.im'); the XMPP server only cares that it can publish to
that node. The app server could even be able to speak to both APNS and GCM,
delivering notifications to both iOS and Android clients for the same event.
Personally, I prefer and will be using the second option.
It may also be nice if the client could define what events it cared about.
Most mobile clients are probably not going to care much about anything other
than ping and message stanzas when operating in the background. There would
be significant battery life improvements if a client could take advantage of
XEP-0198 (with a very long expiration) to close the socket unless a message
or ping arrived. While XEP-0198 is probably beyond the scope of this
document, it’s probably how I and others will try to use push, so it may
warrant mentioning.
Yes, Christian had some thoughts on selecting what gets pushed out. I'll be
adding a way to do that in the XEP soon. In particular, I want to add that
mechanism to handle the case where my XMPP server might include message content
in the push data (because I the user am ok with that tradeoff), but an App
server could wish to *never* receive that information. I believe Monal would
fall into that group.
As it currently stands, when and what constitutes a push-worthy event is left
to the server implementation. Christian has been working on an implementation
for Ejabberd that uses XEP-0198 to determine when to start sending
notifications. I expect we'll be able to start standardizing some of those with
a bit more implementation experience.
- Lance
smime.p7s
Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-10 at 01:27 -0700, Lance Stout wrote: The defined workflow is that when the XMPP server detects something interesting happened, then it has a set of JID+node endpoints that can be informed of that interesting event via pubsub publishes. We could let the server have the option to pick which of those JID+node combos it will publish to, but there is not a defined way to choose any particular subset. However, there are options available to pick from, for example: - Was the interesting event associated with a particular resource that also had enabled push services? Send the publish to only those services. - Are there push services for a user which have not been enabled by any of the user's current online sessions? Send the publish only to those services. - Publish to all enabled services regardless of if the user has any online resources. I expect that the XEP will expand to cover this topic once we have some more implementation experience on what works well in practice. As there's currently no specification on what are interesting push events, it's completely up to the implementer. My implementation currently defines events as: a message / presence subscription was stored by stream management's resumption feature This means if a client enables push and then goes offline it'll never receive notifications (unless it goes back online). The server will send notifications only if the client closed the tcp connection without sending the closing stream tag or when a dead tcp connection is detected. Is this a valid interpretation? We should define what going offline means for push (at least say it's up to server implementations).
[Standards] Proposed XMPP Extension: Push
Hi all, I make an XMPP app on iOS called Monal. Much of my comments are based on my experiences developing an XMPP client on iOS for the past 6 years. My concerns may be Apple specific in some places but since the intent of the XEP is for a very general implementation, these issues should be considered. Apologies for resurrecting this discussion. The proposed XEP does not seem to address token expiration. On Apple platforms (and likely others) the push token will change periodically. This information is provided on a feedback channel to the App server but there is no way for it to communicate this to the XMPP server. There is really no way for the client to know it’s token has expired so It will not know to request a new one from the push service and the messages will just be lost. In addition even if the client were to somehow know, there doesn't seem to be a way for the client to refresh its token with the XMPP server. It may also be nice if the client could define what events it cared about. Most mobile clients are probably not going to care much about anything other than ping and message stanzas when operating in the background. There would be significant battery life improvements if a client could take advantage of XEP-0198 (with a very long expiration) to close the socket unless a message or ping arrived. While XEP-0198 is probably beyond the scope of this document, it’s probably how I and others will try to use push, so it may warrant mentioning. Thanks, -Anu
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-10 at 00:43 -0700, Lance Stout wrote: The intent in the security section is to not allow changing in-band what content gets delivered via the push notifications, not the enabling/disabling of push services. Otherwise, a client could surreptitiously change the settings to include private information like full message bodies and contact JIDs when the user had previously chosen not to allow publishing that data. I'll add some clarifying language. Of course, the same sort of opportunities exist for bad clients already, such as adding to a user's roster without their consent. However, such things are generally noticeable by the user and correctable. Push services are more shielded from the user's notice and thus much easier to exploit. I must have skipped the in-band-configuration not recommended paragraph the first time, so my suggestion of including settings in the enabled stanza is not recommended. An example for out-of-band configuration would be logging into a web interface and deselect include-message-bodies, right? That's a lot of effort, so maybe the server should at least tell the user how it's configured. Then the user can decide if re-configuring is necessary. Service discovery could return the user-specific configuration: iq from='jul...@capulet.lit' to='jul...@capulet.lit/balcony' id='disco1' type='result' query xmlns='http://jabber.org/protocol/disco#info' identity category='account' type='registered'/ feature var='urn:xmpp:push:0'/ x xmlns='jabber:x:data' field var='FORM_TYPE' valueurn:xmpp:push:0#configuration/value /field field var='include-message-count'value1value/field field var='include-message-bodies'value0value/field field var='include-senders'value0value/field field var='include-pending-subscription-count' value1value /field /x /query /iq Christian
Re: [Standards] Proposed XMPP Extension: Push
On Mar 10, 2015, at 8:51 AM, Christian Ulrich christian...@rechenwerk.net wrote: On Di, 2015-03-10 at 00:43 -0700, Lance Stout wrote: The intent in the security section is to not allow changing in-band what content gets delivered via the push notifications, not the enabling/disabling of push services. Otherwise, a client could surreptitiously change the settings to include private information like full message bodies and contact JIDs when the user had previously chosen not to allow publishing that data. I'll add some clarifying language. Of course, the same sort of opportunities exist for bad clients already, such as adding to a user's roster without their consent. However, such things are generally noticeable by the user and correctable. Push services are more shielded from the user's notice and thus much easier to exploit. I must have skipped the in-band-configuration not recommended paragraph the first time, so my suggestion of including settings in the enabled stanza is not recommended. Well, the text would need changing once that form is included in the XEP. The point though is that using that form will only be able to disable information in practice, not enable it. Even if you try enabling `include-message-bodies`, message bodies wouldn't actually be included if the user had previously disabled that option. I would gladly concede that I'm being overly paranoid here. Feedback welcome on if this cautious approach is even useful. An example for out-of-band configuration would be logging into a web interface and deselect include-message-bodies, right? That's a lot of effort, so maybe the server should at least tell the user how it's configured. Then the user can decide if re-configuring is necessary. Service discovery could return the user-specific configuration: iq from='jul...@capulet.lit' to='jul...@capulet.lit/balcony' id='disco1' type='result' query xmlns='http://jabber.org/protocol/disco#info' identity category='account' type='registered'/ feature var='urn:xmpp:push:0'/ x xmlns='jabber:x:data' field var='FORM_TYPE' valueurn:xmpp:push:0#configuration/value /field field var='include-message-count'value1value/field field var='include-message-bodies'value0value/field field var='include-senders'value0value/field field var='include-pending-subscription-count' value1value /field /x /query /iq +1, I imagine this will end up working like the disco features for pubsub. smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Push
On Mar 10, 2015, at 8:12 AM, Christian Ulrich christian...@rechenwerk.net wrote: Thanks for clarifying. Do we allow a client to send an enable stanza before resource binding then? We should not, if we want to allow the first two options you mentioned. I don't see a need to particularly restrict that ability since it's an App Client that will be making the enable call, so if the app needs to have a resource association it should wait until after binding. At the least, a suggestion to wait until binding would be good, right? more details I came across: The XEP defines the push notification field last-message-body. RFC 6120 says: Multiple instances of the body/ element MAY be included in a message stanza for the purpose of providing alternate versions of the same body, but only if each instance possesses an 'xml:lang' attribute with a distinct language value Quite a rare case I think, should the server just pick the first body or should it include all bodies like this: Ah, right. That's going to get tricky very quickly, but I'm not seeing anything better than your suggestion right now. Is there a reason why jingle events (like in the old version) are not included in the field list? The summary form is meant to be just that — a summary of information you will always want to have in a push so you can keep counters and badges, etc, synced properly. Not everything needs to be forced to fit into the summary form; you can include any other payload elements you wish. I've (maybe incorrectly?) thought of the summary data to be 'passive' data. So I'm undecided how Jingle would fit there yet, since it is more of a call-to-action that could need special treatment. I am anticipating an update to http://xmpp.org/extensions/xep-0353.html to define how to use it with push, which would cover this case. Could a server shutdown be a push event? No reason why not. I'm not sure what you'd do with the information, but if that's interesting to applications, then yeah. - Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-10 at 01:27 -0700, Lance Stout wrote: I may need to add additional clarifying language to the XEP then. Enabling and disabling as defined is for the bare JID account level. However, servers could keep track of which services a particular resource connection enabled and use that information to do more intelligent notifications. The defined workflow is that when the XMPP server detects something interesting happened, then it has a set of JID+node endpoints that can be informed of that interesting event via pubsub publishes. We could let the server have the option to pick which of those JID+node combos it will publish to, but there is not a defined way to choose any particular subset. However, there are options available to pick from, for example: - Was the interesting event associated with a particular resource that also had enabled push services? Send the publish to only those services. - Are there push services for a user which have not been enabled by any of the user's current online sessions? Send the publish only to those services. - Publish to all enabled services regardless of if the user has any online resources. I expect that the XEP will expand to cover this topic once we have some more implementation experience on what works well in practice. Of course, what defines interesting (and the levels and kinds of interesting) is left to the server implementation and to future XEPs, but there are a lot more potential things than just offline messages. Thanks for clarifying. Do we allow a client to send an enable stanza before resource binding then? We should not, if we want to allow the first two options you mentioned. For my implementation I decided to use a little trick for now in order to reduce complexity: Potentially interesting things are defined by stream management storing a stanza for later delivery. Important detail: When a push-enabled client enters the waiting-for-resumption state (a.k.a. zombie state), because stream management recognized the connection was closed, the push-module overwrites the resumption timeout (typically something like 5 min) with a long time span (e.g. 100 days). Interesting things thus happen only for clients having stream management resumption enabled. That's a little sad for clients without that feature but in my view has some advantages: - stream management may only be enabled when resource binding is complete, so all the potentially interesting stanzas are directed to a full jid. So the responsibility to route stanzas is delegated to the server's routing algorithm and might be configured by XEP-0354 in the future. - filtering mechanisms like CSI can be used (not possible if client is offline) - client stays in an available state, presence information is visible to presence subscribers (e.g. another resource might want to know the priority to become more / less available) more details I came across: The XEP defines the push notification field last-message-body. RFC 6120 says: Multiple instances of the body/ element MAY be included in a message stanza for the purpose of providing alternate versions of the same body, but only if each instance possesses an 'xml:lang' attribute with a distinct language value Quite a rare case I think, should the server just pick the first body or should it include all bodies like this: ... x xmlns='jabber:x:data' field var='FORM_TYPE'valueurn:xmpp:push:summary/value/field field var='last-message-body' option label='de'valueWarum bist du Romeo?/value option label='en'valueWherefore art thou Romeo?/value /field /x ... Is there a reason why jingle events (like in the old version) are not included in the field list? Could a server shutdown be a push event? Otherwise the server should store the list of enabled clients in persistant storage. I don't know if that's something for the XEP to mention. Christian
Re: [Standards] Proposed XMPP Extension: Push
2.1 Push Service, 'is what' is extranous. 3.2 Business Rules paragraph 3, Care SHOULD be taken. 'ought' is too relaxed a word to use here, and it doesn't fit in with the SHOULDs used in paragraph 2. Fixed 5 Enabling Notifications, Note. This reiterates the assumption that the App Client is aware of the push service, and can interact with the push client on the host device, AND can interact with the XMPP server for the setup phase. To pull an 'evil' use case out of the hat, what about the case where the App Client can only communicate with the XMPP server via the push service? Do you have a specific example in mind for that case? The App Server should accept the push service token also via out-of-band mechanisms. 6 Disabling Notifications. The App Server should also provide an out-of-band mechanism for disabling push notifications. While I agree with these behaviours, is it a standards scope creep to introduce SHOULDs for App Servers? Speaking of out-of-band mechanisms, I notice that they're mentioned in section 9 Security (Wheel of Fortune types miss 'implementations') as a SHOULD, while in-band modifications are not recommended. Even though that's what is being described in sections 5 and 6 ;). The intent in the security section is to not allow changing in-band what content gets delivered via the push notifications, not the enabling/disabling of push services. Otherwise, a client could surreptitiously change the settings to include private information like full message bodies and contact JIDs when the user had previously chosen not to allow publishing that data. I'll add some clarifying language. Of course, the same sort of opportunities exist for bad clients already, such as adding to a user's roster without their consent. However, such things are generally noticeable by the user and correctable. Push services are more shielded from the user's notice and thus much easier to exploit. 7.1 Publish Errors The second paragraph describes how the server MAY consider the endpoint still active until a certain number of errors have been accumulated. I think there should also be language declaring that the server may also retry an errored-out endpoint at a later time, something like (as para3): A server MAY also retry a disabled JID and node combination after period of time (eg, 1 day) in a disabled state. +1, added Example 13 before this section has one too many 't's in its title. You'd confuse the poor Wheel of Fortune contestants with 'notifictation'. :) Fixed 8 Remote Disabling of Notifications. to stop accepting notifications _from_ the user's XMPP server Fixed New update of the XEP with the above changes has been sent to the editors. — Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 10 Mar 2015, lancest...@gmail.com wrote: 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. Yes, that is the correct interpretation. Imagine for example that Apple's push service was actually implemented as an XMPP Push Service. The 'device ID' given to your iOS app would be the node. What a node actually represents is 100% completely arbitrary and decided by the App Server. The App Server you create for your new app could treat node == device ID so that it can target specific devices, or you might want to just always notify all of a user's devices (or none!) and thus node == user. All of which means that your XMPP server has no internal knowledge of phones or devices, only of applications/services. The problem with that approach is the the XMPP server needs to know if a device is online or not. It is the responsability of the XMPP to know which node to notify. To send a push notification to a device, it need a baseline and to compare with list of online devices. 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. I may need to add additional clarifying language to the XEP then. Enabling and disabling as defined is for the bare JID account level. However, servers could keep track of which services a particular resource connection enabled and use that information to do more intelligent notifications. We do not have a unique mapping between app and resource. For example, some client decide to use the same resource on all devices to be able to kick the existing session. Then, mapping the push to a resource is not enough, thus my device registry need. The defined workflow is that when the XMPP server detects something interesting happened, then it has a set of JID+node endpoints that can be informed of that interesting event via pubsub publishes. We could let the server have the option to pick which of those JID+node combos it will publish to, but there is not a defined way to choose any particular subset. However, there are options available to pick from, for example: - Was the interesting event associated with a particular resource that also had enabled push services? Send the publish to only those services. - Are there push services for a user which have not been enabled by any of the user's current online sessions? Send the publish only to those services. - Publish to all enabled services regardless of if the user has any online resources. It seems there is a case that is not handled is: publish to all devices on which the client is offline. I expect that the XEP will expand to cover this topic once we have some more implementation experience on what works well in practice. Of course, what defines interesting (and the levels and kinds of interesting) is left to the server implementation and to future XEPs, but there are a lot more potential things than just offline messages. Well, I have made a a custom implementation of such service already and I know that I need to keep a list of registered devices. When the session opens and it send the push configuration packet, it give again its device id. That allow the server to tell that this specific device is online (and put it offline on disconnect). The most basic and useful use case is to have that baseline of offline / online devices to be able to send push to all offline devices. Then your App Server needs to provide a way to disable notifications to your phone, which is already the case today for mobile apps. The topic of push is hard to talk about without assuming everything is directed to mobile devices, but the point is that XMPP servers really shouldn't need to know what a phone even is. Consider XMPP Push Services whose associated App Server is nothing more than a daily 'things you missed' email summary generator — a case with no mobile app, no mobile device, and no particular associated resource. Yes, I agree to cover those cases, but we need to have the case most of the developer expect to be covered answered as well. I think we can make that device registry (ability to pass a unique device ID on push enable in XMPP) optional. We will probably cover the use case that are not mobile in the same good way. But my feeling is that we need that registry if we want to cover the mobile case. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
Hello Christian, Sorry for the late reply: On 5 Mar 2015, christian...@rechenwerk.net wrote: 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. If we agree on semantic that is a node reprensent a device-application, I am fine indeed. Having the ability to have a human name for the node, would be handy. One of your requirements is still not met: you have to know the resource to enable / disable push. [...] 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 What about having the ability to list all your nodes (= devices) + the ability to delete a node as owner ? That would allow you to manage them as a users. I hope this helps, -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
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. Yes, that is the correct interpretation. Imagine for example that Apple's push service was actually implemented as an XMPP Push Service. The 'device ID' given to your iOS app would be the node. What a node actually represents is 100% completely arbitrary and decided by the App Server. The App Server you create for your new app could treat node == device ID so that it can target specific devices, or you might want to just always notify all of a user's devices (or none!) and thus node == user. All of which means that your XMPP server has no internal knowledge of phones or devices, only of applications/services. 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. I may need to add additional clarifying language to the XEP then. Enabling and disabling as defined is for the bare JID account level. However, servers could keep track of which services a particular resource connection enabled and use that information to do more intelligent notifications. The defined workflow is that when the XMPP server detects something interesting happened, then it has a set of JID+node endpoints that can be informed of that interesting event via pubsub publishes. We could let the server have the option to pick which of those JID+node combos it will publish to, but there is not a defined way to choose any particular subset. However, there are options available to pick from, for example: - Was the interesting event associated with a particular resource that also had enabled push services? Send the publish to only those services. - Are there push services for a user which have not been enabled by any of the user's current online sessions? Send the publish only to those services. - Publish to all enabled services regardless of if the user has any online resources. I expect that the XEP will expand to cover this topic once we have some more implementation experience on what works well in practice. Of course, what defines interesting (and the levels and kinds of interesting) is left to the server implementation and to future XEPs, but there are a lot more potential things than just offline messages. 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… Then your App Server needs to provide a way to disable notifications to your phone, which is already the case today for mobile apps. The topic of push is hard to talk about without assuming everything is directed to mobile devices, but the point is that XMPP servers really shouldn't need to know what a phone even is. Consider XMPP Push Services whose associated App Server is nothing more than a daily 'things you missed' email summary generator — a case with no mobile app, no mobile device, and no particular associated resource. 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 That is already the defined behaviour for the disable / element when no node is provided, but you would need to know the JID of the service. — Lance smime.p7s Description: S/MIME cryptographic signature
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
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 3 Mar 2015, christian...@rechenwerk.net wrote: Then the client app hands this information over to its xmpp server using the enable-iq stanza so the xmpp server can publish push notifications when the client app is not reachable. What does it mean ? Suppose I am using MyApp on iPad and iPhone, with the same JID and resource (not using them at the same time). What does not being reachable mean ? That's what I mean when I talk about a client registry that the XMPP server has to know about. To know that a client is not reachable or is missing, it need to have a list. It needs to be able to know for a given JID what are the client app - device tuple to be notified. I my view the app server cannot know that, because it does not know anything about the reachability. I think one node representing multiple client apps is only possible if all of these apps use the same push service type, e.g. all of them use app ShinyApp on iOS. Otherwise the app server which maybe only supports one push service type can't decide if a published notification is for the client it is serving. How can I see all my client app registered for push ? How can I manage that list ? from which side? I think each client app is responsible for its own registration. Yes, but the list need to be managed. Supposed I had two devices and now handed over one to someone else. I need to be able to get the list of devices that serve a reference for XMPP server to trigger push notifications sending. And as a user, I need to be able to manually clean that list in some rare but important cases. Does it make sense ? -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 2 Mar 2015, edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Push Abstract: This specification defines a way for an XMPP servers to broadcast information for use in push notifications to mobile and other devices. I have several questions regarding things that are not clear for me after first read: - Is app client really an instance of an application running on a specific device ? I thought at first the node what acting as a device registry, but, it seems it does not as a node is defined as: Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user. So, basically, I am lost. What is acting as a Client App registry ? How can I see all my client app registered for push ? How can I manage that list ? - What is the role of node ? Do you have example on how they are used created and deleted ? - I could not see how that step is performed in the XEP: The App Client sends the token to the App Server for later use. Sorry for the very basic questions and thanks for your feedback. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
On 03.03.2015 16:16, Mickaël Rémond wrote: Hello, On 3 Mar 2015,christian...@rechenwerk.net wrote: Then the client app hands this information over to its xmpp server using the enable-iq stanza so the xmpp server can publish push notifications when the client app is not reachable. What does it mean ? Suppose I am using MyApp on iPad and iPhone, with the same JID and resource (not using them at the same time). What does not being reachable mean ? You are right, the draft does not define any events when push notifications should be sent. The old version didn't either but it defined three cases to consider when such an event occurs: [1]. I don't think there needs to be a list of unreachable clients, the server knows when a client is not reachable: In my (currently broken) ejabberd implementation I chose to send notifications in the following cases: - Stream management stores a stanza for a push-enabled user - mod_offline stores a message for a push-enabled user This has quite complicated implications, because message delivery rules (https://tools.ietf.org/html/rfc6121#section-8.5.4) are quite complicated. First try to write them down: One or multiple push notifications are published if - a message addressed to a full jid arrives AND the user has push enabled for this full jid AND a session with this full jid is in stream management's zombie state - a message addressed to a full jid arrives AND there's no non-negative resource for that jid AND a push-enabled jid has a session with the highest priority AND this session is in stream management's zombie state - a message arrives addressed to a bare jid arrives AND the highest priority session is for a push-enabled jid AND this session is in stream management's zombie state - a message addressed to full or bare jid arrives AND there's no non-negative resource AND there's one (or multiple) push-enabled jids This is probably incomplete and can be written in a better form. The question is, do we want to define these events in the XEP or leave it up to the server when to send a push notification? I have to think more about this. Yes, but the list need to be managed. Supposed I had two devices and now handed over one to someone else. I need to be able to get the list of devices that serve a reference for XMPP server to trigger push notifications sending. And as a user, I need to be able to manually clean that list in some rare but important cases. Does it make sense ? I'm not sure if I understand this. If you registered at the app server with resource A and enabled push at your XMPP server for A, you can unregister and disable later for A on another device. But maybe I got you wrong. What case are you thinking of? Christian [1] https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md#where-to-deliver-notifications
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 3 Mar 2015, christian...@rechenwerk.net wrote: On 03.03.2015 16:16, Mickaël Rémond wrote: Hello, On 3 Mar 2015,christian...@rechenwerk.net wrote: Then the client app hands this information over to its xmpp server using the enable-iq stanza so the xmpp server can publish push notifications when the client app is not reachable. What does it mean ? Suppose I am using MyApp on iPad and iPhone, with the same JID and resource (not using them at the same time). What does not being reachable mean ? You are right, the draft does not define any events when push notifications should be sent. The old version didn't either but it defined three cases to consider when such an event occurs: [1]. I don't think there needs to be a list of unreachable clients, the server knows when a client is not reachable: Well, in our implementation, we found that the server has no proper way to know where to push unless you have a registry of client. 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 In my (currently broken) ejabberd implementation I chose to send notifications in the following cases: - Stream management stores a stanza for a push-enabled user - mod_offline stores a message for a push-enabled user This has quite complicated implications, because message delivery rules (https://tools.ietf.org/html/rfc6121#section-8.5.4) are quite complicated. First try to write them down: One or multiple push notifications are published if [...] This is probably incomplete and can be written in a better form. The question is, do we want to define these events in the XEP or leave it up to the server when to send a push notification? I have to think more about this. Yes. I agree about the routing for online users. This is not easy but can be sorted out by server developers. However, I think we miss a level of routing for offline resources. At some point, I was toying with the idea of having queues to deliver offline messages to all devices when they reconnect. This was solve in some way with archiving as a way to provide catchup. However, the problem is back with push, as the client stay offline and you want to notify them with push. Relying on offline means you miss a rule: Delivering to offline devices means you need to know the offline devices. Yes, but the list need to be managed. Supposed I had two devices and now handed over one to someone else. I need to be able to get the list of devices that serve a reference for XMPP server to trigger push notifications sending. And as a user, I need to be able to manually clean that list in some rare but important cases. Does it make sense ? I'm not sure if I understand this. If you registered at the app server with resource A and enabled push at your XMPP server for A, you can unregister and disable later for A on another device. But maybe I got you wrong. What case are you thinking of? 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. I hope this help :) -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
On Mar 2, 2015, at 4:11 PM, Christian Ulrich christian...@rechenwerk.net wrote: I started implementing an older version of the XEP [1] as an ejabberd module. It's on github [2]. Currently I'm updating it to the new version. Awesome and ^5! My implementation includes the app server (currently only for Ubuntu push), so the app server and the XMPP server are one instance. In order to explain why I chose to do this I have to expand the scope a little. I understand why you'd want to set things up that way, but IMO this is not going to be tenable in the long run (explained below). In case of Apple's, Google's and Microsoft's push services the app server needs secret authorization data (certificate or secret key) to send push notifications. So all client app instances need to register with a central app server. In Ubuntu's push service [3] it's different. The app server only needs the client's token and app_id for authorization with ubuntu's server. I'd like to keep decentrality alive where possible and in case of Ubuntu Push it is (at least in the non-proprietary part). So I'd like to enable an arbitrary XMPP server to send notifications to Ubuntu's push service. Given that you read the previous draft, I'm sure you appreciate that the topic of push comes with a very tangled knot of terminology, so please bear with me trying to explain my thoughts here. I think this approach is trying to decentralize the wrong aspect. 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. - apps that need to register with one central app server will know its app server's hostname, but for an app supporting arbitrary app servers there's no way of dicovering a hostname. So it should be able to ask its xmpp server for a hostname serving a specific push service type. Maybe something like this (up means ubuntu push): iq type='get' from='ro...@montague.net/orchard' to='montague.net' id='items3' query xmlns='http://jabber.org/protocol/disco#items' node='urn:xmpp:push:0#up'/ /iq iq type='result' from='montague.net' to='ro...@montague.net/orchard' id='items3' query xmlns='http://jabber.org/protocol/disco#items' node='urn:xmpp:push:0#up' item jid='push-up.montague.net'/ /query /iq 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 interesting idea to pursue. Perhaps we need to define how to create disco#info identities for this? Would this be a follow-up XEP or defined here? iq type='result' from='my-app-server.montague.example' id='x13' query xmlns='http://jabber.org/protocol/disco#info' identity category='pubsub' type='push' / identity category='app-server' type='my-cool-app-name' / /query /iq This needs more implementation experience to hammer out. - arbitrary app servers require a unified registration process. The draft suggests to use XEP-0077, that's ok I think, but then we need to define what data the client has to provide. My suggestion for XEP-0077 registration fields: * token (mandatory) * app-id
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-03 at 11:23 +0100, Mickaël Rémond wrote: - Is app client really an instance of an application running on a specific device ? I thought at first the node what acting as a device registry, but, it seems it does not as a node is defined as: Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user. So, basically, I am lost. What is acting as a Client App registry ? In my understanding an app client is the actual app running an iOS etc. The registration process is not defined (XEP-0077 is suggested). I think the idea is that there could be a proprietary app server that has nothing to do with XMPP which does the dispatching of push notifications to the push service (in the old draft version the push service, e.g. APNS, was called proprietary push service and packets sent to it were called proprietary push notifications, this makes it clearer). It needs the token and maybe additional information (at Ubuntu push an app-id) for that. The interface between app server and xmpp server is a pubsub node. The app server creates a node on a pubsub service (could be a third instance or a part of the app server) and subscribes to it. The information required for publishing on that node (hostname, node name, maybe a secret) are sent to the client app as a registration response. Then the client app hands this information over to its xmpp server using the enable-iq stanza so the xmpp server can publish push notifications when the client app is not reachable. I think one node representing multiple client apps is only possible if all of these apps use the same push service type, e.g. all of them use app ShinyApp on iOS. Otherwise the app server which maybe only supports one push service type can't decide if a published notification is for the client it is serving. How can I see all my client app registered for push ? How can I manage that list ? from which side? I think each client app is responsible for its own registration.
Re: [Standards] Proposed XMPP Extension: Push
I was just waiting for this :-) Thanks to Lance and everyone that contributed to the push XEP. I'll start experimenting with it in a few days and eventually comment the XEP itself if I bump into practical problems. On Mon, Mar 2, 2015 at 10:46 PM, XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Push Abstract: This specification defines a way for an XMPP servers to broadcast information for use in push notifications to mobile and other devices. URL: http://xmpp.org/extensions/inbox/push.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. -- Daniele
[Standards] Proposed XMPP Extension: Push
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Push Abstract: This specification defines a way for an XMPP servers to broadcast information for use in push notifications to mobile and other devices. URL: http://xmpp.org/extensions/inbox/push.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: Push
On Mo, 2015-03-02 at 22:53 +0100, Daniele Ricci wrote: I was just waiting for this :-) Thanks to Lance and everyone that contributed to the push XEP. I'll start experimenting with it in a few days and eventually comment the XEP itself if I bump into practical problems. On Mon, Mar 2, 2015 at 10:46 PM, XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Push Abstract: This specification defines a way for an XMPP servers to broadcast information for use in push notifications to mobile and other devices. URL: http://xmpp.org/extensions/inbox/push.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. I started implementing an older version of the XEP [1] as an ejabberd module. It's on github [2]. Currently I'm updating it to the new version. My implementation includes the app server (currently only for Ubuntu push), so the app server and the XMPP server are one instance. In order to explain why I chose to do this I have to expand the scope a little. In case of Apple's, Google's and Microsoft's push services the app server needs secret authorization data (certificate or secret key) to send push notifications. So all client app instances need to register with a central app server. In Ubuntu's push service [3] it's different. The app server only needs the client's token and app_id for authorization with ubuntu's server. I'd like to keep decentrality alive where possible and in case of Ubuntu Push it is (at least in the non-proprietary part). So I'd like to enable an arbitrary XMPP server to send notifications to Ubuntu's push service. It's not obligatory to merge app server and XMPP server to achieve this but it lowers the administration effort (especially for ejabberd clusters) and increases efficiency, if the app chooses its home server as app server. Regarding my requirements there are two little problems with the current draft: - apps that need to register with one central app server will know its app server's hostname, but for an app supporting arbitrary app servers there's no way of dicovering a hostname. So it should be able to ask its xmpp server for a hostname serving a specific push service type. Maybe something like this (up means ubuntu push): iq type='get' from='ro...@montague.net/orchard' to='montague.net' id='items3' query xmlns='http://jabber.org/protocol/disco#items' node='urn:xmpp:push:0#up'/ /iq iq type='result' from='montague.net' to='ro...@montague.net/orchard' id='items3' query xmlns='http://jabber.org/protocol/disco#items' node='urn:xmpp:push:0#up' item jid='push-up.montague.net'/ /query /iq - arbitrary app servers require a unified registration process. The draft suggests to use XEP-0077, that's ok I think, but then we need to define what data the client has to provide. My suggestion for XEP-0077 registration fields: * token (mandatory) * app-id (optional, relevant for Ubuntu push) * silent-push (optional, relevant for iOS and Android (I think)) I think an example for registration should be in the XEP. Moreover I'm missing an example for configuring the XMPP server part regarding privacy. In [1] options like 'include-senders' and 'include-bodies' were mentioned. How about defining some publish-options (XEP-0060 §7.1.5) which can be included in the enable iq-stanza. The XMPP server will consider these when publishing an item and doesn't need to include them into the pubsub stanza. Like this: iq type='set' id='x43' enable xmlns='urn:xmpp:push:0' jid='push-up.montague.net' node='yxs32uqsflafdk3iuqo' x xmlns='jabber:x:data' field var='FORM_TYPE' valuehttp://jabber.org/protocol/pubsub#publish-options/value /field field var='include-bodies'value0value/field field var='include-senders'value0value/field field var='include-message-count'value1value/field /x /enable /iq Christian P.S. thank you Lance and the others involved in writing the draft. [1] https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md [2] https://github.com/royneary/ejabberd/blob/master/src/mod_push.erl [3] https://developer.ubuntu.com/en/apps/platform/guides/push-notifications-client-guide/
