> 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
