Firefox has a presence on most operating systems (Mac, Windows, Linux, Android and iOS), so the goal would be that a website could send you a notification whenever and Mozilla would figure out the best place to alert you of it.
(Disclaimer: Mozilla employee, but not working on notifications)
This is word-for-word what Notifo was built to accomplish. Maybe with the weight of Mozilla behind the effort (and a large pre-existing install base) they will have more success.
I have the same problem with this feature I had with Notifo: It sounds awesome, until I try to think where I'd use it. I can't find many uses where it would beat email, even though I use it for some things like HN comment replies, notifications for actions on my web apps and various personal events.
I think the area where notifications are important, but slightly less important than email, yet not so unimportant that you don't want to have a user install another app, is pretty small... Too bad, I very much like the idea of Notifo. When will it stop working? Do you plan on open sourcing any part of it?
But it does compete with email, I get instant push notifications on my email client on all my devices. The killer feature of Notifo et al is that you can customize the alerts that will be generated, but that's a small part of what the notification does (i.e. notify you).
Interesting idea - I'd be happy to have a standard method of passing notifications that were simpler than an email from any site to any user.
But I do not like the idea of tying it to web browsers, or to one aggregator. If I want all of my notifications to go to Google and be turned into emails, or to Facebook and appear in my inbox there, or to a server I run myself, where I can get them with a desktop app, then I should be able to.
I don't see anything that ties people to a single aggregator, and it's not common for Mozilla to design for that. From the spec[1] it seems they're designing a system where client has to accept any URL to notify and any server can work as long as they accept POST request with certain parameters.
Right, one of the goals of the design is to not lock in any one aggregator. We just need to standardize the server API so other apps don't have to care who they're talking to.
Looking at the higher level document* the Post Office seems to require the Mozilla ID. It's possible that that just means "A unique ID for that server", but I'd like that to be explicit.
Thanks for pointing this out. SMTP, for example, is sort-of equivalent to what Mozilla is doing. (send messages to users, remove duplicates, and verify the user's and sender's identity)
SMTP isn't directly usable in a browser - they're not competing directly - but SMTP is a federated system with an open protocol.
It's crazy how much browsers are becoming operating systems. I'm neither for nor against it in general; I simply think it is an interesting thing to watch happen. However in this case, I think it makes more sense for the user to download a desktop application in order to get push notifications directly from the server when not browsing the website.
I guess they don't want the app to hold open connections to every site (some people have solved the C1M problem but some haven't) and they probably want a server to buffer messages when the app is not running. You'd run into these same issues whether the notifications are received by Firefox or a different desktop app.
It's a web app, it already has a server. It must be possible to design this in a way that you use only your own server in the process, and not mozilla's.
I'm betting this is more about boot2gecko than Firefox. Maybe not a lot more, but it's certainly necessary for boot2gecko to have any feasibility.
Does anyone know why they're pushing this instead of plain old Server Sent Events (something w3c is already working on for servers to push to browsers)?
I think notifications will be useful in all our browsers, not just B2G. I'm targeting Firefox Mobile for the initial release since mobile is where notifications fit in the best.
I don't see notifications supplanting Server Sent Events. SSE gives developers a lot more control over the stream since it's connected directly to your server, and you don't have to bother the users with permission dialogs. You'd use push notifications if the user doesn't have your site open, but otherwise SSE gives you more power.
Cool. :) Thanks for the reply. I had assumed that an "app" made for Firefox or Chrome would be able to register a handle for a Server Sent Event so that apps could be notified or have their state changed via an Action even if the tab isn't open. Somehow I missed that this was that functionality via a new API.
As for B2G, I think I just got excited about it because notifications was the bit I was interested in seeing work out.
Does anyone know why they're pushing this instead of plain old Server Sent Events (something w3c is already working on for servers to push to browsers)?
They're very different notifications. SSE is only useful if the user happens to have the website open. This new proposal is a replacement for emails - it lets you send asynchronous notifications to the user that he may receive even if he's not on your website and even if he was offline for a while.
What about notifications that don't require Firefox to be opened? Or notifications that don't require an internet connection? or notifications that don't require your computer to be on? What about notifications that don't even require me to be awake? Send me push notifications through ether, straight into my brain.
http://jbalogh.me/2012/01/30/push-notifications/
And, the wiki page:
https://wiki.mozilla.org/Services/Notifications/Push/API
Firefox has a presence on most operating systems (Mac, Windows, Linux, Android and iOS), so the goal would be that a website could send you a notification whenever and Mozilla would figure out the best place to alert you of it.
(Disclaimer: Mozilla employee, but not working on notifications)