ubuntu-push-devs team mailing list archive

[John Lenton <john.lenton@xxxxxxxxxxxxx>]

On Tue, Sep 10, 2013 at 6:17 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx> wrote:
>
> Can you clarify the specific use-cases you are trying to
> solve/referring to here? As I understand it, friends will only
> eventually migrate to the push-notification service and we are good
> with what we have right now. Admittedly, polling on a socket is not
> what we should or want to do, but we are not limited by implications
> of the app lifecycle for friends.

depends what you mean with "we are good". We don't need Friends
migrated by v0; we definitely need Friends either migrated or off the
phone before operators will touch it.

> Let's assume the best case and we have native apps for facebook,
> twitter, your-favorite-social network apps. How would friends fit in
> with this configuration/scenario?

that's one I'd love to know. My take is that Friends has value in and
of itself, and a lot of people (even on other phones, or the web)
would love to have it.

>> * 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?
>>
>
> This obviously needs to be part of the SDK and the push-service needs
> to provide a consistent way for authentication and encryption.
> I think it's important to consider the per-app use-case here. friends
> is a somewhat special case from my POV. (John, please correct me if
> I'm wrong).

no, it doesn't "obviously need to be part of the SDK", because
authentication (in the sense Robert used, which is actually identity
and not authentication) is not a client-side problem at all (more
below).

In fact, Robert's question itself makes me wonder whether we're not
being clear enough as to what needs to be done on the appdev server
side. Talking with Lucio yesterday, I'm adding "write a sample appdev
server" as one of the tasks we need to do for this. The appdev needs
to write a backend web application that handles multiple users, and
this has nothing to do with the SDK. You're providing a multi-user
network-connected application, your backend needs to be multi-user.
That's a no brainer. The SDK has nothing to do with it at all.

anyway, back to Thomas's question: the push service will have the
concept of users and devices (a many-to-many relation, even). When an
app dev server has a notification for a given user it will use the
app-provided user-specific token (and, later, maybe, an optional
specification of devices to deliver to: e.g., user Foo, on devices A,
B, C, or that have purple registers, or that the user is using right
now) to the push notifications server, along with the notification it
needs delivering (that notification will in some cases be the message
itself, in other cases it will be "come get messages").