[aerogear-dev] Firefox OS App Day

Tue Jun 4 13:18:11 EDT 2013

>You may want to note that in the ReadMe in case some folks start running this and wonder why their apps need to reregister frequently.
Ah good point! I've updated the ReadMe files for the Netty and vert.x version. Thanks!

And thanks for the information about your server implementation, very interesting stuff, we'll definitely look more closely at your implementation and the suggestions you have brought forward. Our server side started out as a simple POC but moving forward we'd like to make it as performant as possible of course. 

----- Original Message -----
From: "JR Conlin" <jrconlin at mozilla.com>
To: "Kris Borchers" <kris at redhat.com>
Cc: "Erik Jan de Wit" <edewit at redhat.com>, "JR Conlin" <jrconlin+moz at gmail.com>, "Daniel Bevenius" <dbeveniu at redhat.com>, "Matthias Wessendorf" <matzew at redhat.com>, "Nikhil Marathe" <nmarathe at mozilla.com>, "Ryan Tilder" <rtilder at mozilla.com>, push-notifications at mozilla.org, "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
Sent: Tuesday, June 4, 2013 6:37:00 PM
Subject: Re: Firefox OS App Day

I'll let Nikhil remark on the client side stuff, since that's his area 
of expertise.

Looking at the server, I see that you do storage in memory. You may want 
to note that in the ReadMe in case some folks start running this and 
wonder why their apps need to reregister frequently.

One other thing I forgot to mention was that my server also discards the 
sent version data. There are a few reasons to do this (one being that it 
not only reduces potential security issues, but also reduces the data 
storage requirement). Instead, I simply use UTC for the version. It does 
mean that there's a risk that an accidentally malicious server could 
"flood" their channel with update requests, but there are ways to deal 
with that and it's kind of a corner case.

Obviously, we'd love more input if you have different opinions about that.

On 2013/6/4 9:19 AM, Kris Borchers wrote:
> Great to hear that you guys are interested in collaborating a bit with 
> us! We are really excited about what we have so far and where we want 
> to go with this to hopefully help bring SimplePush to the browser. I 
> have added our developer mailing list to the CC.
>
> Another repo we wouldn't mind you taking a peek at is the client side 
> polyfill stuff I have been working on here 
> https://github.com/aerogear/aerogear-js/blob/Notifier/src/simple-push/aerogear.simplepush.js and 
> the bit that does most of the work is here 
> https://github.com/aerogear/aerogear-js/blob/Notifier/src/notifier/adapters/simplePush.js. 
> It currently lives on a branch for the new Notifier bits I am adding 
> to AeroGear.js for some API unification for different messaging 
> protocols. Basically what we are doing is using websockets (or a 
> fallback) via SockJS and storing some channel info in localStorage for 
> re-registration, etc.
>
> Any and all feedback would be appreciated. Even if it's "You're crazy! 
> Don't do that! Do this!" :)
>
> Thanks and also excited to be able to work with you on this as well!
>
> On Jun 4, 2013, at 10:30 AM, JR Conlin <jrconlin at mozilla.com 
> <mailto:jrconlin at mozilla.com>> wrote:
>
>> We have push-notifications at mozilla.org 
>> <mailto:push-notifications at mozilla.org>, however that list is not 
>> widely used. I wouldn't mind adding it as a CC to the discussion, 
>> however.
>>
>> I'm fine using your public mail list, if you don't mind me pointing 
>> to it from our wiki pages or summarizing discussion points there.
>>
>> Neat, you're implementing a netty version. I'll have to dig into it 
>> and see how you're building that out.
>>
>> I should also probably mention that to get things up to large scale, 
>> the go version I built does a few things different than the strict 
>> spec says. <https://github.com/jrconlin/pushgo>
>>
>> 1. The server doesn't really care that much about valid channelIDs.
>> As you know, when you start to have to deal with very large numbers 
>> of connections, you really want to reduce your data storage 
>> dependencies. Since SimplePush is a "best effort" system (we're not 
>> guaranteeing delivery of messages in all cases since that's 
>> prohibitively expensive), we merely collect channelIDs for a given 
>> UAID and report them to the client on flush. This allows us to not 
>> have to do a data fetch, since the client will discard any unknown 
>> channelID, passing those values to the client does not cause user 
>> facing issues. I can prevent random "griefing" from malicious users 
>> by using a simple AES hash on the endpoint. If the hash fails to 
>> decrypt, I don't even bother trying to store anything.
>>
>> I also don't report back failures to PUT requests. The less 
>> information that I give malicious parties, the better, and legit 
>> parties will always get the same result.
>>
>> 2. I take advantage of memcache's self expiring records to auto-prune 
>> entries. Legit notifications live for 3 days. This is based on the 
>> idea that notifications tend to be fairly ephemeral and you probably 
>> don't really care if an accident slowed down your commute home last 
>> Thursday.
>>
>> We're excited that you want to contribute and look forward to working 
>> with you.
>>
>> On 2013/6/4 5:20 AM, Erik Jan de Wit wrote:
>>> Forgot to add these guys
>>>
>>> Cheers,
>>> Erik Jan
>>>
>>> Begin forwarded message:
>>>
>>>> *From: *Erik Jan de Wit <erikjan.dewit at gmail.com 
>>>> <mailto:erikjan.dewit at gmail.com>
>>>> <mailto:erikjan.dewit at gmail.com>>
>>>> *Subject: **Re: Firefox OS App Day*
>>>> *Date: *June 4, 2013 8:48:26 AM GMT+02:00
>>>> *To: *jr conlin <jrconlin at gmail.com <mailto:jrconlin at gmail.com> 
>>>> <mailto:jrconlin at gmail.com>>
>>>> *Cc: *Nikhil Marathe <nmarathe at mozilla.com 
>>>> <mailto:nmarathe at mozilla.com>
>>>> <mailto:nmarathe at mozilla.com>>, JR Conlin <jrconlin+moz at gmail.com 
>>>> <mailto:jrconlin+moz at gmail.com>
>>>> <mailto:jrconlin+moz at gmail.com>>
>>>>
>>>> Hi,
>>>>
>>>> Great to hear from you, we are building something based on the specs
>>>> that you wrote. The idea is that this will serve as a polyfill we have
>>>> a server as well
>>>> https://github.com/danbev/aerogear-simplepush-server To be able to
>>>> stay in sync with what you are doing we need have some additional
>>>> questions is it ok for you to have a discussion on our public mailing
>>>> list?
>>>>
>>>> Cheers,
>>>> Erik Jan
>>>>
>>>> On Jun 2, 2013, at 8:46 PM, jr conlin <jrconlin at gmail.com 
>>>> <mailto:jrconlin at gmail.com>
>>>> <mailto:jrconlin at gmail.com>> wrote:
>>>>
>>>>> Hi Erik Jan,
>>>>>
>>>>> Yes, we're the folks you probably want to talk to. Nikhil works on
>>>>> the Client portion (the elements that run on the device or browser),
>>>>> and I work on the Server portion.
>>>>>
>>>>> We'd love to hear your questions, since we've been fairly deep into
>>>>> this for a while and it's always good to have folks point out the
>>>>> confusing bits.
>>>>>
>>>>> I can tell you that a bunch of the more confusing elements might go
>>>>> away if we note that SimplePush isn't supposed to be 100% guaranteed
>>>>> delivery, but "Best Effort". Doing 100% guaranteed is very expensive
>>>>> from a hardware and software point of view and costs tend to
>>>>> seriously escalate once you get past a few hundred users. Instead,
>>>>> the system tries it's best to send a dataless "ping" to the device,
>>>>> in many cases, leaving how the ping actually gets to the device as a
>>>>> responsibility of the system that is closest to the device.
>>>>>
>>>>> Think about how email is sent around. Just because you hit "send"
>>>>> doesn't mean that the email has appeared at the destination. Often
>>>>> it's handed around to multiple systems before finally making it to
>>>>> the location.
>>>>>
>>>>> In that scenario, "errors" become a bit harder to nail down. There
>>>>> are definite errors when a device can't talk to it's immediate
>>>>> server, and we try to handle those appropriately. There are also
>>>>> potential errors that may happen if an end point tries to ping a
>>>>> device that doesn't exist. Where things get fuzzy are the errors
>>>>> around a device that just got run over by a bus or sat in a drawer
>>>>> with a dead battery for a week.
>>>>>
>>>>> In any case, feel free to contact us via email or if you like on
>>>>> irc.mozilla.org/#push <http://irc.mozilla.org/#push> 
>>>>> <http://irc.mozilla.org/#push>
>>>>>
>>>>> On 6/2/2013 10:10 AM, Henrik 'henx' Mitsch wrote:
>>>>>> Hi Nikhil and JR,
>>>>>>
>>>>>> looking at https://wiki.mozilla.org/WebAPI/SimplePush you seem to be
>>>>>> the main editors. Last weekend we had a Firefox OS App Day in
>>>>>> Switzerland. It was awesome!
>>>>>>
>>>>>> Erik Jan was one of the participants. He has a question concerning
>>>>>> Simple Push (see below). Can you guys help him out?
>>>>>>
>>>>>> Best regards,
>>>>>>  Henrik
>>>>>>  Mozilla Rep
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 28.05.13 09:59, Erik Jan de Wit wrote:
>>>>>>> Hi Henrik,
>>>>>>>
>>>>>>> I was talking with my colleges about the nice day we had saturday.
>>>>>>> And I mentioned that you could bring us in contact with people that
>>>>>>> build the Simple Push into Mozilla. Like I've explained before we
>>>>>>> made an implementation as well based off the specs that are on the
>>>>>>> MDN, but would be nice if we could sync with the one that was
>>>>>>> developed for Mozilla OS as the specs have some holes. For instance
>>>>>>> how to handle errors is not really clear. Could you bring us in
>>>>>>> contact with the people that implemented this in Firefox?
>>>>>>>
>>>>>>> Thanks, Erik Jan
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>