This page is a discussion of ideas for a possible, perhaps useful, bit of software, but it has not been written, it's just a discussion for now. There are a lot of issues to solve for this to ever come to fruition, even if it is a good idea (which it might not be). If you have comments, or suggestions why it's a good or bad idea, please send them in by email.
Note: since these pages were written, it has come to my attention that there are already not one but two pieces of software called Murmur. one is apparently a "PyGTK2 client for Museekd" (whatever that is), and the other is a "server component for Mumble" (whatever that is). This page is not about either of those, it's about a completely different (and in fact not-yet-existing) piece of software. If it ever happens, clearly it'll need a new name, but Murmur nicely implies communication that can't be understood by others. |
Firstly, let's look at why "social" sites like Facebook and Twitter have become so explosively popular. Of course, everybody likes to communicate, but before those particular platforms took off, people already had plenty of media with which to talk to one another. There was already email of course, and instant messaging, and forums, and IRC, and voice over IP, and people could write blogs if they wanted, and each of those mechanisms were useful and relevant for their own purposes. So what has driven so many people to open up yet another communication channel?
One theory is that people's attention spans are shortening, and it just takes too long to write a personal, individual email now. Who has that kind of time? Far easier to write one short message on your public "wall" so that everybody can read it if they want. Then aggregate all your friend's short messages into one easy-to-summarize view, and you can get updates from people who you wouldn't normally go to the trouble of keeping in regular email contact with. It's much more casual, just graze what's going on with the people you know. Then, allow quick feedback and responses, allow email-like individual communication too, but the ease with which one can "broadcast" your information to many people is clearly attractive.
Okay so far, so what's the catch? Well, some critics say that these central platforms exert too much power over the information being exchanged. Is it ok if the platforms sell your personal data for a profit? Is it ok if they change their privacy policies to allow more of your details to be accessed? Where do you draw the line, where the cost of having all your data owned by one company outweighs the benefits you get from their services?
What if it were possible to exchange information and messages with your friends, without any one company being in control? What if it could be designed so that nobody else could read your messages or your details without you allowing it? That would put you back in control of your own data again.
What kind of information could that be? Anything really, it could be short messages intended for all your friends to read, long personal messages just for one individual, photographs of you on holiday, suggestions for movie night, cookie recipes, even short status updates with less than 140 characters. For each message, you would be able to determine exactly who should be able to read it, from one single contact, to a selection of contacts or possibly groups of contacts.
There are some outlines of the mechanisms in the basic ideas page, and also some overviews of existing projects which are related in some way. This is followed by some more ideas governing transitions and message passing, and some recent impetus from news events, stimulating more thoughts on the project.
A simple diagram to visualize the connections is shown below. The Facebook model is shown on the left, where the corporation (who is interested only in profit) owns and controls the data, and allows access to various people including your friends. Murmur's proposed model is shown in the centre, where the users contact each other directly, and pass information in encrypted form to each other as they wish.
On the right of this diagram is another proposed model, using a server for each user. Each user is then responsible for the maintenance of their own personal server, and the servers exchange information with each other. This alternative model would give benefits of continuous connectivity between servers and access from multiple clients, but gives each user a significant burden of obtaining and setting up their own additional server. This is the chosen model for Diaspora and Appleseed, among other networks.