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 <[email protected]> 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
