So, i should probably talk about what the heck i've been doing at Mozilla, shouldn't i?
Well, with things finally starting to surface, i'm a bit more comfortable talking about them. The first part of what i'm working on is Notifications. What the heck is "Notifications" you ask? Well, it's kinda tricky.
The elevator pitch i like to give is "Somewhere between Instant Messaging and Email is 'Notifications'". It's a way for sites to semi-anonymously send messages to a user. Communication is one way right now, mostly for simplicity sake between the site and the user, but there's precious little to prevent the communication from going either way.
Ah, this is our floor, shall we get out of the elevator and actually talk about this? Cool.
The history lesson
A little over a year ago, a couple of damn bright interns spent their summer building a prototype notification system that used AMQP and a few other things to pass messages back and forth. The cool thing is that it allowed browsers to talk to browsers, or sites to talk to browsers or really anything to talk to anything. You could get twitter announcements in your chrome, or send a tab to your mobile device or all sorts of things. It was spiffy, but unfortunately, had issues. A fairly large one was relying on AMQP, meaning a persistent socket connection. That's expensive on a whole slew of levels, not including trying to convince your grandma to punch a hole into her firewall.
So, as is the case with a lot of good ideas, we headed back to the whiteboard to figure out what elements we can use. Some things, like sending a tab to a device, turned out to work better if we used something like sync. That still left a few other features that we wanted.
Enter the BrowserID
BrowserID is cool. The ability to log into a site by selecting what email you want to provide to them is amazingly simple! Granted, if you're logging into a site like GnomeBondage.com, you probably don't want to give them an email that will let them fill your work email box with things you may not want your employer to see.
That's why you want something that is a bit harder for them to associate back to you. And that's what i've been working on.
(Originally, Bipostal (BrowseriD Postal Services, no, really. Stop giggling like that.) was meant to be a later addition to the Push Notifications stuff. Because BrowserID pushed forward, though, the need was higher for that part.)
So, Bipostal generates a token that is specific for you and the third party site (say example.org). The token is ~64 base36 characters resulting in 64*(log2(36) ~= 5.17) = 330 bits of entropy or 2187250724783011924372502227117621365353169430893212436425770606409952999199375923223513177023053824 possible combinations. That's pretty large. Plus, we're doing a number of things to prevent spammers and other ne'er do wells from sending in just random garbage.
When a site wants to send you a note, the send it to an address like "email@example.com". We make sure it's legit, strip out the fancy HTML cruft, and sent it to you. You can also quiet messages to that address (if some site turns out to be overly chatty) or delete that ID. In the future, sites can include bits of JSON in their email that can get pulled out and sent to you as notifications. All magical and pseudonymous. Well, unless you fill out all the profile info with your real values, in which case, they know everything about you, but that's an "out of band" problem.
What's to come
Honestly, quite a bit. While a lot has been nailed down (both Push and Bipostal are on Github), but that doesn't mean we don't want to hear folks comments and ideas. i've included two of the ways you can provide feedback on the Notifications main page. Likewise, you can comment here and i'll try to respond both here and via email.
Likewise, we'd really love for other companies to help us work out the details to provide a cost effective, light weight platform for this sort of thing. (Websockets and SIP are neat, but require persistent connections which can be costly. We have the option to do message encryption, which would allow the server to not know the content of the message being transmitted, but it would be neat to use non invasive encryption validation to see if we can prevent bogus messages from being delivered.) It's always good to have bigger brains helping out. There's a lot we can do and a lot we're trying to make sure we don't mess up.
Now more than ever, What do you think?