[aerogear-dev] Beyond SimplePush's simplicity

Bruno Oliveira bruno at abstractj.org
Wed Oct 29 11:54:32 EDT 2014


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 at redhat.com>
> wrote:
>
> >
> > On Oct 20, 2014, at 9:44 AM, Lukáš Fryč <lukas.fryc at 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 at 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 at 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 at 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 at 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 at 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 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
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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


--

abstractj
PGP: 0x84DC9914


More information about the aerogear-dev mailing list