Grimwire and WebRTC: An Interview With Paul Frazee

Using the data channel to replace servers. You know what I think about the data channel in WebRTC – it being the most fascinating aspect of it. I've been trying to figure out in the past several months what's this project Grimwire exactly is, which got me to Paul Frazee, who is developing this framework. What it essentially does, is offer a mechanism that turns web browsers into web servers within a larger network. And with where Paul is headed, this means decentralization of networks. Here's what Paul had to say to me about his project.   What is Grimwire all about? Grimwire is about host-independent software. It's a toolset for running Web services from the page, and it includes facilities for exchanging links so applications can discover each other and configure together. You might think of it as "HTTP over WebRTC"... and over Web Worker channels, and Web Sockets, and to Javascript functions. It's Ajax to anywhere. The motivation is to pick up where projects like Diaspora left off with meaningfully private and user-owned software. There's a rich community of Web developers that can't tap into their software and tweak it without owning the network in the first place. That's a missed opportunity. Where's our Emacs? What kind of creativity could we open up if the web app could be rewritten with modules in the clients? That's where Grimwire is focused: unlocking more control, more creativity and more privacy.   What excites you about working in WebRTC? RTC is an enormous improvement for Web privacy. It creates encrypted connections between pages, so there's less need to rely on cloud services to reach each other. Users can use those connections for the sensitive data and use the cloud for the public content. The signalling services have to track meta-data, but Grimwire can be downloaded and run privately so that you can protect yourself and your friends. Making the Web a P2P platform is going to have some seismic effects in terms of flexibility. It'll mean you can spin up a new service just by opening a static JS app and broadcasting it on a relay. I'm very excited to see how dev communities leverage that.   Can you give an example or two of services you believe this framework is good for? The two first applications I wrote were chat and mail. There's really no limit on what you can do. Since the p2p messaging uses Ajax, choosing to implement something over WebRTC doesn't lock you into it. You can switch between the cloud and a peer by just toggling the URL. Grimwire's link-exchanging system is very semantic. It uses relation types and meta-data so you can describe an endpoint instead of hard-code your URLs. That matters a lot for letting users choose their software; you can query the links on the network and say, "here's X and here's Y - pick one." Think in terms of having an "Open file" dialog for the Web, where the Web now includes JS functions and Workers and peers. Now, what can you imagine doing with that? From a privacy perspective, anything you do on Facebook or GMail could be done better here. The messages don't traverse through their servers, so they can't scan them for advertisements or give them to government agencies. Messages flow directly when both users are online. Users are going to value having that option.   Backend. What technologies and architecture are you using there? Node.js and the file system. I might add redis as an optional backend, but grimwire is meant to be user-deployable so you can set up networks on LANs and get meaningful privacy. So it's built with a vertical scaling limit and just the one dependency, which is node.

This being limited to WebRTC, what kind of fallback do you offer on non-supporting browsers? The node.js server can carry any arbitrary payload in its signalling service. Until a session is established, the Ajax traffic uses this "bouncing" to communicate, and if the session fails to form it just continues to bounce. That was a late change since it requires more trust in the signal host, but the frustration we were having with random failures made it worthwhile.   Where do you see WebRTC going in 2-5 years? 2-5 years, I'd like to never use a cell-phone network again. By then, we should have good mobile Web devices like with Mozilla's platform, and should be able to run our own RTC networks and use Wifi and have a few fewer eyes on our metadata. I like to think the signaling will be universally federated, but that's more of a business issue than a technology one. The other thing I see happening is cloud services getting augmented with or supplanted by RTC, maybe with signal hosts and a few generic services (CouchDB, say) on raspberry pis plugged into home routers. Either way, I hope we'll be looking back on a lot of 3rd-party hosting, especially for personal content.   If you had one piece of advice for those thinking of adopting WebRTC, what would it be? Don't bother with audio/video. If you're not already a year into the project, you're a year behind a lot of existing entrants. It's also just not that interesting compared to the data. There's a lot of novelty to explore with P2P that we're just scratching the surface of, because it shifts so much control into the clients' hands.   Given the opportunity, what would you change in WebRTC? I'd add a signaling mechanism to the browser that serves the local tabs only, and maybe can broadcast within the LAN if that's possible. If you could connect tabs directly to each other without involving a remote service -- no broadcasting metadata -- it'd be safer.   What’s next for Grimwire? Next is polishing it up for users. The dashboard is getting rewritten to give people something fun to manage their services and their data with. Hopefully fun ends up being the right word to describe it. Then I plan to dive into the more experimental features like user-editable Workers and networked GUIs, which rely a lot on the security model. If they work out, then I'll start to make my web-based Emacs apps. Otherwise, I'll keep digging into P2P services and see what other cool stuff we can do. - The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.