Chalk this up as an idea that may have been done… or someone’s planning it and I don’t know.

Anyone familiar with the Einstein@HOME project? The idea’s pretty simple: you have a large number of calculations to perform, but supercomputers are a little expensive. Instead, you write an application which many home computers can download and run, and communicate with your main server.

I used to participate in it, but a couple features kept me off. First, I couldn’t share it between computers. Second, when I had to get rid of a machine, I couldn’t transfer the results to a new one. The final straw for me was when I found out a few years ago the Einstein@HOME project had accidentally been recycling data – sending me and several others data to crunch which had already been through the whole verification process. (What’s the point of leaving my machine on for days or weeks then?)

Now, imagine writing your distributed-computing application for a web browser. A little HTML, maybe some canvas work to make it look pretty (and show what you’re doing), and a whole lot of JavaScript.

Suddenly, you’ve got a lot of the necessary infrastructure built for you. Portable user accounts? Yep, we’ve been doing that for the last fifteen years (log-in pages). Communication with the home server? XMLHttpRequest. Fast calculation times? All the major browsers are implementing just-in-time compilation for frequently executed JavaScript – which is ideal for distributed computing (it executes a section of code very frequently).

There’s a few other benefits, too. It’s very hard to crash the platform in JavaScript – you have to go out of your way to do that. The whole WWW opens up to you, in a well-tested platform. Oh, and there are literally hundreds of millions of users of the major browsers. (Dare I say billions, plural? If not now, soon.) Distribution of your application becomes even easier than it is now: it’s just a web site. Plus, users can see when they’re on a secure connection to you (that little padlock in the corner).

When your application lives in a web page, your users can be fairly confident you’re not doing something evil to their machine. Security holes aside, outside the browser there’s few traces left behind. So it’s even environmentally friendly to the computer’s eco- and operating- system!

Of course, when you write something to force a JavaScript engine to do lots and lots of calculations, you’re going to start pushing the boundaries of what the platform is capable of. Which isn’t necessarily a bad thing: with Mozilla, you get an open, competent and somewhat responsive platform support community. If a bug is easy to reproduce – especially if it breaks the JavaScript engine (less so if it breaks something else) – and is filed in the right place on Bugzilla – and you’re nice to the community in question (politeness and patience helps!), you can get a pretty good response.

An obvious downside is that a distributed-computing web application could really wreak havoc as a botnet or a denial-of-service to the browser’s users. Here, the infrastructure of the browser could help again: for Firefox, Mozilla simply could put the dangerous application’s web site on their dangerous sites blocklist. Once that happens, and the user loads the web page, they see a big red warning page first, with a traffic cop icon scaring them off. The botnet disappears (or at least is seriously reduced in size, and thus, potency).

Commercializing a distributed-computing web application – where the end-user gets paid a little at a time for their results – might be practical too. (PayPal, anyone?) That could lead to a few dangers, though: who do you trust with tens of thousands of computers?

Right now, this is just an idea. I have no idea who might be working on that already, or if it’s just not practical. Comments welcome, though.