Peer-to-Peer Inside the Browser: Lloyd Hilaiel from BrowserPlus interviews Alex MacCaw about MachSend

There is a lot of talk about the blurring lines between the desktop and the web--the notion that most of the desktop programs we use will be transparently replaced with web applications in a silent revolution. Recently Alex MacCaw, co-founder of Lead Thinking, LLC, and frequent Rails hacker, showed us that this revolution is already upon us.

MachSend is a web application that lets you share files using peer-to-peer technology. The fact that no tools exist to build peer-to-peer applications inside the browser didn't stop Alex. Having heard about BrowserPlus, an open platform from Yahoo! which makes it possible to extend the web, he used it to drop NAT traversal technology into popular browsers, and then went and built MachSend on top. We were extremely impressed with Alex's work, and spent a little time talking with him to get the details on how he put this app together.

Lloyd Hilaiel
Yahoo BrowserPlus team

Screen%20shot%202009-10-22%20at%2010.39.40%20AM.png


1. Tell us a little bit about MachSend? What is the product and why is it interesting?

Machsend allows free unlimited peer to peer file transfers from inside the browser. You can just go to machsend.com, drag a few files on, and share the uniquely generated link. You can share the link with people via IM, for example. Anybody with your link can download the files.

2. "Peer to peer" file transfer? What are the benefits of peer to peer vs. a server proxied transfer to the end user and to you, the developer?

To the user a P2P file transfer is faster than a relayed one, and their data is more secure, since it's not shared with any third party. P2P benefits the developer in that they don't have to pay any data transfer charges. I'm passing on these savings by removing any limits to file transferals.

3. Neat. Given all of the other ways to transfer files, why do you feel that MachSend is compelling?

Machsend is just quicker, there's no registration and no cost. There are no restrictions in the amount you can transfer, and the data gets transferred faster (especially on the same network).

4. When designing MachSend, what technological requirements did you have? What ultimately led you to want to build something in-browser?

Most computers on the internet are behind NATs, a system designed to secure networks and use fewer IP addresses. However, most NATs don't natively support P2P connections, and require a bit of coaxing to do so. Typically P2P connections use UDP, rather than TCP, as it's initially easier to establish a connection. I needed a reliable
connection though, with guarantees that all the data would reach the endpoint. Rather than re-implementing TCP's reliability and flow control in UDP, I explored the possibility of using a TCP connection - fairly unusual in P2P programs.

Initially I was a rather at a loss on how to proceed, but I found a paper where some students had tested a lot of TCP P2P techniques on different routers, and recommended a particular one. I implemented their recommendation which works on about 80% of the NATs they tested.

It was built in the browser simply out of convenience to the end user. I didn't want users to have to download and install a piece of software just to send and receive files. I was also familiar with building web applications, and was keen to reuse existing skills.

5. Once you decided to build in-browser, why did you choose BrowserPlus? What were some of the other technologies available to you and from what perspectives was BrowserPlus superior?

I looked at a few other technologies such as Java, Silverlight, and Flash. However, Java and Silverlight both had cross-domain restrictions. Flash 10 has P2P capabilities, but it was flawed for file transfers since files had to be completely loaded into memory.

BrowserPlus didn't have these limitations, and I was excited to see Ruby was supported (which would speed up development considerably). After developing a few BrowserPlus services, such as a Bonjour one, I decided on using it for MachSend.


6. What were the major pain points in using and extending upon BrowserPlus? What do you think needs to be done better?

The API is a bit long winded, and isn't very 'Rubyish'. I know the BrowserPlus team is taking steps to address this and that Ruby is being upgraded to 1.9. One other thing that I've been getting lots of requests for is Linux support (which I know Yahoo! is also working on).


7. Very concisely, what were some of the best parts about using BrowserPlus? What has the team done right?

I think the serialization decisions the BrowserPlus team made were correct, only allowing a few data types to be translated from Ruby to Javascript, and visa versa. I like the asynchronous nature to the API and that BrowserPlus is running in a different process, so it doesn't bring down the browser if anything goes wrong. Most of all I like how much scope and opportunity BrowserPlus gives to developers - I could never have built MachSend in any other browser plugin.


8. Finally, can you give us a sneak peek of what's next with MachSend? What has user feedback been and what features do you expect you'll add in the future?

Well, I originally built MachSend to promote my company's other product, a moderation platform called Socialmod. However it's been so popular that I'm planning to make it a product in its own right. Next steps are to enhance usability, and add encryption. I'll always keep the basic product free, but I aim to add a premium version with support for asynchronous transfers - so you don't have to keep the browser window open.