← Back to team overview

ubuntu-push-devs team mailing list archive

Re: status?

 

Brief comments on the issues:

On Tue, Sep 10, 2013 at 1:59 PM, Robert Park <robert.park@xxxxxxxxxxxxx>wrote:

> * All of our components are communicating with DBus. I am vaguely aware
> that DBus can be used over the network but I have no idea how well it works
> or what challenges I might face there.
>
>
You dont do dbus over the network, the app gets called by dbus from our
local push daemon when there is a message.

* Everything we do depends heavily on Ubuntu Online Accounts in order to
> authenticate with the user's social networks and download the messages we
> poll for. How will I go about sending the user's social network OAuth
> tokens to a server process running in canonical's/operator's cloud, and
> what are the security/privacy implications of this? The community screamed
> bloody murder about our central server for dash queries, just wait until
> they hear that we're gonna be harvesting their social network credentials.
>
>
Yes, this is an intrinsic problem with polling and the phone. If we move
polling outside we need to move the credentials (and have one massive
polling service). If we want to keep polling in the device, we need to
solve a different problem. And i am not sure its going to fly with network
operators.


* If we end up using an interchange format such as JSON for transmitting
> social network messages from our server to the phone, then the phone needs
> to retain all the JSON-parsing code that I've already written, and it seems
> like a massive duplication of effort. Eg, social network sends JSON to
> canonical/operator server, which gets parsed and interpreted and marshalled
> into a standard format, and then converted back to JSON, and pushed to the
> client, which interprets the JSON again. Adds an extra hop in the
> transmission of the data.
>

 We expect to get json messages that we push to the device as json
messages. It is an extra hop.


> * Authentication! how the heck is the server gonna know which messages go
> to which people! So I'm gonna have to create a whole new authentication
> layer myself? And we expect every app author to reinvent this themselves?
> Or will you be providing an SDK for authenticating clients to the push
> server in a reliable and secure way?
>

Our current proposal for this goes like this:
The phone app creates a channel against our push service. It gets a token.
It then sends that token and the other credentials it has to the friends
push service. When the friends push service has a new message for the
client it will use the token to send a notification to the device. (https
post against our push service with the token and the json payload)

This is a good example of why the "registering a client with the developer
service" is best served by and out-of-band communication not mediated by
the push service.

Regards,

Lucio.

Follow ups

References