The Firebase Public Beta

Today, we announced the opening of Firebase Beta to the public!

It’s been a few months since I joined the team, and it’s been one hell of a ride. Working at a start-up was everything I imagined it would be, and more. I can easily say that I’ve never been as productive as this before, and that there’s a lot of joy in putting a product that you played a critical role in building, out in the world for every one to see. The best thing about working in a small team who are all in the same room is the speed at which everything moves. It took me an evening to implement Persona support for Firebase, but it took even lesser time to get the feature out to our users. That’s when I learned that the amount of time elapsed between making something and shipping it can play a huge role in motivating me, and I suspect many other developers feel the same way.

Last night the entire team was in the office until midnight, polishing and tweaking everything to make sure we were ready for today’s release. Bugs were found and fixed in minutes. We even managed to implement an entire feature that we decided was important to have. The dedication and caliber of my colleagues continues to amaze me.

The night before the Firebase public beta

The real reward, however, is when I talk about Firebase with other developers. The response has been overwhelmingly positive – from veterans I know at Mozilla to folks who are just learning JavaScript at Meetups. The look on their face when they first understand how Firebase works, that ‘aha!‘ moment, is priceless. A few moments later, you can almost hear their mind sprinting through the possibilities of what they could make.

We have an excellent product, and now is the time to spread the word and help people build amazing things with it. 2013 is going to be a fun and challenging year!

A new beginning

After a nice relaxing thanksgiving week, with almost no e-mail to read (I can’t stress enough how nice this was) – I’m incredibly excited to start my first day at Firebase tomorrow! If you haven’t heard of them before, it’s because they’re a startup :) And they’re in the business of building a scalable, real-time backend for apps.

When I joined Mozilla, it was very hard for me to envision any better job than the one I had. In fact, I still think that’s true, but when I met and spoke with the folks from Firebase, I knew I had found another job that could be just as good! The team is small (7 including me), consists of really intelligent and likeable people, all of whom are engineers, and they’re working in a space I have a deep academic and professional interest in.

But why a startup? In the words of Cobb, from Inception:

What is the most resilient parasite? Bacteria? A virus? An intestinal worm? An idea. Resilient… highly contagious. Once an idea has taken hold of the brain it’s almost impossible to eradicate. An idea that is fully formed – fully understood – that sticks; right in there somewhere.

And somewhere along the way, the thought of what it would be like to work at a startup entered my head. Maybe it was the near constant buzz about startups around me, or my daily reading of hacker news. Maybe Cobb and crew planted the idea when I was unconscious on a plane. I don’t know. But there it was…

I normally ignore emails from recruiters, since most of them are poorly written and ill-researched (my friends have had similar experiences), but this particular email was well crafted and it had to do with start-ups. I was already pretty curious, and finding out more couldn’t hurt, right? Here we are!

I’m really looking forward to this roller-coaster ride, as one of the founders put it. In addition to writing code, which I love, I’ve also always enjoyed talking to others about my work. At Firebase, I’m going to be doing a bit of both, so you’ll most certainly hear more about my adventures as they unfold.

Wish me luck!

Mozilla at CampusParty ’12 and Berlin

I had the wonderful opportunity to participate at CampusParty Europe in Berlin over the last few days. I had never been to a CampusParty before, but I had a great time! It is definitely one of the more unique tech conferences out there, if you can even call it that. The most amazing thing about this event was that it was hosted at an old airport, Berlin Tempelhof, and a lot of the interiors are still intact. For instance, you can still see conveyor belts, signs like “Passport Control” and all the gate numbers. The talks themselves were located in a large hangar-like structure, which made for some odd acoustics, but the talks went surprisingly well considering 8 of them ran in parallel under a (very large) roof. Another adjacent hangar was reserved for a bunch of tents where participants chose to camp out through the entire event.

My primary focus at the event was to support the Firefox OS Challenge held by Telefonica. I spoke to a few developers on how to go about writing an app for Firefox OS, and some of the common pitfalls encountered when a website is converted into an app. I think the reception was pretty positive and it was great to meet folks who were pretty excited about Firefox OS. I was also extremely pleased that my Samusng Galaxy SII with FirefoxOS worked flawlessly through all the demos (yes, even the WiFi)!

You can find slides from my presentation here.

 

 

Mark Surman, the executive director of the Mozilla Foundation had a talk scheduled at the “free software” track.  His talk was about the Mozilla Foundation’s vision for promoting openness, innovation and opportunity on the web, with some interesting ideas on how to achieve that in the long run, over the next century. What I found particularly interesting was the notion of building a generation of Webmakers, i.e. ordinary people who know how the web works and are “literate” enough to write or hack a web page. This knowledge is mostly limited to computer programmers or engineers  these days, but Mark’s argument is that because the Internet is so vital and fundamental to human society, it is important that we educate the next generation about the web, just like we do with reading, writing and mathematics. The Webmaker project, along with tools like ThimbleX-Ray Goggles, and Popcorn are all steps in this direction. Chad Vader’s remix of Rebecca’s Black “Friday” was played at full volume during the talk, and at one point there was a caped man on stage. ’nuff said.

Next up was the charismatic Christian Heilmann, who spoke about Mozilla, the web and you. The talk covered a wide range of topics, with a focus on Mozilla’s latest efforts in the Mobile space, specifically Firefox OS. There was also a shout out to WebRTC, one of the projects really close to my heart, woo! Christian’s talks are always very entertaining, he has a blog post with links to slides and the recorded talk, which you should check out!

I also got the chance to visit the venue of our future MozSpace in Berlin. Mozilla Spaces is a project whose aim is to set up places around the world where the Mozilla community can come together to hack, design, research and all the other things Mozillians do to keep the web open. The tech scene in Berlin is pretty hot right now, and given the strength of our existing community there, it seemed like a fairly natural place to open up a MozSpace. The space is right on the historic Bernauer Straße, overlooking the memorial. There’s a lot of history behind the area, and the locality is filled with offices and co-working spaces for many other interesting startups. The San Francisco MozSpace has some serious competition with both the Paris and Berlin projects underway!

While strolling around Alexanderplatz, the city’s U-Bahn (subway) center and generally a very busy plaza, I was delighted to see Firefox Advertisements all over the walls. We did a small advertising campaign in San Francisco at the Caltrain station and the US-101 a few months ago, and this appears to be a continuation of that effort. Germany is known for its emphasis on Privacy (both Google & Facebook have had tussles with the German Government on such issues), so I hope the various messages resonated with the public. I don’t speak German, but I’m told the phrases were rather eloquent!

 

It’s been a while since I’ve been to a MozCamp (my last one was at Prague), and so I’m really looking forward to attending MozCamp EU in Warsaw. Tim Terriberry and I will be talking about WebRTC, and I hope to see some of you there!

Mozilla at Mobile World Congress 2012

The Mobile World Congress at Barcelona this year was the first trade show that Mozilla has participated in. This is new territory for us, but given that 2012 marks the year where mobile devices will far outnumber desktops & laptops, it was clear that Mozilla has to play a central role in promoting an open ecosystem for mobile devices. However, we’re a small, community-driven software company, so putting on a professional face at a trade show like MWC to tell the world that we’re serious about our enacting our mission in the mobile space can be very intimidating. Especially when you’re sharing the floor with established industry giants; Huawei, for example, had a whole city block reserved for their “booth”. Other carriers, OEMs, and hardware manufacturers had an equally large presence at the show. At the beginning of the week, what we mostly hoped for was to sneak in, show our wares and gauge interest. What we actually got exceeded our wildest expectations.

We setup our booth at App Planet to showcase many of our products that are relevant to the mobile space: Boot 2 Gecko, Firefox on Android, the Mozilla Marketplace, and Mozilla Persona. There was a continuous stream of people, on all four days, interested in checking out demos of our various products, which meant non-stop talking for booth staff! One of the things we’re really proud of is that our booth was manned by Mozilla staff who directly work on the very same products we were show-casing. This made for some very authentic demos, and we left no question unanswered.

Boot 2 Gecko

On the first day, we made an announcement that we would be partnering with Telefónica to release an open web device, a phone based fully on HTML5, powered by Boot 2 Gecko. This really resonated with almost everyone at the event, and set the tone for the following week. I had several people come up to me at our (rather modest, what I thought would be almost unfindable) booth and ask for a B2G demo, which kicked ass (and was only finished on Sunday night, most of us only saw the working phone on the first day of the show!). One gentleman from the press even commented that it was the only news worth writing about.

This is the kind of response that really energizes the entire team and validates a lot of our thinking in the mobile space. In a world that is dominated and controlled by vertical silos like those built around iOS and Android, our call for a more open eco-system is something that many at MWC were able to understand as being important, and potentially disruptive. Imagine being able to install apps from not just one marketplace, but several, or even just being able to navigate to a web page to install an app, without a gatekeeper or a middleman.

Everyone (including myself) was blown away with the performance of B2G on the demo phones, running apps like Cut the Rope (which was recently ported to HTML, CSS & JS, thanks to Microsoft) just as smoothly as the native counterpart. Our demo had a little view source button, which you could press when you were on the home screen, the dialer app, or anywhere else; and it always put a smile on the audience’s face. This is really a phone made of the web, for the web.

Mozilla Marketplace

The natural transition from the B2G demo happens when someone asks “how do users get apps on the phone?”. Mozilla is going to be running a marketplace for apps written using HTML5 technologies. Our marketplace is already open for developer submissions, and we hope to have a consumer beta ready sometime by the end of Q2 this year. We showcased some of our partner apps that have been submitted to the marketplace, running on a variety of different platforms: Android phones, tablets; Mac and Windows computers.

We’re going to have an awesome, community-driven app store (built on the same principles, and even the same code-base as our add-on marketplace), but it will by no means be the only HTML5 app store in town. We encourage, and even support, other companies wanting to setup their own stores; and developers are always free to self-publish apps on their own websites (adding an ‘install’ button to your website is really simple!). We’re going to be supporting paid apps on our marketplace, and also provide an in-app purchase API (credit cards supported via PayPal, and we’re also trying to support carrier billing in some countries); but because apps are built using the same web technologies used for building websites, developers are always free to setup their own payment systems.

It’s a really open eco-system, bringing the flexibility and distributed nature of the web to the app world. If you’re interested in the technical details of how this all works, I wrote a post sometime ago explaining it all. A very common question I received was “is there an SDK I can use?”, or “are there standard UI widgets we’re expected to use?”. The answer is that, this is not just another app store, developers will use the same technologies as they do today to build websites, with a few tweaks here and there (to support multiple screen sizes, and to support offline usage, etc.) to make an app. You can use any of your favorite JS frameworks, UI widgets and server side frameworks to build an app. Again, an app marketplace made of the web, for the web.

Firefox on Android

We also had lots of visitors to our booth who were either fans of Firefox and just wanted to say thanks (we love you all!) or were former Firefox users who now use a different browser (we love you too!).

The original version for Firefox on Android was built using the same front-end code (XUL) as on the desktop and had some performance problems. We’ve since re-written the entire UI to be much more smoother, and really focused on improving startup speed. We had some amazing demos of Firefox on Android phones and tablets that showcased all of these improvements, and more.

We also had a chance to demo some of the cool new WebAPIs that we’ve introduced (many of them driven by the needs of B2G!): such as camera access, accelerometer, vibration, etc. I think most of our visitors were very pleased with how far Firefox on mobile has come, with competitive performance and a smooth browsing experience. We look forward to pushing the latest nightly version into the Google Market on Android as soon as possible so everyone can get their hands on them! (If you’re an impatient daredevil, just head to the nightly page to download the latest & greatest).

That’s not all

Mozilla Persona came up a lot in conversations, as identity is the binding glue for all our projects. Enabling a really simple sign-in process on not just websites but also devices like B2G phones; while respecting user privacy and choice, is a high priority for us. We were able to do demos of a Persona based login to the Apps marketplace but also explain to everyone interested about how this is not just another login system like Facebook Connect, but rather a federated and distributed system for identity. Keep up with the latest developments in this space on the Mozilla Identity blog!

During the same week as MWC, Gary announced Collusion at TED U, an add-on that lets you discover who’s tracking you online. With the recent debate around user privacy, especially in the mobile space, it wasn’t surprising that there were quite a few people who were interested in Collusion at MWC. I was able to give a few demos of the add-on in action on the desktop computers, but unfortunately we didn’t have a version working on our Mobile browsers (something we hope to fix in the near future). It was awesome to be able to demo this at MWC and show to the world that user privacy comes foremost at Mozilla (Firefox was also the first browser to implement Do Not Track).

All in all, this past week has been pretty exciting for all of us. Firefox brought openness to the web almost a decade ago and played a key role in shaping the web to where it is today. However, as the world is changing and becoming more mobile, we’d like to bring the same values and principles with us into this new realm. At MWC, we showed the world that Mozilla is a serious player in the mobile space. We made a lot of promises, and we loved the response; now is the time to execute. I hope that at the next mobile world congress, we will have lived up to all our promises and have a pretty compelling demonstration of what we accomplished in 2012.

The web is the platform. And Mozilla is leading the charge. Onward!

PIPA/SOPA: Not good for anybody’s health

Wikipedia, Google, Reddit and several other major sites are protesting the PIPA/SOPA legislation by either completely blacking out their sites or by modifying their front pages to inform their visitors of this harmful legislation that the MPAA is trying get the U.S. Congress to pass. I’m proud that Mozilla will be also be participating in the ‘internet strike’ tomorrow!

I’ve rarely discussed politics on my blog, and as an Indian citizen I am particularly helpless to do anything about U.S. legislation. Mitchell and many others have already posted level-headed arguments on why PIPA/SOPA isn’t going to help anyone. However, this response from the MPAA’s chief executive Chris Dodd (who is, notably, a former US Senator) really irks me:

Only days after the White House and chief sponsors of the legislation responded to the major concern expressed by opponents and then called for all parties to work cooperatively together, some technology business interests are resorting to stunts that punish their users or turn them into their corporate pawns, rather than coming to the table to find solutions to a problem that all now seem to agree is very real and damaging.

It is an irresponsible response and a disservice to people who rely on them for information and use their services. It is also an abuse of power given the freedoms these companies enjoy in the marketplace today. It’s a dangerous and troubling development when the platforms that serve as gateways to information intentionally skew the facts to incite their users in order to further their corporate interests.

A so-called “blackout” is yet another gimmick, albeit a dangerous one, designed to punish elected and administration officials who are working diligently to protect American jobs from foreign criminals. It is our hope that the White House and the Congress will call on those who intend to stage this “blackout” to stop the hyperbole and PR stunts and engage in meaningful efforts to combat piracy.

The MPAA has, in the past, used its “power” to enact legislation that makes it illegal to manufacture DVD players that allow lawful, paying consumers to skip the FBI warning shown at the beginning of DVDs. The MPAA is now using that very same “power” and political clout to enact PIPA/SOPA. It is plainly hypocritical that the MPAA would call Google and Wikipedia irresponsible for displaying accurate information on their own websites.

Furthermore, the MPAA calls out for “co-operation” from technology companies on the matter of piracy. I am at a loss to understand why Google or any other technology company should spend even a cent of their hard-earned money on solving a problem for the MPAA. Why didn’t the MPAA use its enormous cash pile on technology that would enable them to profit from evolving technology instead of spending it all on lobbying a bill that threatens the Internet’s very existence?

The retort from the MPAA is that they’re not against the Internet, just piracy. However, that’s exactly where the problem lies. The PIPA/SOPA bills as currently drafted would give the MPAA (a private entity, mind you) the overarching power to shut down any website, without legal recourse, all in the name of combating piracy. Even if I trust the executives at the MPAA to not abuse that power, I do not fool myself into thinking that there will be no mistakes at all. Taking down a website for no real legal reason, even temporarily, is just not worth it – especially when the end goal is to let the MPAA make an extra million dollars.

Thankfully, the Internet is not designed to let any single entity obtain that much power (one could note that it is that distributed nature of the Internet that makes it so successful). Even if the bill is enacted, it will not prevent people from being able to reach these “rogue” websites that publish pirated content. Consumers will still be able to reach websites not hosted in the U.S. (as most of them are) via their direct IP address, and site owners can always be a step ahead by registering new domain names if they choose to. Not to mention, the Streisand Effect is likely to swing into action, further fueling the trend of people visiting rogue websites for pirated content. For example, it is trivial to write an add-on for Firefox and other browsers that would bypass the DNS “blacklisting” technique PIPA and SOPA propose to implement. There is no way that the MPAA, the U.S. Government, or any single entity for that matter, can stay on top of thousands of such work-arounds.

The technology companies and architects of the internet have openly informed the MPAA about the fallacies of the bill (something that they couldn’t figure out for themselves); for the MPAA to expect any more “co-operation” from them is futile.

Nobody in their right mind has ever said that piracy is not a problem. However, the benefits that the Internet brings to humanity is far too much to let a private corporation endanger it just so it can continue to profit. In the long run, for any corporation to stay in business, it must adapt to evolving technology. Digital goods are just not the same as physical objects, bits have no colour. The companies that realize this fundamental, unchangeable truth and try to capitalize on technology are the ones who will ultimately succeed, not the ones who try to fight it. In the physical realm, we don’t outlaw things that brings a lot more good to society even if you are able to do a few bad things with it (though increasingly governments seem to punish the masses in the name of fighting a few bad apples; which is also no doubt a very troubling phenomenon). I hope the MPAA will use its power and money to figure out how it can profit from technology in a way that preserves the founding principles of the internet, for its own sake, or it won’t be too long before someone who does replaces them.

Behind the Mozilla Apps Developer Preview

On Tuesday, we launched a developer preview of the Mozilla Apps project, something I’ve been working on for the better part of the year. We released a suite of tools and documentation aimed at helping developers write, deploy and sell apps built using modern web technologies like HTML5, CSS and JavaScript. Many others have already covered the question of “why” we are doing this: all the major app ecosystems out there are closed, tied to a single vendor, and could certainly use a healthy dose of the openness. There are many great things about Apps, and many great things about the Web, and we want to bring them together. [UPDATE: Tim Berners-Lee agrees!]

In this post, I want to cover the “how”. If you’re interested in writing apps, I would point you to the documentation we have on how to build them. On the other hand, if you’re curious to learn about how the system works as a whole, read on! A lot of different pieces of technology had to come together to get where we are today.

App Manifest

A fundamental building block of the system is the app manifest. Every app in the system is represented by this JSON file, documented here, which essentially contains a set of metadata about your app: name, icons, localized descriptions and so on. This manifest file is hosted at the same domain as your app. An app is uniquely identified by the domain it is hosted at, and this manifest must be served off the very same domain (at any path), with the Content-Type header set to application/x-web-app-manifest+json. We’ve received a lot of feedback stating that this is limiting, but unfortunately almost every security knob in browsers is tuned to the domain of a given page. Because we anticipate that apps will, at some point, be able to request access to elevated privileges (to use the computer’s web camera, for example), we must restrict ourselves to one app per domain. Note that app1.example.org and app2.example.org are different domains but example.org/app1 and example.org/app2 are not.

App Manifest

There are many other specifications that express ideas similar to this concept of a manifest (W3C Widgets, Chrome Web Store, etc.), and we are definitely very keen to standardize the format.

API: mozApps

The next piece we introduce are a set of new DOM APIs, present under the navigator namespace. The API offers a few different functions, but the most important one is navigator.mozApps.install. This function allows a web page to initiate the “installation” process for an app, which is identified by the URL to its manifest (explained previously). Any page is able to invoke this function, so you can self-publish your apps! Just add an “Install” button to your site and call this function with the right arguments. The API also provides a function that can tell if your app is currently installed (amInstalled).

There is another set of APIs under the navigator.mozApps.mgmt namespace. These “management” functions are only available to certain privileged domains, and are able to query the DOM for a list of all apps the user has installed, launch any given one, and uninstall an app. This API is expected to be used only by web pages that the user has explicitly authorized as being able to manage their apps on their behalf. We call such web pages “Dashboards”, and we built a default one into the system (which I shall explain shortly).

The mozApps API is fully documented, but you should note that as with any early DOM API (that we hope to standardize), it is subject to change. In fact, we’re already thinking about how we can further simplify the API and make it more standards-friendly. Join the discussion!

HTML5 App Runtime

Now, what actually happens when somebody calls a function described in the mozApps API? We’d like for users to be able to look for, install and launch apps from any standards-compliant browser without having to do anything special. So, we’ve built a fully in-content implementation of the mozApps API, provided by include.js that is served off the myapps.mozillalabs.com domain (the reason for that will become apparent when we discuss dashboards). Just include that JS file in any page that uses the mozApps API and you should be good to go! This applies to self-published apps as well as stores.

Now, whenever the install method from the mozApps API is invoked, the user is greeted with a dialog asking them to confirm if they’d like to install the app:

The Dashboard

Let’s say the user confirms the installation, what next? After a set of sanity checks against the manifest of the app, it is officially installed into the users collection of apps, which we call a repo. A Dashboard is the piece of software that is responsible for letting the user manage their repo, by allowing them to launch and uninstall their apps. Recall that the mozApps.mgmt set of APIs allow a dashboard to do this, and currently the myapps.mozillalabs.com domain is white-listed. In the future we expect people to write dashboards (which is essentially an app to manage apps!) that users can authorize. When a user visits the default Mozilla Labs dashboard, they look at something like this:

We implemented a touch friendly dashboard that works on both mobile devices and the desktop, to let you re-arrange your app icons and organize them in pages. This part of the dashboard is implemented using the wonderful icongrid library, which you are more than welcome to re-use while writing your own dashboard!

Clicking on an icon will launch that app. What does launching mean? In the HTML5 app runtime, it means it will open up the app in a new browser tab. However, we’ve also been experimenting with how we can improve this experience, which we will discuss next.

App Runtime for Firefox

For Firefox users, we have the opportunity to provide enhancements to the whole app installation and launch process while we wait for the API to get standardized. We’ve written an add-on that implements the mozApps API, which will override the include.js HTML5 runtime version (so stores are encouraged to continue including the include.js version to provide the most portable experience for their users). If you have this add-on installed and install an app from any page or store, you will be greeted with a doorhanger that asks you confirm if you really intend to install this app:

Note that there’s an extra option in there that asks if you want to install the “native” app version or not. On Windows and Mac, this means that we will automatically generate a .EXE or .APP that wraps your web application into a shell that looks and feels like a real app! For example, on the Mac, we will create a menu bar and dock icon for you:

Cool? Sounds pretty familiar to the Prism experiment, right?

In addition to this style of “native” launching, users can also use the dashboard from before as usual. Launching from the dashboard will open it in an app tab, a nifty little Firefox feature.

App Runtime for Android

An important feature of Apps written using web technologies is that they can work on a variety of different devices. We want users to be able to buy an app only once and use it not only on their desktop, but also on their tablets and phones. We’re going to start out with Android (iOS has its own set of tricky technical and policy problems to deal with), by introducing an App Runtime (codename “Soup”).

The App Runtime for Android is a native Android application that lets users install, launch and manage their apps just like on the desktop:

Mozilla App Marketplace on Android

Installing an app on Android using Soup will create an icon in your home screen, tapping on it will launch the app using our embedded web runtime. Well built web applications can now look and feel just like native android apps!

Roundball on Android

In addition, apps that you installed on the desktop can be automatically synchronized to your phone (and all your other devices) using our Sync functionality, which we will discuss next.

Sync

Users shouldn’t have to install apps on every device they own once they’ve purchased it. We’ve developed an AppSync solution for the HTML5 runtime, Firefox runtime as well as Android. In all three environments, you should be prompted to login with your BrowserID (Mozilla’s new federated & distributed Identity system) when you visit the dashboard:

Login for AppSync

Once you’ve logged into your dashboard, your apps from all your devices should start automatically synchronizing!

App Marketplace

Search is a great tool for the web, and we expect that many users will discover apps using search engines. However, directories have their place and are an invaluable tool to create a community around apps. Mozilla has been running addons.mozilla.org (AMO) for a while now, an easy place to find, install and review add-ons for Firefox. We want to build a similar store for Apps, and as part of the developer preview, we launched apps-preview.mozilla.org. This preview of our “app store” lets developers submit an app by telling us the link to their manifest (the process is very similar to how you submit an add-on for inclusion on AMO). Once the application is accepted into the store users can find, install, review and provide ratings for apps. This store uses the same mozApps install APIs we discussed earlier, and we expect that others will build their own stores. We want competition in the app store market too!

Supporting developers who want to sell apps is also important to us. We’re testing integration with Paypal as part of the developer preview, which will allow developers to sell apps across the world at various price tiers.

Receipts

How do we balance the need for developers to be able to charge for their apps, while allowing users to use an app they’ve already paid for across all their compatible devices? We’ve devised a receipt format that helps achieve this. When a user completes the payment process on a given store, the store will generate a receipt of this format and pass it to the mozApps API as part of the install data provided to the install call. The implementation responsible for providing the API will stash the receipt along with the app itself (and all devices the app is synced to).

At launch time, the app can ask for the receipt associated with itself using the amInstalled API call, do an integrity check, and send it over the original store that issued the receipt. The store can then verify that the receipt is indeed valid and notify the app, at which point the app can decide whether to let the user run it or not. We’ve provided a utility function verifyReceipt to help the app developer do all of this.

Do note, however, that this whole scheme is merely intended to help developers who don’t want to setup their own payment systems. Developers are free to write apps that use their own (or 3rd party) payment or subscription services. You could, for example, sell your app for free on the AMO store, but ask users to login when the app is launched, or implement your own in-app purchasing system. We will do what we can to help, but in the end, you’re in full control of what your users see when they launch your apps!

What’s next?

This is just the beginning, we have a lot more work to do before we can realize a flourishing and open app ecosystem for the web. Here are just some of thing we have planned for the next few months:

  • Building out a “Web Runtime”, or WebRT. We’ve built an initial prototype of how such a runtime might work in the add-on for Firefox, and we want this to extend this to a more robust system with auto-updates and deeper OS integration.
  • Capabilities. In conjunction with the WebAPI project, we want to provide apps with more device APIs and capabilities than regular web pages, while giving the user an easy way to control and hand out permissions. This includes things like camera access, filesystem APIs and more.
  • Web Activities. A while ago we release a prototype of the apps extension that supported what we call web activities, a way for apps to communicate with each other safely and easily. You could use this, for example, to upload a picture to a site from your favorite photo service, or to share a link from an app to all your friends using your favorite social network. The Firefox Share add-on already relies on web activities to do the latter.
  • Push sync & notifications. We want users to be able to “push” apps to any of their devices directly from an app store.
  • Standardization. It is critical for the health of the web for all of these app related APIs to be standardized and supported by all interested parties.

Most importantly, we want you to get involved and help us build!

Show me the code

I’ll end this post with a brief description of all the code behind the various pieces in hopes of attracting contributors :) All of our code is hosted on Github and licensed under the MPL/GPL/LGPL tri-license.

The main repository for the Apps project can be found here. It contains the source code for the HTML5 App Runtime (include.js and trusted.js are the important pieces), the App Runtime for Firefox and the Dashboard that is currently deployed on myapps.mozillalabs.com. The Dashbaord was built using IconGrid, a JavaScript library to build touch friendly scrollable pages. The App Runtime for Firefox is written using the Add-on SDK and shares a few common files with the HTML5 runtime (repo.js, urlparse.js, manifest.js and sync.js).

Source code for the Android App Runtime (codenamed ‘Soup’) can be found here. It is a regular Android application written in Java with an embedded PhoneGap instance to support the marketplace and app launching.

On the server side of things, Zamboni is the code that powers addons.mozilla.org, and was extended to support apps-preview.mozilla.org. It is built on Django. The AppSync server is also written in Python (using Cornice) and is what powers app synchronization across all three runtimes (HTML5, Firefox and Android). The AppSync server in turn talks to Sauropod, written in node.js and backed by HBase. Sauropod is a Mozilla Labs experiment aimed at building a secure storage system for user data. Tarek Ziadé has a more comprehensive overview of how all the server side pieces fit together, which you should go read!

Don’t hesitate to participate and ask questions on our mailing list. We encourage you to play around with the system and file any bugs that you may find here. Together, we can make an open, healthy app ecosystem for the web a reality. We look forward to hearing from you!

Follow

Get every new post delivered to your Inbox.