1:58 p.m.
Hey guys,
I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as
Firefox OS using our Cordova plugin.
But as you know, with FFOS it is not that simple - since SimplePush
protocol allows to transfer just incremental versions, we are not able to
deliver any interesting message.
UnifiedPush Server could be a correct place where we unify and shield our
users from this limitation:
my idea is storing the message on UPS under the SimplePush endpoint URL.
Once the message with version reaches the client, he would contact UPS to
retrieve this message under a key ( pushEndpoint, version ).
The messages could have default built-in TTL to allow periodic cleanup.
What do you think?
Cheers,
~ Lukas
2:06 p.m.
not sure. but perhaps worth to look into this for 1.1x
Oh, aren't the new SimplePush specs (or was it WebPush) defining richer
payloads, like we know from Android or iOS?
On Monday, October 20, 2014, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
Hey guys,
I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as
Firefox OS using our Cordova plugin.
But as you know, with FFOS it is not that simple - since SimplePush
protocol allows to transfer just incremental versions, we are not able to
deliver any interesting message.
UnifiedPush Server could be a correct place where we unify and shield our
users from this limitation:
my idea is storing the message on UPS under the SimplePush endpoint URL.
Once the message with version reaches the client, he would contact UPS to
retrieve this message under a key ( pushEndpoint, version ).
The messages could have default built-in TTL to allow periodic cleanup.
What do you think?
Cheers,
~ Lukas
--
Sent from Gmail Mobile
2:07 p.m.
Hi Lukáš,
I like that idea, because in the end our goal is to unify. And I think that the simple
push protocol will be changed in the future to allow for ‘normal’ message sending. So we
could fallback afterwards.
Cheers,
Erik Jan
On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
Hey guys,
I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as Firefox OS
using our Cordova plugin.
But as you know, with FFOS it is not that simple - since SimplePush protocol allows to
transfer just incremental versions, we are not able to deliver any interesting message.
UnifiedPush Server could be a correct place where we unify and shield our users from this
limitation:
my idea is storing the message on UPS under the SimplePush endpoint URL. Once the message
with version reaches the client, he would contact UPS to retrieve this message under a key
( pushEndpoint, version ).
The messages could have default built-in TTL to allow periodic cleanup.
What do you think?
Cheers,
~ Lukas
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:51 p.m.
Awesome, great to hear that SimplePush will get a native support for a full
message content.
As Erik said, in the meantime, we could unify this behavior.
I have created the associated issue:
https://issues.jboss.org/browse/AGPUSH-1073
On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi Lukáš,
I like that idea, because in the end our goal is to unify. And I think
that the simple push protocol will be changed in the future to allow
for ‘normal’ message sending. So we could fallback afterwards.
Cheers,
Erik Jan
On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
Hey guys,
I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as
Firefox OS using our Cordova plugin.
But as you know, with FFOS it is not that simple - since SimplePush
protocol allows to transfer just incremental versions, we are not able to
deliver any interesting message.
UnifiedPush Server could be a correct place where we unify and shield our
users from this limitation:
my idea is storing the message on UPS under the SimplePush endpoint URL.
Once the message with version reaches the client, he would contact UPS to
retrieve this message under a key ( pushEndpoint, version ).
The messages could have default built-in TTL to allow periodic cleanup.
What do you think?
Cheers,
~ Lukas
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:59 p.m.
I'm just worried about storing the message, for stuff like privacy, for
instance. Let's make a really short TTL or better let's delete the mesage
right after it has been retrieved.
On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
Awesome, great to hear that SimplePush will get a native support for
a
full message content.
As Erik said, in the meantime, we could unify this behavior.
I have created the associated issue:
https://issues.jboss.org/browse/AGPUSH-1073
On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
wrote:
> Hi Lukáš,
>
> I like that idea, because in the end our goal is to unify. And I think
> that the simple push protocol will be changed in the future to allow
> for ‘normal’ message sending. So we could fallback afterwards.
>
> Cheers,
> Erik Jan
>
> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>
> Hey guys,
>
> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as
> Firefox OS using our Cordova plugin.
>
> But as you know, with FFOS it is not that simple - since SimplePush
> protocol allows to transfer just incremental versions, we are not able to
> deliver any interesting message.
>
> UnifiedPush Server could be a correct place where we unify and shield our
> users from this limitation:
>
>
> my idea is storing the message on UPS under the SimplePush endpoint URL.
> Once the message with version reaches the client, he would contact UPS to
> retrieve this message under a key ( pushEndpoint, version ).
>
> The messages could have default built-in TTL to allow periodic cleanup.
>
> What do you think?
>
>
> Cheers,
>
> ~ Lukas
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:08 p.m.
Removing after retrieval was the idea, I ve noted that in the JIRA.
I believe that push messages themselves are not really secure, since you
hand over each message to third-party without encryption.
If we leave push message encryption up to app developer, then SimplePush is
no different, or is it?
On Mon, Oct 20, 2014 at 2:59 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
I'm just worried about storing the message, for stuff like
privacy, for
instance. Let's make a really short TTL or better let's delete the mesage
right after it has been retrieved.
On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
> Awesome, great to hear that SimplePush will get a native support for a
> full message content.
>
> As Erik said, in the meantime, we could unify this behavior.
> I have created the associated issue:
> https://issues.jboss.org/browse/AGPUSH-1073
>
>
> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
> wrote:
>
>> Hi Lukáš,
>>
>> I like that idea, because in the end our goal is to unify. And I think
>> that the simple push protocol will be changed in the future to allow
>> for ‘normal’ message sending. So we could fallback afterwards.
>>
>> Cheers,
>> Erik Jan
>>
>> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>>
>> Hey guys,
>>
>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
>> as Firefox OS using our Cordova plugin.
>>
>> But as you know, with FFOS it is not that simple - since SimplePush
>> protocol allows to transfer just incremental versions, we are not able to
>> deliver any interesting message.
>>
>> UnifiedPush Server could be a correct place where we unify and shield
>> our users from this limitation:
>>
>>
>> my idea is storing the message on UPS under the SimplePush endpoint URL.
>> Once the message with version reaches the client, he would contact UPS to
>> retrieve this message under a key ( pushEndpoint, version ).
>>
>> The messages could have default built-in TTL to allow periodic cleanup.
>>
>> What do you think?
>>
>>
>> Cheers,
>>
>> ~ Lukas
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:55 p.m.
On 2014-10-20, Lukáš Fryč wrote:
Removing after retrieval was the idea, I ve noted that in the JIRA.
I believe that push messages themselves are not really secure, since you
hand over each message to third-party without encryption.
If we leave push message encryption up to app developer, then SimplePush is
no different, or is it?
If you leave message encryption up to app developer, they won't do it.
And I'm very serious here.
On Mon, Oct 20, 2014 at 2:59 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> I'm just worried about storing the message, for stuff like privacy, for
> instance. Let's make a really short TTL or better let's delete the mesage
> right after it has been retrieved.
>
>
> On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>
>> Awesome, great to hear that SimplePush will get a native support for a
>> full message content.
>>
>> As Erik said, in the meantime, we could unify this behavior.
>> I have created the associated issue:
>> https://issues.jboss.org/browse/AGPUSH-1073
>>
>>
>> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
>> wrote:
>>
>>> Hi Lukáš,
>>>
>>> I like that idea, because in the end our goal is to unify. And I think
>>> that the simple push protocol will be changed in the future to allow
>>> for ‘normal’ message sending. So we could fallback afterwards.
>>>
>>> Cheers,
>>> Erik Jan
>>>
>>> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>>>
>>> Hey guys,
>>>
>>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
>>> as Firefox OS using our Cordova plugin.
>>>
>>> But as you know, with FFOS it is not that simple - since SimplePush
>>> protocol allows to transfer just incremental versions, we are not able to
>>> deliver any interesting message.
>>>
>>> UnifiedPush Server could be a correct place where we unify and shield
>>> our users from this limitation:
>>>
>>>
>>> my idea is storing the message on UPS under the SimplePush endpoint URL.
>>> Once the message with version reaches the client, he would contact UPS to
>>> retrieve this message under a key ( pushEndpoint, version ).
>>>
>>> The messages could have default built-in TTL to allow periodic cleanup.
>>>
>>> What do you think?
>>>
>>>
>>> Cheers,
>>>
>>> ~ Lukas
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
3:25 p.m.
I vote no for this.
I think storing messages, for any period of time is bad.
I think SimplePush should stay “Simple” and we should follow the spec on this.
On Oct 20, 2014, at 8:59 AM, Sebastien Blanc
<scm.blanc(a)gmail.com> wrote:
I'm just worried about storing the message, for stuff like privacy, for instance.
Let's make a really short TTL or better let's delete the mesage right after it has
been retrieved.
On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com
<mailto:lukas.fryc@gmail.com>> wrote:
Awesome, great to hear that SimplePush will get a native support for a full message
content.
As Erik said, in the meantime, we could unify this behavior.
I have created the associated issue: https://issues.jboss.org/browse/AGPUSH-1073
<https://issues.jboss.org/browse/AGPUSH-1073>
On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com
<mailto:edewit@redhat.com>> wrote:
Hi Lukáš,
I like that idea, because in the end our goal is to unify. And I think that the simple
push protocol will be changed in the future to allow for ‘normal’ message sending. So we
could fallback afterwards.
Cheers,
Erik Jan
On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com
<mailto:lukas.fryc@gmail.com>> wrote:
> Hey guys,
>
> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as Firefox
OS using our Cordova plugin.
>
> But as you know, with FFOS it is not that simple - since SimplePush protocol allows
to transfer just incremental versions, we are not able to deliver any interesting
message.
>
> UnifiedPush Server could be a correct place where we unify and shield our users from
this limitation:
>
>
> my idea is storing the message on UPS under the SimplePush endpoint URL. Once the
message with version reaches the client, he would contact UPS to retrieve this message
under a key ( pushEndpoint, version ).
>
> The messages could have default built-in TTL to allow periodic cleanup.
>
> What do you think?
>
>
> Cheers,
>
> ~ Lukas
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:43 p.m.
Oh, aren't the new SimplePush specs (or was it WebPush) defining
richer
payloads, like we know from Android or iOS?
That is for WebPush, I'm not aware of any message payload (besides a
version/timestamp) for SimplePush.
On 20 October 2014 15:25, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
I vote no for this.
I think storing messages, for any period of time is bad.
I think SimplePush should stay “Simple” and we should follow the spec on
this.
On Oct 20, 2014, at 8:59 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
I'm just worried about storing the message, for stuff like privacy, for
instance. Let's make a really short TTL or better let's delete the mesage
right after it has been retrieved.
On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
> Awesome, great to hear that SimplePush will get a native support for a
> full message content.
>
> As Erik said, in the meantime, we could unify this behavior.
> I have created the associated issue:
> https://issues.jboss.org/browse/AGPUSH-1073
>
>
> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
> wrote:
>
>> Hi Lukáš,
>>
>> I like that idea, because in the end our goal is to unify. And I think
>> that the simple push protocol will be changed in the future to allow
>> for ‘normal’ message sending. So we could fallback afterwards.
>>
>> Cheers,
>> Erik Jan
>>
>> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>>
>> Hey guys,
>>
>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
>> as Firefox OS using our Cordova plugin.
>>
>> But as you know, with FFOS it is not that simple - since SimplePush
>> protocol allows to transfer just incremental versions, we are not able to
>> deliver any interesting message.
>>
>> UnifiedPush Server could be a correct place where we unify and shield
>> our users from this limitation:
>>
>>
>> my idea is storing the message on UPS under the SimplePush endpoint URL.
>> Once the message with version reaches the client, he would contact UPS to
>> retrieve this message under a key ( pushEndpoint, version ).
>>
>> The messages could have default built-in TTL to allow periodic cleanup.
>>
>> What do you think?
>>
>>
>> Cheers,
>>
>> ~ Lukas
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:44 p.m.
Clarification: this was meant as UnifiedPushClient extension, rather then
SimplePush's one (bad wording)
On Mon, Oct 20, 2014 at 3:25 PM, Lucas Holmquist <lholmqui(a)redhat.com>
wrote:
I vote no for this.
I think storing messages, for any period of time is bad.
I think SimplePush should stay “Simple” and we should follow the spec on
this.
On Oct 20, 2014, at 8:59 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
I'm just worried about storing the message, for stuff like privacy, for
instance. Let's make a really short TTL or better let's delete the mesage
right after it has been retrieved.
On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
> Awesome, great to hear that SimplePush will get a native support for a
> full message content.
>
> As Erik said, in the meantime, we could unify this behavior.
> I have created the associated issue:
> https://issues.jboss.org/browse/AGPUSH-1073
>
>
> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
> wrote:
>
>> Hi Lukáš,
>>
>> I like that idea, because in the end our goal is to unify. And I think
>> that the simple push protocol will be changed in the future to allow
>> for ‘normal’ message sending. So we could fallback afterwards.
>>
>> Cheers,
>> Erik Jan
>>
>> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>>
>> Hey guys,
>>
>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
>> as Firefox OS using our Cordova plugin.
>>
>> But as you know, with FFOS it is not that simple - since SimplePush
>> protocol allows to transfer just incremental versions, we are not able to
>> deliver any interesting message.
>>
>> UnifiedPush Server could be a correct place where we unify and shield
>> our users from this limitation:
>>
>>
>> my idea is storing the message on UPS under the SimplePush endpoint URL.
>> Once the message with version reaches the client, he would contact UPS to
>> retrieve this message under a key ( pushEndpoint, version ).
>>
>> The messages could have default built-in TTL to allow periodic cleanup.
>>
>> What do you think?
>>
>>
>> Cheers,
>>
>> ~ Lukas
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:46 p.m.
On Oct 20, 2014, at 9:44 AM, Lukáš Fryč <lukas.fryc(a)gmail.com>
wrote:
Clarification: this was meant as UnifiedPushClient extension, rather then
SimplePush's one (bad wording)
i think i might still be a no, because of storing messages
On Mon, Oct 20, 2014 at 3:25 PM, Lucas Holmquist <lholmqui(a)redhat.com
<mailto:lholmqui@redhat.com>> wrote:
I vote no for this.
I think storing messages, for any period of time is bad.
I think SimplePush should stay “Simple” and we should follow the spec on this.
> On Oct 20, 2014, at 8:59 AM, Sebastien Blanc <scm.blanc(a)gmail.com
<mailto:scm.blanc@gmail.com>> wrote:
>
> I'm just worried about storing the message, for stuff like privacy, for instance.
Let's make a really short TTL or better let's delete the mesage right after it has
been retrieved.
>
>
> On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com
<mailto:lukas.fryc@gmail.com>> wrote:
> Awesome, great to hear that SimplePush will get a native support for a full message
content.
>
> As Erik said, in the meantime, we could unify this behavior.
> I have created the associated issue: https://issues.jboss.org/browse/AGPUSH-1073
<https://issues.jboss.org/browse/AGPUSH-1073>
>
>
> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com
<mailto:edewit@redhat.com>> wrote:
> Hi Lukáš,
>
> I like that idea, because in the end our goal is to unify. And I think that the
simple push protocol will be changed in the future to allow for ‘normal’ message sending.
So we could fallback afterwards.
>
> Cheers,
> Erik Jan
>
> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com
<mailto:lukas.fryc@gmail.com>> wrote:
>
>> Hey guys,
>>
>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as
Firefox OS using our Cordova plugin.
>>
>> But as you know, with FFOS it is not that simple - since SimplePush protocol
allows to transfer just incremental versions, we are not able to deliver any interesting
message.
>>
>> UnifiedPush Server could be a correct place where we unify and shield our users
from this limitation:
>>
>>
>> my idea is storing the message on UPS under the SimplePush endpoint URL. Once the
message with version reaches the client, he would contact UPS to retrieve this message
under a key ( pushEndpoint, version ).
>>
>> The messages could have default built-in TTL to allow periodic cleanup.
>>
>> What do you think?
>>
>>
>> Cheers,
>>
>> ~ Lukas
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:06 p.m.
I understand the implications,
but are you worried about storing messages per se or rather fact that UPS
would need to store anything?
Storing messages is required part in case of SimplePush deployment - all
other networks can be approached as fire&forget.
While up to the point you start to use SImplePush you are free of managing
custom storage and exposing your storage endpoint to the client, at that
point you simply have to -> ouch, that hurts.
---
In case this does not get into UPS, I would suggest at least having
interceptor on UPS side that would enable extension developers to plug such
a storage (we are limited by a fact that Push Sender does not know an
endpoint URL, actually it does not have any connection to Sender at all, so
there are limited options to connect those two).
Or maybe he can even do that today with JAX-RS interceptors? :-)
On Mon, Oct 20, 2014 at 3:46 PM, Lucas Holmquist <lholmqui(a)redhat.com>
wrote:
On Oct 20, 2014, at 9:44 AM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
Clarification: this was meant as UnifiedPushClient extension, rather then
SimplePush's one (bad wording)
i think i might still be a no, because of storing messages
On Mon, Oct 20, 2014 at 3:25 PM, Lucas Holmquist <lholmqui(a)redhat.com>
wrote:
> I vote no for this.
>
> I think storing messages, for any period of time is bad.
>
> I think SimplePush should stay “Simple” and we should follow the spec on
> this.
>
> On Oct 20, 2014, at 8:59 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
> I'm just worried about storing the message, for stuff like privacy, for
> instance. Let's make a really short TTL or better let's delete the mesage
> right after it has been retrieved.
>
>
> On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>
>> Awesome, great to hear that SimplePush will get a native support for a
>> full message content.
>>
>> As Erik said, in the meantime, we could unify this behavior.
>> I have created the associated issue:
>> https://issues.jboss.org/browse/AGPUSH-1073
>>
>>
>> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
>> wrote:
>>
>>> Hi Lukáš,
>>>
>>> I like that idea, because in the end our goal is to unify. And I think
>>> that the simple push protocol will be changed in the future to allow
>>> for ‘normal’ message sending. So we could fallback afterwards.
>>>
>>> Cheers,
>>> Erik Jan
>>>
>>> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>>>
>>> Hey guys,
>>>
>>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
>>> as Firefox OS using our Cordova plugin.
>>>
>>> But as you know, with FFOS it is not that simple - since SimplePush
>>> protocol allows to transfer just incremental versions, we are not able to
>>> deliver any interesting message.
>>>
>>> UnifiedPush Server could be a correct place where we unify and shield
>>> our users from this limitation:
>>>
>>>
>>> my idea is storing the message on UPS under the SimplePush endpoint
>>> URL. Once the message with version reaches the client, he would contact UPS
>>> to retrieve this message under a key ( pushEndpoint, version ).
>>>
>>> The messages could have default built-in TTL to allow periodic cleanup.
>>>
>>> What do you think?
>>>
>>>
>>> Cheers,
>>>
>>> ~ Lukas
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:54 p.m.
I'm sorry, I'm late for this train, because was involved into other
stuff.
Like everyone already mentioned into this thread, store messages is
really bad and the major concern is about privacy. You don't want people
sneaking at your push messages.
Unless we implement a OTR model like Pond
(https://pond.imperialviolet.org/) or something like that. I'm -1.
Fire and forget can't guarantee privacy.
On 2014-10-20, Lukáš Fryč wrote:
I understand the implications,
but are you worried about storing messages per se or rather fact that UPS
would need to store anything?
Storing messages is required part in case of SimplePush deployment - all
other networks can be approached as fire&forget.
While up to the point you start to use SImplePush you are free of managing
custom storage and exposing your storage endpoint to the client, at that
point you simply have to -> ouch, that hurts.
---
In case this does not get into UPS, I would suggest at least having
interceptor on UPS side that would enable extension developers to plug such
a storage (we are limited by a fact that Push Sender does not know an
endpoint URL, actually it does not have any connection to Sender at all, so
there are limited options to connect those two).
Or maybe he can even do that today with JAX-RS interceptors? :-)
On Mon, Oct 20, 2014 at 3:46 PM, Lucas Holmquist <lholmqui(a)redhat.com>
wrote:
>
> On Oct 20, 2014, at 9:44 AM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>
> Clarification: this was meant as UnifiedPushClient extension, rather then
> SimplePush's one (bad wording)
>
>
> i think i might still be a no, because of storing messages
>
>
> On Mon, Oct 20, 2014 at 3:25 PM, Lucas Holmquist <lholmqui(a)redhat.com>
> wrote:
>
>> I vote no for this.
>>
>> I think storing messages, for any period of time is bad.
>>
>> I think SimplePush should stay “Simple” and we should follow the spec on
>> this.
>>
>> On Oct 20, 2014, at 8:59 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>>
>> I'm just worried about storing the message, for stuff like privacy, for
>> instance. Let's make a really short TTL or better let's delete the
mesage
>> right after it has been retrieved.
>>
>>
>> On Mon, Oct 20, 2014 at 2:51 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>>
>>> Awesome, great to hear that SimplePush will get a native support for a
>>> full message content.
>>>
>>> As Erik said, in the meantime, we could unify this behavior.
>>> I have created the associated issue:
>>> https://issues.jboss.org/browse/AGPUSH-1073
>>>
>>>
>>> On Mon, Oct 20, 2014 at 2:07 PM, Erik Jan de Wit <edewit(a)redhat.com>
>>> wrote:
>>>
>>>> Hi Lukáš,
>>>>
>>>> I like that idea, because in the end our goal is to unify. And I think
>>>> that the simple push protocol will be changed in the future to allow
>>>> for ‘normal’ message sending. So we could fallback afterwards.
>>>>
>>>> Cheers,
>>>> Erik Jan
>>>>
>>>> On 20 Oct,2014, at 13:58 , Lukáš Fryč <lukas.fryc(a)gmail.com>
wrote:
>>>>
>>>> Hey guys,
>>>>
>>>> I'm working on a demo of UPS pushing to iOS, Android, Windows, as
well
>>>> as Firefox OS using our Cordova plugin.
>>>>
>>>> But as you know, with FFOS it is not that simple - since SimplePush
>>>> protocol allows to transfer just incremental versions, we are not able
to
>>>> deliver any interesting message.
>>>>
>>>> UnifiedPush Server could be a correct place where we unify and shield
>>>> our users from this limitation:
>>>>
>>>>
>>>> my idea is storing the message on UPS under the SimplePush endpoint
>>>> URL. Once the message with version reaches the client, he would contact
UPS
>>>> to retrieve this message under a key ( pushEndpoint, version ).
>>>>
>>>> The messages could have default built-in TTL to allow periodic cleanup.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> ~ Lukas
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
4:03 p.m.
FYI, Officially, the predecessor for SimplePush will be WebPush,
https://datatracker.ietf.org/wg/webpush/charter/
which runs on top of HTTP2
http://http2.github.io/
Unofficially, data is kind of a pain in the patootie, but obviously
really handy to have. There are security and privacy issues a-plenty
when dealing with data storage (HIPPA & subpoenas come to mind in the
US.) Internally, we're kicking around the idea of allowing data, but not
allowing storage, (so a device would only get data if it was actively
connected. If it was offline, it would only get the version number
update when it reconnected).
I'm also interested in what y'all come up with.
On 10/20/2014 4:58 AM, Lukáš Fryč wrote:
Hey guys,
I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
as Firefox OS using our Cordova plugin.
But as you know, with FFOS it is not that simple - since SimplePush
protocol allows to transfer just incremental versions, we are not able
to deliver any interesting message.
UnifiedPush Server could be a correct place where we unify and shield
our users from this limitation:
my idea is storing the message on UPS under the SimplePush endpoint
URL. Once the message with version reaches the client, he would
contact UPS to retrieve this message under a key ( pushEndpoint,
version ).
The messages could have default built-in TTL to allow periodic cleanup.
What do you think?
Cheers,
~ Lukas
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:18 p.m.
You are right, guys, with storing the messages, we are hitting the security
implications that I didn't think about.
Right now they have to be handled by third-party providers, but in this
case, we would need to encrypt data, pass certification, etc, that is
rather a target for internal infrastructure than a cloud service.
We could probably come with an encryption model that would allow only given
SimplePush retrieve the message, involving client's private key and version
number, but question is whether that is worth the trouble and complexity.
On Mon, Oct 20, 2014 at 4:03 PM, jr conlin <jrconlin(a)gmail.com> wrote:
FYI, Officially, the predecessor for SimplePush will be WebPush,
https://datatracker.ietf.org/wg/webpush/charter/
which runs on top of HTTP2
http://http2.github.io/
Unofficially, data is kind of a pain in the patootie, but obviously
really handy to have. There are security and privacy issues a-plenty
when dealing with data storage (HIPPA & subpoenas come to mind in the
US.) Internally, we're kicking around the idea of allowing data, but not
allowing storage, (so a device would only get data if it was actively
connected. If it was offline, it would only get the version number
update when it reconnected).
I'm also interested in what y'all come up with.
On 10/20/2014 4:58 AM, Lukáš Fryč wrote:
> Hey guys,
>
> I'm working on a demo of UPS pushing to iOS, Android, Windows, as well
> as Firefox OS using our Cordova plugin.
>
> But as you know, with FFOS it is not that simple - since SimplePush
> protocol allows to transfer just incremental versions, we are not able
> to deliver any interesting message.
>
> UnifiedPush Server could be a correct place where we unify and shield
> our users from this limitation:
>
>
> my idea is storing the message on UPS under the SimplePush endpoint
> URL. Once the message with version reaches the client, he would
> contact UPS to retrieve this message under a key ( pushEndpoint,
> version ).
>
> The messages could have default built-in TTL to allow periodic cleanup.
>
> What do you think?
>
>
> Cheers,
>
> ~ Lukas
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:28 p.m.
Heh, even that can be tricky. Generally, people will get encryption
wrong. Plus, the encrypted data block will (at least ideally) be an
indecipherable bunch of random bytes. That means that the server should
not be able to read it, or confirm that the data was actually encrypted.
Sadly, this means that someone could "encrypt" with ROT13 and the server
couldn't really verify. Then there's the problem of key distribution,
which is an absolute nightmare to do properly.
The reason that we have version (and I'll be honest, I kinda fought that
for a pretty long time too) is because it's the very least amount of
meaningful data that can be exchanged between two parties via a third
without too many issues.
I'm not a lawyer, nor do I play one on TV, nor do I even pretend to
understand international law, but I can tell you that various global
government agencies can require networks to provide anything from data
dumps to "pen registry" devices (a device that records all data
exchanges), often under orders to not disclose the fact that these
devices have occurred. For some sites, that's just the cost of doing
business, but also explains why the paranoid prefer sites like SpiderOak
(which does a fantastic job making damn sure that they can't read your
data at all).
I'll also be honest, for Mozilla, not handling data is VERY cost
effective. Not dealing with data makes things scale amazingly well for
astoundingly little, so we're doubly inclined to make data "someone
else's problem".
Ultimately, though, our customers are the ones that make the decision
about whether or not Data is worth all this. They've pretty much said
that they want data. We're trying to balance that within the WebPush
protocol, and by making data optional and disposable within SimplePush.
(Again, nothing 100% there, we're still debating it internally.) It's
also possible to do secure data exchange between parties using zero
knowledge key exchanges via things like JPAKE, but customer acceptance
of that sort of thing can be difficult.
Still, more brains == better things, so if there's a brilliant, as yet
undiscovered solution out there, it's definitely worth thinking about.
On 2014/10/20 7:18 AM, Lukáš Fryč wrote:
You are right, guys, with storing the messages, we are hitting the
security implications that I didn't think about.
Right now they have to be handled by third-party providers, but in
this case, we would need to encrypt data, pass certification, etc,
that is rather a target for internal infrastructure than a cloud service.
We could probably come with an encryption model that would allow only
given SimplePush retrieve the message, involving client's private key
and version number, but question is whether that is worth the trouble
and complexity.
On Mon, Oct 20, 2014 at 4:03 PM, jr conlin <jrconlin(a)gmail.com
<mailto:jrconlin@gmail.com>> wrote:
FYI, Officially, the predecessor for SimplePush will be WebPush,
https://datatracker.ietf.org/wg/webpush/charter/
which runs on top of HTTP2
http://http2.github.io/
Unofficially, data is kind of a pain in the patootie, but obviously
really handy to have. There are security and privacy issues a-plenty
when dealing with data storage (HIPPA & subpoenas come to mind in the
US.) Internally, we're kicking around the idea of allowing data,
but not
allowing storage, (so a device would only get data if it was actively
connected. If it was offline, it would only get the version number
update when it reconnected).
I'm also interested in what y'all come up with.
On 10/20/2014 4:58 AM, Lukáš Fryč wrote:
> Hey guys,
>
> I'm working on a demo of UPS pushing to iOS, Android, Windows,
as well
> as Firefox OS using our Cordova plugin.
>
> But as you know, with FFOS it is not that simple - since SimplePush
> protocol allows to transfer just incremental versions, we are
not able
> to deliver any interesting message.
>
> UnifiedPush Server could be a correct place where we unify and
shield
> our users from this limitation:
>
>
> my idea is storing the message on UPS under the SimplePush endpoint
> URL. Once the message with version reaches the client, he would
> contact UPS to retrieve this message under a key ( pushEndpoint,
> version ).
>
> The messages could have default built-in TTL to allow periodic
cleanup.
>
> What do you think?
>
>
> Cheers,
>
> ~ Lukas
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3466
days inactive
3475
days old
15 comments
9 participants
participants (9)
-
Bruno Oliveira -
Daniel Bevenius -
Erik Jan de Wit -
JR Conlin -
jr conlin
-
Lucas Holmquist -
Lukáš Fryč -
Matthias Wessendorf -
Sebastien Blanc