shrughes

For the past four years, I’ve been asking myself, “Why aren’t you working on making a p2p cloud social network thing instead of letting users’ information be in the control of humongous corporations?”  Well, why aren’t I?  Hmm.  Well, anyway, here are what I view as the components to a nice p2p cloud.  Please be charitable and realize that I’m writing this from a position of complete ignorance of a lot of things.

A Source of Personal Identity

One major reason Facebook is scary is that it wants the ability to control your ability to log in to other sites.  You can log in with Facebook connect!  This gives Facebook control over your ability to log in.  It tells Facebook what sites you’re visiting.  It tells other sites about your use of Facebook.  We’d like logging in to be easy, and we’d like it not to happen through Facebook connect, or some similar feature under the control of some other group of shareholders.

A solution might be an “auto-login” feature built into web browsers, and built into the language of the web.  (If this is in HTML 5, I wouldn’t know, and I’m sorry if my ignorance makes you feel that you’re wasting your time reading the blog of somebody who is suddenly ashamed of how ignorant he is of an important upcoming standard.)  If browsers had the ability to say, “Submit user account info,” and submit the information needed to set up a user account in a regular fashion, with a profile picture, a username, and a human name, that would be nice.  It would also be nice if a user could then supply proof that they’re such-and-such user on another site.

Client-side Scriptability

We’d like to be able to safely run programs on client computers.  The web has this with Javascript.  If clients could open requests to things other than the originating web server, that would be nice, too.  If we could open up background apps and have them run in the background, that would be nice.  Having a language that is faster than Basically, we’d need Javascript, but with more power.  There are, of course, issues with this — we don’t want folks to be able to send viruses around.  Yeah, there are issues to figure out.  Anyway, this is a nature of the p2p cloud that web browsers have partially implemented.  I need to study my HTML 5.

Firewall Busting

We need some Skype-like thing that lets clients connect to one another by punching through firewalls.  Essentially, we need some kind of “Magic Socket Service,” that figures out some way to route data from one client to another.  You might also need some way to identify which peer you’d want to talk to, which we might have talked about above.  We might also need some flexible, adaptive ways of pretending to communicate under the pretense of existing protocols, depending on how firewalls are these days and in the future.

A Lookup Table

A p2p cloud would need a lookup table.  You’d need a mechanism for “pointing at resources.”  It would be nice if the elements of the table were immutable.  Take Tahoe-LAFS or some similar thing, minus any pretense of encryption, and that would be part of the deal.  Of course, an http URL is a valid thing that can be looked up.  Do you the person controlling the http server to be able to modify the contents of the value there?  Maybe you want some kind of “http url plus a series of hashes of successive prefixes of the content attached,” so that clients can try the server first, but then fall back to the peer-to-peer lookup table.

A Way to Transfer Personal Identity Between Computers

One problem with making a secure version of Dropbox (secure in the Tarsnap sense) is that you need a way for multiple computers to access the same data.  You need two computers to be able to securely say, “I am the same John Smith.”   Generally speaking, this can either be done by having some central service that controls your identity, where you log in using a password, or it can be done by moving secret keys (or whatever) through the sneakernet.  You can’t just email the secret keys or send them on some TLS socket without trusting some central authority.  Maybe you can verify key fingerprints, or something, I’m not a pro cryptography engineer, but whatever you do, to actually be secure about this would require some knowledge and self-protection on the user’s behalf.

And remember that client computers are generally much more insecure than some central server.  Who do you trust more to manage your grandma’s ability to log in to places: Facebook, or your grandma’s computer?  Unless your grandma doesn’t download any malware and uses a perfectly secure operating system, I’d say the probability of grandma having her credentials stolen is way higher than the probability of Facebook being evil about your ability to log in to places.  Of course, the malware could grab granny’s Facebook credentials anyway.  What can you do?

So, let’s put security aside.  We need some way to transfer identity between computers.  Maybe, for some users, that involves being ultra-paranoid and walking flash drives around.  And for other users, they can just type a password.

The Synchronization of State Between Computers

Along with personal identity comes the need to copy other information.  For example, recently I’ve been working on an iPhone Hacker News reader that keeps track of which posts you’ve read and highlights unread posts.  The one problem with that app is that, once you get home, you do your browsing on your regular computer, and any browsing you do on the different devices is unknown to one another.  We need some way for the state of the app to be shared, so that you get a smooth experience across computers.  One way is for the centralized server to have the feature of keeping track of unread posts.  Some forums have this feature.  Since we’re generally working in a decentralized environment, however, we don’t have that option.  We’d like applications to be written to live on multiple devices, to have little sense of an individual computer.  And we’d like to do it seamlessly.  Hahahahaha!  I bet there are some old codgers laughing at my naivety for suggesting that this could ever be done without creating an overcomplicated disaster.  Anyway, this sharing mechanism might be done over the lookup table mentioned above, or it might be done through a more optimized mechanism.  Or maybe it’s just the case the lookup table has features built in that makes it efficient for computers to find other computers interested in the same information, instead of being a completely dumb key-value store.  It really depends on how you define the boundaries between different things.

So maybe we want something fancier than a mere lookup table.

A Standard Library of p2p Social Networking Interfaces

If you have stuff like this, you could implement a peer-to-peer social network.  So we’d want a set of standard interfaces, for doing common ways of sharing information.  We’d want a standard way to represent data structures amid the p2p lookup table, and we’d want standard ways for updating and mutating values, and a whole bunch of other fun stuff.  But then, some applications might have problems of synchronization and maintaining coherent state.

So maybe we want something fancier than a mere lookup table.

An Anonymity Network

I don’t think the p2p cloud would be an anonymity network, but it would be nice if you could be anonymous.  Or at least somewhat anonymous.

So.

So you’ll notice that these features don’t need to be intertwined into one magic platform.  Really, if you just added these features one-by-one, you’d find a good improvement to the state of the web.  And, you know, a lot of these exist already, in some form or another.

Update! Fib has told me to read cortesi and DesktopCouch and told me the post is 100% fluff and reads as “you know what would be awesome” and “I haven’t done any research at all.”  All of that is correct, obviously.

For a while I was thinking about how I was going to display comments for my little HN newsreader, while having convenience and support for the things I want to make convenient. But what a fool I am! Why not do the following:

1. Create a new NSURLProtocol with the prefix “hn:” whose responses get passed through a content-annotating proxy.
2. Point a UIWebView at <hn://news.ycombinator.com/>. Note the scheme.

Done!

And now the problem is reduced to something I’m comfortable with: manipulating streams of bytes :-)