> 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 (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. Given the above, this does need standardizing on a per-app basis. But that standardization should be done as part of the documentation of the app. > 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'> > <value>http://jabber.org/protocol/pubsub#publish-options</value> > </field> > <field var='include-bodies'><value>0<value></field> > <field var='include-senders'><value>0<value></field> > <field var='include-message-count'><value>1<value></field> > </x> > </enable> > </iq> Perhaps a second form for that sort of configuration? I would like to keep it so that the XMPP server can just attach the publish-options form to publishes without having to understand the semantics of the fields. Thanks for the feedback! - Lance
smime.p7s
Description: S/MIME cryptographic signature
