10 ms·

Push API – W3C Working Draft

162 points by sinak 12y ago

swartkrans 12y ago
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.
- pan69 12y ago
  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?
  - m_eiman 12y ago
    Yes, and it has to maintain TCP connections with every push source you've registered, including re-connecting whenever your network situation changes. IMHO, this will lead to a lot of wasted bandwidth. Might not be a problem on desktop machines, but on mobile devices…
    - zachlatta 12y ago
      It already happens on mobile devices through APNs, GCM, and the like. Maybe mobile web browsers will have backing cloud services that use the mobile OS's recommended push server as a frontend to the mobile device? That doesn't sound like an ideal scenario though, considering that then the cloud service would have an enormous amount of user data going through it.
      - lucian1900 12y ago
        APN and GCM multiplex messages from all apps on a single TCP connection. That makes a significant difference.
        domenicd 12y ago
        That is how the Push API works as well. In fact usually developers will be using APN or GCM when they use the Push API.
    - aikah 12y ago
      well how do smartphones and apps deal with push notification in general? (i mean native apps)
      - nostrademons 12y ago
        The OS provides a messaging service. Applications can request differing levels of latency guarantee. The default on Android is to deliver immediately unless the device is off or sleeping, in which case it'll be queued for up to 4 weeks or until the device wakes up, whichever comes first. There is also throttling functionality, where an app that sends too many messages in a short period of time will find that its messages are only delivered when the device radio has to wake up for other non-throttled messages.
      - m_eiman 12y ago
        With iOS, Apple provides a service that event sources push their messages to, and a single TCP connection is maintained with the device regardless of the number of event sources. Google has something similar, if not identical.
- SynchrotronZ 12y ago
  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.
  - mmahemoff 12y ago
    "User agents must not provide Push API access to webapps without the express permission of the use" I share your concern. but I share a great fear that web apps will become increasingly irrelevant if they remain just documents that can't do anything when they're not explicitly in a running tab/window. The permission requirement is the same one that allows for local storage, which could have caused great problems, but has so far held up well.
    - travisby 12y ago
      And the Ask toolbar doesn't get installed without expressed permission, either.
    - dspillett 12y ago
      > The permission requirement is the same one that allows for local storage Assuming this does not allow the push of UI interaction, then yes. If it would allow UI responses to be pushed then we would be one XSS vulnerability or "uneducated users" away from a new set of exploits for forcing pop-under advertising , and other potentially more insidious problems, through. Local Storage and Index DB are storage only so the only attack routes are DoS-due-to-disk-full-errors which is generally less attractive (you can make more money pushing stuff to people than pushing people off the network).
  - vbezhenar 12y ago
    Safari supports push notifications from websites for a while. I've found it convenient for the news websites I often visit just to check for new content. It's like RSS integrated into OS. One can misuse it, but generally it's useful.
- smanuel 12y ago
  > 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/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html 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(...
  - rakoo 12y ago
    I believe this spec is aiming to standardize the service offered primarily by Google (GCM) and Apple (APN), and open/standardize it for other people like pubnub/parse/pusher/...
  - mmastrac 12y ago
    The new web APIs are promise-ified by default rather than using the callback model of the past. So rather than register(callback), it's register().then(...). Whether this is a good thing or not is another question I don't know the answer to.
    - smanuel 12y ago
      My comment was mainly about serviceWorker.ready.then. I've never seen a JS API using such pattern - the name of the event as a property which is a promise. A manager object/class also usually rings a bell. Not that I'm an API specialist but I would rather implement it as: document.addEventListener("serviceready", function() { window.pushNotification.register().then(.....
      - AgentME 12y ago
        For an event that only happens once, then the navigator.serviceWorker.ready.then(function(){... version is preferable to document.addEventListener("serviceready", function() { because A) you don't have to worry about removing your event listener after the fact, and B) if the event has already happened, then your callback will be called immediately.
- andrewstuart2 12y ago
  >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/ http://www.w3.org/TR/eventsource/
Animats 12y ago
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.
- zachlatta 12y ago
  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.
- swartkrans 12y ago
  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.
Too 12y ago
OT: Does anyone know what software was used to create those sequence diagrams?
- iLoch 12y ago
  Visio is pretty great.
- swartkrans 12y ago
  Looks like it could have been OmniGraffle Pro.
- weisk 12y ago
  LucidChart
- rcfox 12y ago
  If you're looking to build sequence diagrams, a guy I knew made this: https://www.websequencediagrams.com 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 12y ago
  If you want free / open source you could look at Dia. http://dia-installer.de/index.html.en http://dia-installer.de/index.html.en You could also try yED. http://www.yworks.com/en/products/yfiles/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/ http://alternativeto.net/software/dia/
  - grap 12y ago
    The list from your edit is great. I didn't even know that alternativeto.net existed.
joneil 12y ago
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 12y ago
  Hey, check us (Roost YCS14) out at https://goroost.com 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.
robbytwashere 12y ago
'This section is non-normative' Like what the hell does that mean? Please explain.
- nhaehnle 12y ago
  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 12y ago
  > '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 12y ago
  Normative is 'what should be normal', or 'ideally'—a normative argument is one pushing for a certain model of how things should be.
- domenicd 12y ago
  http://ln.hixie.ch/?start=1140242962&count=1 http://ln.hixie.ch/?start=1140242962&count=1
pratik23 12y ago
YOU MUST CHECK THIS OUT.... https://www.youtube.com/watch?v=RCv-xZygxV4 https://www.youtube.com/watch?v=RCv-xZygxV4
pratik23 12y ago
YOU MUST CHECK THESE OUT..... https://www.youtube.com/watch?v=1PEbxryfx7Y https://www.youtube.com/watch?v=1PEbxryfx7Y https://www.youtube.com/watch?v=SdTg7b8HbkU https://www.youtube.com/watch?v=SdTg7b8HbkU
paulojreis 12y ago
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 12y ago
  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.
  - paulojreis 12y ago
    So "they" can reach you, even if you don't visit. I guess it will be used to "remind" or notify you of all new posts/entries/content/everything. From there, it can move fast to notifying you about a new sponsor (or just saying who sponsored the new post). Of course, it will need user approval, so the problem is (I hope) minimized (but just wait for the amount of Google+ "friend invites" notifications you will receive, even if you visited it only once).
Beltiras 12y ago
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 ....
mike-cardwell 12y ago
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 12y ago
  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/ http://www.w3.org/TR/eventsource/
  - mike-cardwell 12y ago
    Yes, you can already add your own encryption on top of the push system. What I was proposing is that it is standardised and doesn't require any extra code from the application developer. So when I want to push a message out to one of my users, the push software I am using will handle encrypting it, and the push software on the users device will handle decrypting it. They will both be aware of the encryption keys involved because they will have negotiated them during the initial direct connection and will have them stored.
arihelgason 12y ago
Any word on when browsers other than Safari will be supporting push notifications?
- millisecond 12y ago
  FWIW, I've hearing "late this year" and "early next year" from some contacts.
- TD-Linux 12y ago
  There is code in nightly right now for it, I believe it is pref'd off though.
millisecond 12y ago
This (and current Safari support) is what we (Roost - https://goroost.com 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.
dmritard96 12y ago
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.

162 points by sinak 12y ago

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.

pan69 12y ago
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?
- m_eiman 12y ago
  Yes, and it has to maintain TCP connections with every push source you've registered, including re-connecting whenever your network situation changes. IMHO, this will lead to a lot of wasted bandwidth. Might not be a problem on desktop machines, but on mobile devices…
  - zachlatta 12y ago
    It already happens on mobile devices through APNs, GCM, and the like. Maybe mobile web browsers will have backing cloud services that use the mobile OS's recommended push server as a frontend to the mobile device? That doesn't sound like an ideal scenario though, considering that then the cloud service would have an enormous amount of user data going through it.
    - lucian1900 12y ago
      APN and GCM multiplex messages from all apps on a single TCP connection. That makes a significant difference.
      - domenicd 12y ago
        That is how the Push API works as well. In fact usually developers will be using APN or GCM when they use the Push API.
  - aikah 12y ago
    well how do smartphones and apps deal with push notification in general? (i mean native apps)
    - nostrademons 12y ago
      The OS provides a messaging service. Applications can request differing levels of latency guarantee. The default on Android is to deliver immediately unless the device is off or sleeping, in which case it'll be queued for up to 4 weeks or until the device wakes up, whichever comes first. There is also throttling functionality, where an app that sends too many messages in a short period of time will find that its messages are only delivered when the device radio has to wake up for other non-throttled messages.
    - m_eiman 12y ago
      With iOS, Apple provides a service that event sources push their messages to, and a single TCP connection is maintained with the device regardless of the number of event sources. Google has something similar, if not identical.
SynchrotronZ 12y ago
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.
- mmahemoff 12y ago
  "User agents must not provide Push API access to webapps without the express permission of the use" I share your concern. but I share a great fear that web apps will become increasingly irrelevant if they remain just documents that can't do anything when they're not explicitly in a running tab/window. The permission requirement is the same one that allows for local storage, which could have caused great problems, but has so far held up well.
  - travisby 12y ago
    And the Ask toolbar doesn't get installed without expressed permission, either.
  - dspillett 12y ago
    > The permission requirement is the same one that allows for local storage Assuming this does not allow the push of UI interaction, then yes. If it would allow UI responses to be pushed then we would be one XSS vulnerability or "uneducated users" away from a new set of exploits for forcing pop-under advertising , and other potentially more insidious problems, through. Local Storage and Index DB are storage only so the only attack routes are DoS-due-to-disk-full-errors which is generally less attractive (you can make more money pushing stuff to people than pushing people off the network).
- vbezhenar 12y ago
  Safari supports push notifications from websites for a while. I've found it convenient for the news websites I often visit just to check for new content. It's like RSS integrated into OS. One can misuse it, but generally it's useful.
smanuel 12y ago
> 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/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html 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(...
- rakoo 12y ago
  I believe this spec is aiming to standardize the service offered primarily by Google (GCM) and Apple (APN), and open/standardize it for other people like pubnub/parse/pusher/...
- mmastrac 12y ago
  The new web APIs are promise-ified by default rather than using the callback model of the past. So rather than register(callback), it's register().then(...). Whether this is a good thing or not is another question I don't know the answer to.
  - smanuel 12y ago
    My comment was mainly about serviceWorker.ready.then. I've never seen a JS API using such pattern - the name of the event as a property which is a promise. A manager object/class also usually rings a bell. Not that I'm an API specialist but I would rather implement it as: document.addEventListener("serviceready", function() { window.pushNotification.register().then(.....
    - AgentME 12y ago
      For an event that only happens once, then the navigator.serviceWorker.ready.then(function(){... version is preferable to document.addEventListener("serviceready", function() { because A) you don't have to worry about removing your event listener after the fact, and B) if the event has already happened, then your callback will be called immediately.
andrewstuart2 12y ago
>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/ http://www.w3.org/TR/eventsource/

Animats 12y ago

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.

zachlatta 12y ago
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.
swartkrans 12y ago
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.

Too 12y ago

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

iLoch 12y ago
Visio is pretty great.
swartkrans 12y ago
Looks like it could have been OmniGraffle Pro.
weisk 12y ago
LucidChart
rcfox 12y ago
If you're looking to build sequence diagrams, a guy I knew made this: https://www.websequencediagrams.com 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 12y ago
If you want free / open source you could look at Dia. http://dia-installer.de/index.html.en http://dia-installer.de/index.html.en You could also try yED. http://www.yworks.com/en/products/yfiles/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/ http://alternativeto.net/software/dia/
- grap 12y ago
  The list from your edit is great. I didn't even know that alternativeto.net existed.

joneil 12y ago

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 12y ago
Hey, check us (Roost YCS14) out at https://goroost.com 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.

robbytwashere 12y ago

'This section is non-normative' Like what the hell does that mean? Please explain.

nhaehnle 12y ago
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 12y ago
> '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 12y ago
Normative is 'what should be normal', or 'ideally'—a normative argument is one pushing for a certain model of how things should be.
domenicd 12y ago
http://ln.hixie.ch/?start=1140242962&count=1 http://ln.hixie.ch/?start=1140242962&count=1

pratik23 12y ago

YOU MUST CHECK THIS OUT.... https://www.youtube.com/watch?v=RCv-xZygxV4 https://www.youtube.com/watch?v=RCv-xZygxV4

pratik23 12y ago

YOU MUST CHECK THESE OUT..... https://www.youtube.com/watch?v=1PEbxryfx7Y https://www.youtube.com/watch?v=1PEbxryfx7Y https://www.youtube.com/watch?v=SdTg7b8HbkU https://www.youtube.com/watch?v=SdTg7b8HbkU

paulojreis 12y ago

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 12y ago
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.
- paulojreis 12y ago
  So "they" can reach you, even if you don't visit. I guess it will be used to "remind" or notify you of all new posts/entries/content/everything. From there, it can move fast to notifying you about a new sponsor (or just saying who sponsored the new post). Of course, it will need user approval, so the problem is (I hope) minimized (but just wait for the amount of Google+ "friend invites" notifications you will receive, even if you visited it only once).

Beltiras 12y ago

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 ....

mike-cardwell 12y ago

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 12y ago
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/ http://www.w3.org/TR/eventsource/
- mike-cardwell 12y ago
  Yes, you can already add your own encryption on top of the push system. What I was proposing is that it is standardised and doesn't require any extra code from the application developer. So when I want to push a message out to one of my users, the push software I am using will handle encrypting it, and the push software on the users device will handle decrypting it. They will both be aware of the encryption keys involved because they will have negotiated them during the initial direct connection and will have them stored.

arihelgason 12y ago

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

millisecond 12y ago
FWIW, I've hearing "late this year" and "early next year" from some contacts.
TD-Linux 12y ago
There is code in nightly right now for it, I believe it is pref'd off though.

millisecond 12y ago

This (and current Safari support) is what we (Roost - https://goroost.com 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.

dmritard96 12y ago

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.