Re: [Standards] Push notification XEP
We're going to be switching the Buddycloud-pusher to the XEP and making it as standards compliant as possible. Right now it Pushes to Android and Email: https://github.com/buddycloud/buddycloud-pusher/blob/master/README.md#component-design. We're using it in production already and it just works. Code is all on github. S. On 2 February 2014 15:16, Adán Sánchez de Pedro Crespo adans...@waalt.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So do I! I'm eager for seeing this move forward and start making experimental/reference implementations. You can count on a strophe client plugin and prosody server one ;) Regards, - -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS7lNQAAoJEOKCghY7/+mkvaEIAJ6REShFrifFBhOcAMaoTpLq msau0/fUXo8Py3XXwmR1D0lcWc/IaaPPjqyooc/SYf4UHUaADj8FR4UX6VFDnN0B /YzamgM7//p+8DJsSJ1zga58qlJmiFEn0xFsPNZdvgawKtfE1wlRgn+ztwdQnWGf 1cLJ5leunUToEmXNWnvZOZ6M+/NUahsVpccbiv9r8dBBtV2hN5bYm3UwsTwmWUtU kT1rln3gzXVWmFVIpAUyHLCQqujPZ0w0dwdv006pPX4IQCwKUyn8e+gel7bTZB4/ hF6Hovnxa/3FA1okE823HWjAk+V8xbHT+z+lkqqiXs5tRH9Ht41P5pqKj0D6dq0= =AXuq -END PGP SIGNATURE- -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Push notification XEP
Sorry for the late reply Lance. That was what I was missing The client app sends an IQ to its backend service, registering a device ID. And this can happen because the CBS is connected to the user's server in some way (the CBS can verify the user's server). For the rest, the diagrams are very clear, and I can begin implementing it in Kontalk [1], possibly as a standalone component, as soon as it reaches a more-or-less stable status. Did you have any chance to discuss it in person at FOSDEM? How's going there by the way? [1] http://www.kontalk.org/ On Mon, Jan 27, 2014 at 9:16 PM, Lance Stout lancest...@gmail.com wrote: I tried writing up an explanation, but it ended up rather long-winded and confusing to follow. So I made some diagrams instead :) https://cloudup.com/c223kt48cGZ The flows presented there modify what I have in that write-up to make some things simpler. Let me know if there are areas that need more fleshing out for explanation, or if your questions weren't fully addressed. — Lance -- Daniele
Re: [Standards] Push notification XEP
Did you have any chance to discuss it in person at FOSDEM? How's going there by the way? Yes, we had quite a bit of good discussion on this topic at the summit, and now that I have all of the notes I will have an updated Push XEP proposal out in a few days. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Push notification XEP
That's great :-) I'll look forward to read it. Daniele On 2 Feb 2014 15:00, Lance Stout lancest...@gmail.com wrote: Did you have any chance to discuss it in person at FOSDEM? How's going there by the way? Yes, we had quite a bit of good discussion on this topic at the summit, and now that I have all of the notes I will have an updated Push XEP proposal out in a few days.
Re: [Standards] Push notification XEP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So do I! I'm eager for seeing this move forward and start making experimental/reference implementations. You can count on a strophe client plugin and prosody server one ;) Regards, - -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS7lNQAAoJEOKCghY7/+mkvaEIAJ6REShFrifFBhOcAMaoTpLq msau0/fUXo8Py3XXwmR1D0lcWc/IaaPPjqyooc/SYf4UHUaADj8FR4UX6VFDnN0B /YzamgM7//p+8DJsSJ1zga58qlJmiFEn0xFsPNZdvgawKtfE1wlRgn+ztwdQnWGf 1cLJ5leunUToEmXNWnvZOZ6M+/NUahsVpccbiv9r8dBBtV2hN5bYm3UwsTwmWUtU kT1rln3gzXVWmFVIpAUyHLCQqujPZ0w0dwdv006pPX4IQCwKUyn8e+gel7bTZB4/ hF6Hovnxa/3FA1okE823HWjAk+V8xbHT+z+lkqqiXs5tRH9Ht41P5pqKj0D6dq0= =AXuq -END PGP SIGNATURE-
Re: [Standards] Push notification XEP
On Tue, Jan 21, 2014 at 10:44 PM, Lance Stout lancest...@gmail.com wrote: So I install Otalk on my phone, and establish a connection to my own server, lance.im. The Otalk client detects that lance.im supports the push extension via disco/caps. The Otalk client then registers the 'push.otalk.im' endpoint (which the Otalk client knows about because it's hardcoded) as a recipient for push notifications for la...@lance.im on lance.im. Included in that registration MAY be some ID value that the Otalk client provides, which is completely opaque and only intended for use by 'push.otalk.im' as the registered endpoint. (Eg, the Otalk client app could request an ID value from its backend server that associates 'la...@lance.im' with a device id/token before starting the registration process at lance.im.) Hi Lance, that's what I was talking about: that opaque ID is the device token which must reach the push notification component, otherwise it wouldn't know how to send the push notification request to the proprietary server (e.g. GCM). If I got it right, it's in the id attribute of the register/ element so, I didn't notice it at first. And, if I got this right too, this sentence should be expanded: MAY specify an opaque id attribute that the receiving service MAY use to target that specific device when using stream management adding something like or when sending a push notification to the proprietary service or something like that. Can you please explain this: When set to client, the recipient will receive a notification only when there are no online connections that have specified the same recipient. Also you say in your e-mail it's up to the app's backend service to forward that notification over its preferred proprietary push service to the installed app on some device. Are you saying that the client has to connect to the push notification proprietary service instead of the server doing it? -- Daniele
Re: [Standards] Push notification XEP
I tried writing up an explanation, but it ended up rather long-winded and confusing to follow. So I made some diagrams instead :) https://cloudup.com/c223kt48cGZ The flows presented there modify what I have in that write-up to make some things simpler. Let me know if there are areas that need more fleshing out for explanation, or if your questions weren't fully addressed. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Push notification XEP
It sounds like what we've been doing with the buddycloud pusher: https://github.com/buddycloud/buddycloud-pusher. We currently use it to send GCM and emails regarding buddycloud-related events, as per its documentation, but it can be easily extended to push any XMPP event to any pusher service, eg.: Apple's, SMS. Regards, Abmar On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci daniele.ath...@gmail.comwrote: Hello list, I was thinking of writing a XEP for sending a sender ID (Google Cloud Messaging) or a device token (Apple Push Notification Service) or any other push notification service token (that is, a generic one) to the server. Almost all push notification services works the same way: the server provides a provider ID to the client and the client provides a device token to the server. I was thinking of using service discovery to advertise the service from a server: iq from='example.com' type='result' id='H-2' to='al...@example.com' query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/extensions/presence#push' item node='SENDER-ID' jid='gcm.push.example.com' name='Google Cloud Messaging'/ item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple Push Notification Service'/ item ... / /query /iq In the node attribute I'd put the provider ID I was talking about earlier. Device token could be sent using a presence update from the client: presence status.../status ... c xmlns='http://jabber.org/extensions/presence#push provider='gcm.push.example.com'REGISTRATION-ID/c /presence (that would need to be filtered by the server before broadcasting the presence update though, for security reasons). Or an iq to the push notification address could be used: iq to='gcm.push.example.com' token xmlns='http://jabber.org/extensions/presence#push 'DEVICE-TOKEN/token /iq I'd really appreciate some feedback. I think it would be a useful XEP. Regards, -- Daniele -- Abmar Barros MSc in Computer Science from the Federal University of Campina Grande - www.ufcg.edu.br OurGrid Team Leader - www.ourgrid.org Buddycloud Dev - www.buddycloud.org Paraíba - Brazil
Re: [Standards] Push notification XEP
I was thinking of a more specific (and simpler) approach to just using push notification services. Buddycloud is much more than that. On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros abma...@gmail.com wrote: It sounds like what we've been doing with the buddycloud pusher: https://github.com/buddycloud/buddycloud-pusher. We currently use it to send GCM and emails regarding buddycloud-related events, as per its documentation, but it can be easily extended to push any XMPP event to any pusher service, eg.: Apple's, SMS. Regards, Abmar On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci daniele.ath...@gmail.com wrote: Hello list, I was thinking of writing a XEP for sending a sender ID (Google Cloud Messaging) or a device token (Apple Push Notification Service) or any other push notification service token (that is, a generic one) to the server. Almost all push notification services works the same way: the server provides a provider ID to the client and the client provides a device token to the server. I was thinking of using service discovery to advertise the service from a server: iq from='example.com' type='result' id='H-2' to='al...@example.com' query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/extensions/presence#push' item node='SENDER-ID' jid='gcm.push.example.com' name='Google Cloud Messaging'/ item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple Push Notification Service'/ item ... / /query /iq In the node attribute I'd put the provider ID I was talking about earlier. Device token could be sent using a presence update from the client: presence status.../status ... c xmlns='http://jabber.org/extensions/presence#push provider='gcm.push.example.com'REGISTRATION-ID/c /presence (that would need to be filtered by the server before broadcasting the presence update though, for security reasons). Or an iq to the push notification address could be used: iq to='gcm.push.example.com' token xmlns='http://jabber.org/extensions/presence#push'DEVICE-TOKEN/token /iq I'd really appreciate some feedback. I think it would be a useful XEP. Regards, -- Daniele -- Abmar Barros MSc in Computer Science from the Federal University of Campina Grande - www.ufcg.edu.br OurGrid Team Leader - www.ourgrid.org Buddycloud Dev - www.buddycloud.org Paraíba - Brazil -- Daniele
Re: [Standards] Push notification XEP
Yes but the approach that this bodycloud component (XEP-0114) could easily be written into more or less a XEP. /Steffen On 21 Jan 2014, at 11:51, Daniele Ricci daniele.ath...@gmail.com wrote: I was thinking of a more specific (and simpler) approach to just using push notification services. Buddycloud is much more than that. On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros abma...@gmail.com wrote: It sounds like what we've been doing with the buddycloud pusher: https://github.com/buddycloud/buddycloud-pusher. We currently use it to send GCM and emails regarding buddycloud-related events, as per its documentation, but it can be easily extended to push any XMPP event to any pusher service, eg.: Apple's, SMS. Regards, Abmar On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci daniele.ath...@gmail.com wrote: Hello list, I was thinking of writing a XEP for sending a sender ID (Google Cloud Messaging) or a device token (Apple Push Notification Service) or any other push notification service token (that is, a generic one) to the server. Almost all push notification services works the same way: the server provides a provider ID to the client and the client provides a device token to the server. I was thinking of using service discovery to advertise the service from a server: iq from='example.com' type='result' id='H-2' to='al...@example.com' query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/extensions/presence#push' item node='SENDER-ID' jid='gcm.push.example.com' name='Google Cloud Messaging'/ item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple Push Notification Service'/ item ... / /query /iq In the node attribute I'd put the provider ID I was talking about earlier. Device token could be sent using a presence update from the client: presence status.../status ... c xmlns='http://jabber.org/extensions/presence#push provider='gcm.push.example.com'REGISTRATION-ID/c /presence (that would need to be filtered by the server before broadcasting the presence update though, for security reasons). Or an iq to the push notification address could be used: iq to='gcm.push.example.com' token xmlns='http://jabber.org/extensions/presence#push'DEVICE-TOKEN/token /iq I'd really appreciate some feedback. I think it would be a useful XEP. Regards, -- Daniele -- Abmar Barros MSc in Computer Science from the Federal University of Campina Grande - www.ufcg.edu.br OurGrid Team Leader - www.ourgrid.org Buddycloud Dev - www.buddycloud.org Paraíba - Brazil -- Daniele smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Push notification XEP
The Buddycloud pusher approach is - Run as a component - be generic: don't care about the specific push service (email, Google, Apple, next-big-thing) - Give users a way to enable/disable it - Advertise it as a service using SRV records (virtual host for other domains that don't want to run a full push service) Would be nice to think about how push notifications could work with some of the SIFT specs. Eg: a new message would trigger a push, wake an Android App, sync, kill connection, go back to not keeping an open connection. Daniele - will you be at the Summit? S. On 21 January 2014 11:53, Steffen Larsen zoo...@gmail.com wrote: Yes but the approach that this bodycloud component (XEP-0114) could easily be written into more or less a XEP. /Steffen On 21 Jan 2014, at 11:51, Daniele Ricci daniele.ath...@gmail.com wrote: I was thinking of a more specific (and simpler) approach to just using push notification services. Buddycloud is much more than that. On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros abma...@gmail.com wrote: It sounds like what we've been doing with the buddycloud pusher: https://github.com/buddycloud/buddycloud-pusher. We currently use it to send GCM and emails regarding buddycloud-related events, as per its documentation, but it can be easily extended to push any XMPP event to any pusher service, eg.: Apple's, SMS. Regards, Abmar On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci daniele.ath...@gmail.com wrote: Hello list, I was thinking of writing a XEP for sending a sender ID (Google Cloud Messaging) or a device token (Apple Push Notification Service) or any other push notification service token (that is, a generic one) to the server. Almost all push notification services works the same way: the server provides a provider ID to the client and the client provides a device token to the server. I was thinking of using service discovery to advertise the service from a server: iq from='example.com' type='result' id='H-2' to='al...@example.com' query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/extensions/presence#push' item node='SENDER-ID' jid='gcm.push.example.com' name='Google Cloud Messaging'/ item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple Push Notification Service'/ item ... / /query /iq In the node attribute I'd put the provider ID I was talking about earlier. Device token could be sent using a presence update from the client: presence status.../status ... c xmlns='http://jabber.org/extensions/presence#push provider='gcm.push.example.com'REGISTRATION-ID/c /presence (that would need to be filtered by the server before broadcasting the presence update though, for security reasons). Or an iq to the push notification address could be used: iq to='gcm.push.example.com' token xmlns='http://jabber.org/extensions/presence#push 'DEVICE-TOKEN/token /iq I'd really appreciate some feedback. I think it would be a useful XEP. Regards, -- Daniele -- Abmar Barros MSc in Computer Science from the Federal University of Campina Grande - www.ufcg.edu.br OurGrid Team Leader - www.ourgrid.org Buddycloud Dev - www.buddycloud.org Paraíba - Brazil -- Daniele -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Push notification XEP
Hi Daniele, On 21 January 2014 09:58, Daniele Ricci daniele.ath...@gmail.com wrote: Hello list, I was thinking of writing a XEP for sending a sender ID (Google Cloud Messaging) or a device token (Apple Push Notification Service) or any other push notification service token (that is, a generic one) to the server. Almost all push notification services works the same way: the server provides a provider ID to the client and the client provides a device token to the server. We discussed precisely this at the last summit. Nobody has actually written a XEP yet, it would be great if you're able to write one :) Your approach is fine, the only difference I see is that you have a different JID for each service, whereas we were considering a single push service that accepted requests from all types of devices (e.g. push.example.com). I have to say I prefer this all in one approach, but feel free to make a case for splitting them up. Regards, Matthew
Re: [Standards] Push notification XEP
We discussed precisely this at the last summit. Nobody has actually written a XEP yet, it would be great if you're able to write one :) I wrote this up to summarize our discussions at the summit and after: http://legastero.github.io/customxeps/extensions/push.html I've only given a quick look, but it seems similar to the approach that kicked off this thread, and to the ideas behind the BuddyCloud push component. This is the model we arrived at in October: Definitions: 1) Client app: The thing the user is actually using and interacting with on a device. 2) Client Backend Service (CBS): A server run by the maintainers of the client app. The CBS is able to integrate any open/Proprietary Push Notifications to deliver updates to its associated client apps. 3) Proprietary Push Notifications: Apple's Push Notifications, Google Cloud Messaging, etc 4) XMPP Push Service: An XMPP server component/plugin which delivers messages to a CBS on behalf of a user. Goal: Allow a user to have push notification experience using an arbitrary third-party Client App with their personal server. Making this possible implies that use cases where the Client App and XMPP server are part of the same overall system are also possible (eg, a special purpose app that just happens to be using XMPP as an implementation detail, not a generic chat application). Note: It is the CBS that talks with any Proprietary Push service, not the XMPP server itself. This is done because the CBS has private key material that it won't share with an arbitrary XMPP server. In many Proprietary Push Services, the notification will appear to come from the Client App and Client App developers aren't going to give you their private keys so you can enable push for their client on your personal server and risk allowing anyone to spoof their notifications. So what we end up with is this flow: 1) User establishes stream using Client App. 2) Client App discovers that the server has an XMPP Push Service 3) Client App registers the stream with the push service, indicating an endpoint for its CBS that will receive the pushed data. 4) When certain conditions are met (user has no connections, no connection for a given Client App, a stream in XEP-0198 zombie mode, etc) the XMPP Push Service sends a to-be-decided update to the CBS. 5) The CBS can then convert the received update into an open/Proprietary Push Notification. 6) The user's device receives a push notification from their Client App. *) At any time, the user can view the set of endpoints that are registered to receive notifications, and remove them. There are still things that need to be worked out, namely what does an update contain and when exactly do we trigger them. The goal is that we provide sufficient use case coverage to heavily discourage Client App from deciding to proxy the entire session through its CBS. We have seen Client Apps that do this and store user credentials in the CBS to create connections at any time, and that behaviour makes me nervous. However, that approach is 'simplest' and gives Client App developers the greatest degree of control, so this will need a lot of input from existing Client App developers to be successful. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Push notification XEP
The question also arises if the XEP should allow you to enable/disable different types of push notifications e.g. Chat Message, MUC Invites etc or just be for setting your token(s). Regards Spencer On Tuesday, 21 January 2014 at 16:52, Matthew Wild wrote: Hi Daniele, On 21 January 2014 09:58, Daniele Ricci daniele.ath...@gmail.com wrote: Hello list, I was thinking of writing a XEP for sending a sender ID (Google Cloud Messaging) or a device token (Apple Push Notification Service) or any other push notification service token (that is, a generic one) to the server. Almost all push notification services works the same way: the server provides a provider ID to the client and the client provides a device token to the server. We discussed precisely this at the last summit. Nobody has actually written a XEP yet, it would be great if you're able to write one :) Your approach is fine, the only difference I see is that you have a different JID for each service, whereas we were considering a single push service that accepted requests from all types of devices (e.g. push.example.com). I have to say I prefer this all in one approach, but feel free to make a case for splitting them up. Regards, Matthew
Re: [Standards] Push notification XEP
Hi everyone, sorry I won't be at the summit. Any chance FOSDEM stops in Italy? :-) I can't make any promise, but I'll try to make it for next year. Your idea [1] seems good to me. A couple of questions: 1. I assume the endpoint is the equivalent of a device token for APNS and registration ID for GCM 2. I didn't see a way to make the server advertise its provider ID which is necessary at least for APNS and GCM. Maybe in the discovery reply stanza? I still have to study the others (Windows, Blackberry, Symbian?) because there might be more stuff for the XEP to cover. Let me get back at you, I'll see what I can find in the developer's reference, but I doubt they will be that different from Apple or Google. [1] http://legastero.github.io/customxeps/extensions/push.html On Tue, Jan 21, 2014 at 7:01 PM, Lance Stout lancest...@gmail.com wrote: We discussed precisely this at the last summit. Nobody has actually written a XEP yet, it would be great if you're able to write one :) I wrote this up to summarize our discussions at the summit and after: http://legastero.github.io/customxeps/extensions/push.html I've only given a quick look, but it seems similar to the approach that kicked off this thread, and to the ideas behind the BuddyCloud push component. This is the model we arrived at in October: Definitions: 1) Client app: The thing the user is actually using and interacting with on a device. 2) Client Backend Service (CBS): A server run by the maintainers of the client app. The CBS is able to integrate any open/Proprietary Push Notifications to deliver updates to its associated client apps. 3) Proprietary Push Notifications: Apple's Push Notifications, Google Cloud Messaging, etc 4) XMPP Push Service: An XMPP server component/plugin which delivers messages to a CBS on behalf of a user. Goal: Allow a user to have push notification experience using an arbitrary third-party Client App with their personal server. Making this possible implies that use cases where the Client App and XMPP server are part of the same overall system are also possible (eg, a special purpose app that just happens to be using XMPP as an implementation detail, not a generic chat application). Note: It is the CBS that talks with any Proprietary Push service, not the XMPP server itself. This is done because the CBS has private key material that it won't share with an arbitrary XMPP server. In many Proprietary Push Services, the notification will appear to come from the Client App and Client App developers aren't going to give you their private keys so you can enable push for their client on your personal server and risk allowing anyone to spoof their notifications. So what we end up with is this flow: 1) User establishes stream using Client App. 2) Client App discovers that the server has an XMPP Push Service 3) Client App registers the stream with the push service, indicating an endpoint for its CBS that will receive the pushed data. 4) When certain conditions are met (user has no connections, no connection for a given Client App, a stream in XEP-0198 zombie mode, etc) the XMPP Push Service sends a to-be-decided update to the CBS. 5) The CBS can then convert the received update into an open/Proprietary Push Notification. 6) The user's device receives a push notification from their Client App. *) At any time, the user can view the set of endpoints that are registered to receive notifications, and remove them. There are still things that need to be worked out, namely what does an update contain and when exactly do we trigger them. The goal is that we provide sufficient use case coverage to heavily discourage Client App from deciding to proxy the entire session through its CBS. We have seen Client Apps that do this and store user credentials in the CBS to create connections at any time, and that behaviour makes me nervous. However, that approach is 'simplest' and gives Client App developers the greatest degree of control, so this will need a lot of input from existing Client App developers to be successful. — Lance -- Daniele
Re: [Standards] Push notification XEP
1. I assume the endpoint is the equivalent of a device token for APNS and registration ID for GCM By endpoint I meant JID. The Client Backend Service will need some XMPP aware component to receive notification payloads from their users' XMPP servers and convert those into their Proprietary Push Notification service format of choice. 2. I didn't see a way to make the server advertise its provider ID which is necessary at least for APNS and GCM. Maybe in the discovery reply stanza? Your XMPP server only advertises that it can relay notifications to the user's Client Backend Service. It's the CBS that has a provider ID, etc. An example: 1) An iOS client app, named Otalk. 2) The Otalk developers runs a private XMPP server (push.otalk.im) solely for receiving push notification payloads from external servers. 3) I run my own XMPP server on lance.im, which supports this XMPP Push extension. So I install Otalk on my phone, and establish a connection to my own server, lance.im. The Otalk client detects that lance.im supports the push extension via disco/caps. The Otalk client then registers the 'push.otalk.im' endpoint (which the Otalk client knows about because it's hardcoded) as a recipient for push notifications for la...@lance.im on lance.im. Included in that registration MAY be some ID value that the Otalk client provides, which is completely opaque and only intended for use by 'push.otalk.im' as the registered endpoint. (Eg, the Otalk client app could request an ID value from its backend server that associates 'la...@lance.im' with a device id/token before starting the registration process at lance.im.) I then go offline or do something which causes my server, lance.im, to trigger a push notification. It then sends the notification payload (whatever we end up defining for that) to the relevant push endpoints that have been registered for la...@lance.im. In this case, push.otalk.im. The notification is then received by push.otalk.im, and the push.otalk.im server then converts that information into an iOS Push Notification, which requires the use of private key material issued to the Otalk developers to sign the iOS push request. My phone then receives the iOS push notification, which displays a message that 'Otalk' has done something, and maybe updates the Otalk app badge. Fin. My server, lance.im, never needs to know anything about iOS or GCM or anything specific to my phone. It has no 'provider ID'; my server never talks to Apple, Google, etc. What it does have is essentially a special PubSub/PEP node that has user approved subscribers and is only published to by the server under certain conditions and possibly only to certain subscribers at a time. It's up to the installed app to communicate with its own backend services to share device IDs and tokens, and it's up to the app's backend service to forward that notification over its preferred proprietary push service to the installed app on some device. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Push notification XEP
Hi everyone, Another different PUSH service to take into account just to illustrate how much some PUSH services differ from others: the upcoming Javascript Push API (W3C Working Draft [1]). In this WebAPI there is no such thing as device tokens or registration IDs, nor API keys or sender IDs. You just ask the PUSH server for a new endpoint with PushManager.register(); and it returns an URI like this: https://as.push.tefdigital.com/v1/notify/abcdef01234567890abcdefabcdef01234567890abcdef Then you need to pass the endpoint to the server and every time you perform a HTTP PUSH with incremental attribute version, your webapp receives a push event. [1] https://dvcs.w3.org/hg/push/raw-file/default/index.html Regards, -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
Re: [Standards] Push notification XEP
My server, lance.im, never needs to know anything about iOS or GCM or anything specific to my phone. It has no 'provider ID'; my server never talks to Apple, Google, etc. Very smart solution, otherwise we would have to support an endless list of PUSH services (Apple, Google, RIM, etc.) Lance, I've read your XEP draft and sounds to me like a very good point to start from. My doubt is: what kind of information may the payload carry given that it's generated by the user's server? Any use case for that? Thanks. Regards, -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
Re: [Standards] Push notification XEP
My doubt is: what kind of information may the payload carry given that it's generated by the user's server? Any use case for that? Thanks. Right, this is why it has so far been desirable to just proxy the connection, so the app service has complete control over what it can know. These are the use cases I'd want to have covered at minimum: 1) Notification of offline messages, with the message bodies. 2) Notification that messages have been received while offline, possibly with a count of the unread messages. No message bodies or senders. This case is one that we've had to explore for dealing with services that must conform to governmental privacy regulations (e.g. medical) to prevent leaking protected data to external push services or across borders (e.g. a UK provider using push services based in the US). 3) Presence subscription requests, with requester. 4) Number of pending presence subscription requests (same situation as #2). One more that I'm not quite sure how we'd cover yet, but will become important soon: 5) Jingle call request/answered notification. As far as I can tell, those should be sufficient for general chat applications. More special purpose apps may require things like pub sub notifications, etc. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
