[aerogear-dev] Firefox Push API with UnifiedPush Server

[Idel Pivnitskiy]

I've sent a separate PR with renamed Firefox Variant to Webpush Variant
[1]. Will try to make it workable with Google Chrome and FCM too tomorrow.

[1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/745

Best regards,
Idel Pivnitskiy
--
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>

On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <idel.pivnitskiy at gmail.com>
wrote:

> It's a bit early to talk about Safari, because it has not implemented Push
> API, Service Worker API and push message encryption yet. And no information
> about their plans to do this. Currently Apple uses their own protocol for
> push notifications. I've asked my friend to register a test app from his
> Apple developer's account for me, and I'm going to test how it will work
> now, with APNs Variant.
>
> Here is info, that Microsoft started development of Push API for Edge [1].
>
> I decided to create a variant for Firefox just because variant saves
> authentication tokens for push service provider and later uses it's own
> notification sender for a specific push service provider. And I started to
> work on this, when here was no info that Chrome supports PushMessageData
> and push message encryption. But now it may be reasonable to create a
> WebPush variant. Or wait Push API in Edge and decide how to move forward
> after the third player in the game.
>
> If we will create WebPush variant the advantages are:
>
>    1. User have to create just one variant
>    2. Unique extended Installation entity with "auth secret" and "public
>    key" from the browser.
>
> but disadvantages are:
>
>    1. Required registration on each push notification provider: FCM, MPS,
>    etc. (but advantage that the user will not forgot something)
>    2. Determine browser on client side, store it in Installation during
>    registration of device and make decision which push notification provider
>    should be chosen before sending each message.
>
> If we will create variant for each push notification provider the
> advantages are:
>
>    1. Keep our rule, that each variant has it's own push message provider
>    and auth information.
>
> but disadvantages are:
>
>    1. Determine browser on client side and choose appropriate variant
>    secret.
>    2. For FCM make decision about should we encrypt the message before
>    sent (if the client is Chrome) or not.
>
> Also here is a chance, that FCM, MPS and others will implement totally
> identical push services, according to the specification [2], with
> acknowledgment, receipts, HTTP/2, etc. So it may be reasonable to focus on
> one WebPush variant. It will not be a problem for me to rename Firefox to
> WebPush now. I can open a separate PR this evening.
>
> Any thoughts?
>
> [1]
> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/pushapi
> [2] https://tools.ietf.org/html/draft-ietf-webpush-protocol
>
> Best regards,
> Idel Pivnitskiy
> --
> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>
> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <lholmqui at redhat.com>
> wrote:
>
>> I'm tempted to say that there should be a "WebPush" variant instead which
>> could be chrome/ff/safari, but i think chrome and safari are to closely
>> related to Android/iOS atm that it wouldn't make sense.
>>
>> Somewhat related to this is the JS SDK for the ups and how it works for
>> push on the web.  It was initially created to just handle registering
>> SimplePush clients, since there was no browsers doing push.  Then Safari
>> introduced push, then chrome and FF.   with regards to the UPS, these are 3
>> different variants,  so to create 1 app that handles all three you would
>> need to make sure to register 3 "clients" in the js sdk.  I don't know if
>> there is anyway we can help the user out with this. Safari is different
>> enough that it would be easy for the user, but there is no real difference
>> between the registration code in FF and chrome.(perhaps these 2 should be
>> the "WebPush" variant) so a user agent parse would probably need to
>> happen.  i'm not really a big fan of including that in the library,  but
>> maybe we should have an example that shows push for FF and chrome in the
>> same example.
>>
>>
>>
>> On Sun, Jul 24, 2016 at 9:05 PM, Idel Pivnitskiy <
>> idel.pivnitskiy at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I've added a Firefox Variant to support Push API in Mozilla Firefox for
>>> UPS [1]. It works well with my previous example for Chrome [2]. I also
>>> created a new PR to adapt comments in this example and notice that Firefox
>>> also supported [3].
>>>
>>> Current implementation of Firefox Variant does not support
>>> PushMessageData [4]. Looks like it will require significant changes of UPS.
>>> I will initiate a separate thread for this discussion.
>>>
>>> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/744
>>> [2] https://github.com/aerogear/aerogear-js-cookbook/pull/13
>>> [3] https://github.com/aerogear/aerogear-js-cookbook/pull/14
>>> [4] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData
>>>
>>> Best regards,
>>> Idel Pivnitskiy
>>> --
>>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160726/1e04ff35/attachment-0001.html