Push API – W3C Working Draft

[mike-cardwell]

This should have mandatory crypto built in from the beginning so that third party push providers can be used without causing privacy/security concerns.

The browser and the web server should negotiate an encryption key, or set of encryption keys during setup, and any push messages signed and encrypted. That way, any third party push provider can't inpect the messages.

Also, pigs should learn to fly.

[andrewstuart2]

I think the whole point of the spec is third-party push servers, a la GCM.

Encryption is still totally doable, as the client can negotiate directly with the service provider and then hand off to the single-socket push provider who would only see encrypted messages. You'd need metadata readable by the push server, however, so it can deliver messages to the right client.

Push messages already exist via Server-Sent Events [1]. This would simply standardize a less resource intensive single-connection model that third parties can interact with.

[1] http://www.w3.org/TR/eventsource/

[swartkrans]

The push API is pretty awesome, the key difference between it and websockets in term of what it offers is this bit:

> A push service allows a webapp server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent

So you can send push notifications to a user even if they don't have a tab open to your website.

[smanuel]

> The push API is pretty awesome

The idea behind this is awesome (although we already have this for some platforms - e.g. https://developer.apple.com/library/mac/documentation/Networ...)

But the API looks over-engineered. e.g.

navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) {

serviceWorkerRegistration.pushRegistrationManager.register().then(...

[andrewstuart2]

>The push API is pretty awesome, the key difference between it and websockets in term of what it offers is this bit:

> > A push service allows a webapp server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent.

Actually, the difference you describe is what Server-Sent Events [1] already provide: one-way notifications vs bidirectional communication with websockets.

This spec, rather, would standardize an API for a single-connection (read: better battery life) push server that third party webapps can use in the same way Google Cloud Messenger is used by third-party application servers for android apps.

[1] http://www.w3.org/TR/eventsource/

[SynchrotronZ]

I'm... not sure I want this. It sounds pretty useful/fun form a programmers perspective.

But from an end-user perspective I fear that it will lead too various "features" hogging resources. I would assume I could block them client-side, but I'm also the family-tech and quite frankly I don't expect my grandparents to do the same.

[pan69]

Is that the bit (step 1) where they install the Service Worker? I.e. regardless of whether or not the page is open, the Service Worker is active?

[Beltiras]

It's great that there are some standardization efforts in this space but for this to be useful we would need wide coverage of clients implementing it. Stuck using websockets for the next decade I suppose ....

[millisecond]

This (and current Safari support) is what we (Roost - https://goroost.com - YCS14) are building off. Moving toward a complete web-push suite that supports all browsers on both desktop and mobile. Long road in front of us, but it's going to be an exciting world.

[paulojreis]

What I find particularly interesting in the spec is the editors list.

This has the potential to create cool and useful stuff, of course, but (IMO) it will be used mostly for advertising. Guess who's around the spec? Google and two telcos, of course.

[tokenizerrr]

I'm not sure how this would be used for advertising? This is about pushing messages to the user agent when it is not actively visiting a page. Ads are actively requested when you view a page, there is no need for push there.

[Animats]

The client has to have a TCP connection open to the server for this to work, right? Otherwise you run into all the problems of trying to reach machines behind DHCP, firewalls, etc.

[swartkrans]

That detail is implementation dependent. The site that wants to push to your browser hits up a third party push service provider that the user uses to get push notifications. That will probably Apple for iOS and Safari, Google for Chrome and Android, and I'm guessing Mozilla might provide one, as well as a host of other smaller companies that might be interested.

[zachlatta]

Yup, so there will be push servers that clients can connect to, so clients don't have to maintain a ton of open connections, similar to APNs and GCM for iOS and Android, respectively.

[dmritard96]

the interesting question for me is what this means for the big players and their respective platforms.

For instance, the more traditionally native features webapps take on, the less reason I have to need a native app hence am less coupled to a platform. I have always been a bit apprehensive to native apps because of platform lockin and it feels like this plus some of the push from google and their upcoming iot url push system makes it feel like web standards might really make webapps as common/popular/featured(or more) as native. It has plenty of kinks to work out around not being too spammy/sneaky with permissions but overall it feels like this is a major advancement for the web as a platform - assuming the big platform players implement it well.

[joneil]

It's good to see this in the works. Some of the apps I build are simple enough that a web-app is sufficient for almost everything, except that users really want push notifications. If this API becomes implemented (widely enough) that's one less thing we need PhoneGap and friends for.

[millisecond]

Hey, check us (Roost YCS14) out at https://goroost.com - we already do this in a way that will abstract the browser part so you don't have to change anything once the other non-Safari browsers come online.

[Too]

OT: Does anyone know what software was used to create those sequence diagrams?

[rcfox]

If you're looking to build sequence diagrams, a guy I knew made this: https://www.websequencediagrams.com

You define everything with text and it renders a diagram based on what you've written. It's kind of like the dot/Graphviz of sequence diagrams.

[DanBC]

If you want free / open source you could look at Dia. http://dia-installer.de/index.html.en

You could also try yED. http://www.yworks.com/en/products/yfiles/yed/

EDIT: This site has a nice list of a bunch of software that you can check. http://alternativeto.net/software/dia/

[swartkrans]

Looks like it could have been OmniGraffle Pro.

[iLoch]

Visio is pretty great.

[weisk]

LucidChart

[arihelgason]

Any word on when browsers other than Safari will be supporting push notifications?

[millisecond]

FWIW, I've hearing "late this year" and "early next year" from some contacts.

[TD-Linux]

There is code in nightly right now for it, I believe it is pref'd off though.

[robbytwashere]

'This section is non-normative'

Like what the hell does that mean?

Please explain.

[nhaehnle]

It means that this section contains example code, but is not actually part of the standard. From an operative point of view, this means that if it conflicts with anything else in the document, the "anything else" takes precedence.

[dingaling]

> 'This section is non-normative'

Usually it is a concise or dramatic means to demonstrate something, but not adherent to the norms of that context.

For example, pouring petrol over a sofa and igniting it to demonstrate its fireproof attributes. Not normal behaviour but useful as a demonstration.

[duaneb]

Normative is 'what should be normal', or 'ideally'—a normative argument is one pushing for a certain model of how things should be.

[domenicd]

http://ln.hixie.ch/?start=1140242962&count=1