This page expands on the basic ideas of this proposed friend-to-friend system Murmur. If you have comments, or suggestions why it's a good or bad idea, please send them in by email.
As mentioned earlier, one major obstacle to setting up a new network, is that everyone's using the old one. Convenience is king, so how can those people be persuaded to switch to the new network and all the effort that that would entail? It sounds impossible if you want to switch everybody in one go. The answer is, you don't make them switch, you let them carry on using their existing network (or networks) and add Murmur to the mix. Here's one way how it might work, where Andrew and Brian use Facebook, and Charlie doesn't (or has left).
Stage 1 - aggregation and relaying. Charlie wants to keep in touch with Andrew and Brian, so persuades them to run Murmur. They continue using Facebook as usual, make their postings to Facebook as before, but now Murmur grabs the Facebook postings and lets Charlie see them too, because they've been encrypted and forwarded through Murmur. Andrew and Brian benefit by getting replies and postings from Charlie too, but they have to open Murmur to see these, as Charlie's messages don't get sent to Facebook.
The cost at this stage is mostly on Andrew and Brian, they have to install Murmur and set it up to run, and if they want to see what Charlie's up to they have to open Murmur too. However, if Murmur also functions as an aggregator, they also get the benefit of accessing their Facebook stuff and their Twitter stuff, Delicious stuff, maybe even RSS stuff, all from one view within Murmur. Charlie also has the cost of installing and setting up Murmur but has the benefit of keeping in touch with Andrew and Brian in a secure way, and not missing out on what they're posting in Facebook.
Stage 2 - expansion. Other friends also join Murmur, making the network richer and improving the performance (reducing latency). For sending personal, private messages, Murmur is now offering a convenient and encrypted messaging service which is then better and more convenient than either Facebook or email. Even Andrew and Brian can use it to securely message each other even though they're both on Facebook.
The new users joining have to install and get used to the new network, but everybody has the benefit of a better-performing network and secure encrypted messaging. All users have the cost of disk space and bandwidth from running Murmur.
Stage 3 - inversion. Instead of users posting to Facebook and then Murmur propagating the messages through secure channels, the tendency is to do the opposite: posting in Murmur and allowing Murmur to propagate the messages to Facebook. This allows a gradual shift from Facebook in the foreground to being an additional output of Murmur.
Stage 4 - migration. At some stage, Facebook will no longer be the coolest thing on the net, and its popularity will probably decrease at some stage. This happened to friendsreunited, to friendster, to myspace, to xing, to geocities, and countless other such networks - users are fickle and will at some point migrate. Maybe its place is taken by the next coolest site, but that doesn't matter as long as Murmur can interface to it. People can still go on using Murmur as it is and use it to aggregate their other stuff.
Sadly, at no stage in this process do you ever get the benefit that "Facebook no longer has your information". It will always have the information you've given it so far, even if you delete it. Even if you nuke your account, Facebook will not unlearn what you have told it about yourself. But anything you share with your friends through Murmur only goes to your trusted friends, and nobody else has access to it.
One of the many insightful blog comments coming out of these heated discussions is this one from "Professor Opinion" on Techcrunch - If you want to beat Facebook, you can't win by being a "distributed" (99.9% of people don't care), "open source" (99.9% of people don't care), "encrypted" (99.8% of people don't care) version of friggin' Facebook.
An excellent point. True, most people don't care whether the software they use is open source or not. Being "distributed" of course is a benefit (if people understand what distributed means and what the implications are), but given the huge number of Facebook users, probably not that important to most people. On the contrary, being centralized makes it a lot easier for people to use than a distributed system. And encryption? Well, encrypted email has been available for years but almost nobody uses it currently. Why not? Because it's just more convenient not to, and people don't see the benefit of encryption. Maybe this is changing now though, given all the current media coverage?
A case in point - Skype traffic is also encrypted, which is a benefit, but most people don't know or care whether it is or not. It's certainly not given as a reason why people switch to Skype, it's just an additional benefit.
So what kind of network is required for a tool like Murmur to be successful? Do you just need a large number of people to use it? No, of course not, what's important is the connections between those people. A Murmur network of just five people who all know each other is much much more useful than a network of 100 people who each only have one or two connections.
It's not just about how much traffic is exchanged either. With Murmur's model, (as opposed to the personal server model outlined in the introduction page), Murmur relies on the uptime of your regular computer. To exchange a message with one of your friends, either you and your friend must be online at the same time, or a mutual friend can act as a relay. Therefore the latency and efficiency of the communications depend greatly on your uptime, your friend's uptime, and the number of mutual friends you have.
This is an even more extreme case of the "fax effect" where the usefulness of the medium increases dramatically as the number of users increases. Except this time it's even more essential to encourage mutual friends to join so that each member benefits from the increased connectedness.