This page expands on the basic ideas of this proposed friend-to-friend system Murmeli. If you have comments, or suggestions why it's a good or bad idea, please send them in by email.
We already have peer-to-peer networking applications, such as BitTorrent, Kazaa and others. They work on the idea that the individual clients are all equal and communicate with each other, rather than only dealing with a central server (or set of servers). This brings many advantages of scalability, redundancy and fault tolerance, and goes hand-in-hand with how the internet was originally designed. If my computer can talk directly to your computer, why should I send my messages to a central corporation's server, where it can be scanned, monitored, censored and archived?
Murmeli plans to take this a little further, to make a so-called "darknet" (see wikipedia), and more specifically a "friend-to-friend network" (F2F rather than P2P). However, unlike many of the current darknets where the focus is on finding and sharing files, without caring too much where or who they come from, Murmeli's focus will instead be on requesting any and all new information from known and trusted friends. Anonymity isn't a goal at all, quite the opposite. Messages should be demonstrably from a known friend (proved by digital signing), otherwise they'll be rejected.
So what happens if I want to send a message to someone who isn't online right now? That's ok, I can send the message to any of my friends who are online now and ask them to pass it on. Then when my intended recipient comes online, and I've gone, they can get the message from whoever is still online now. If I specify a maximum forwarding limit of 2 hops, then the message needn't traverse the whole network, just those with an indirect connection to me.
And what's to stop my other friends reading this message if they act unwittingly as a relay? Encryption. Each user of the program has a public key (which is public, given to everybody) and a private key, which they keep secret. So if I want to send a message to George, I take my message and encrypt it with George's public key. I send the message to Paul, but he can't read it because he can't decrypt it. Only when Paul forwards the message to George can George then use his private key to decrypt the message and read it. Paul can then delete his copy of the message of course.
In fact, Paul doesn't even need to know that I'm writing to George. Paul knows that the message is from me, because it's signed by me and he can verify that it's from someone he knows. But Paul can't decrypt the message, so the message can't be for Paul. Paul doesn't know who it's for, but can send it to everybody in his friends list (with a flag saying not to forward it any further), and just hope that somebody can decode it. Paul could save himself some bandwith by not sending it to anyone that I've already sent it to (or back to me) - this can be checked with a hashed message id.
If enough of this is transparent, it should be as easy to use as email, and all I see is that I've sent a message to George and all he sees is that he receives a message from me. Nobody else needs to be informed that messages are being exchanged because they're not readable by them. Even the encryption can be completely transparent to make it as easy as possible.
The above description sounds much like email, albeit with the extra security of encryption. And the lack of a server backup of course. Much of the "publishing" aspect comes then from sending such a message to multiple recipients, perhaps all your friends. This is done in exactly the same way, except that instead of one public key being used for encryption, several keys are used, one for each of the intended recipients.
This idea quickly runs into scalability problems. Let's say I want to send a 1 MB message to ten of my friends. If I have to encrypt the message individually for each recipient, that means I have 10 different copies of my 1 MB message to send. But I need to send all the messages to all of my friends so that they can act as relays, so suddenly I'm trying to upload 100 MB instead of 1 MB. If each of my friends then try to upload all these copies to each of their friends too, there is an awful lot of wasted bandwidth and storage.
A much better idea is to generate a random symmetric key with which to encrypt my 1 MB message. I send this encrypted message to all my friends, and in addition I encrypt this random key with each of the public keys of my recipients. This means that there's only one large file being passed around, and 10 different tiny files for the key.
So how is this proposed system any better than what we already have? Firstly it provides secure email. Of course it's possible to send email securely already, but people don't, and even if they do, the sender, recipient, timestamp and subject are all passed in plain text around the internet. So it's easy to log who is communicating with whom and how much and how often. With a decentralized system, it's much more difficult to track.
You also get the possibility of an individual "wall" containing personal updates, thumbnail pictures, status, news and everything that's going on in your life. You add items to your profile, specify who can see them, and your updates appear for them to view. You can have a screen showing all your friends and what they're up to, casually graze if anything new has happened, without the obligation to regularly write a long email to keep in touch. And then when you do want to send a quick message, you can respond either publicly or privately, with a short or a long reply as you wish.
So it has the advantage over email of a more broadcasting nature with casual browsing of published messages possible, together with higher security and privacy than regular email. And spammers won't be among your trusted friends, so they won't be able to send you any messages at all. It has the advantage over Facebook (and similar platforms) of total control over your personal data and confidence that the company won't stamp all over your agreed privacy terms. It has the advantage over Twitter of much more flexibility in terms of message type and maximum message length.
You also get no advertising, and no leakage of personal information to advertisers, developers of those silly games that your friends play (which leak your information back to the game's developers), and of course Facebook itself.
The big killer is popularity. It's the fax effect again, no communication platform is useful if noone's in it already. One of the big draws of Facebook is the fact that so many people are already there, which any new platform obviously doesn't have. This brings the important added function of finding people you'd lost contact with - with a new platform you have to find them first, then persuade them to join the new platform. Which sounds like a hurdle.
Second - who wants to install a new application? All the web-based social networks just need a browser, which everybody already has. Downloading and installing more software? Unlikely to be popular.
Another disadvantage is resource usage. Sending email is efficient because you only need to send one copy to your email server, which forwards it to the recipient's email server, and then at some time later, a copy is sent to the recipient. In contrast, Murmeli's proposed scheme involves potentially sending multiple copies of the message to several friends, asking them to send copies to their friends too, negotiating between peers which messages need to be exchanged and so on, just on the hope that sometime soon the recipient will be online at the same time as someone who has the message. Then it needs a mechanism for the peers to mark the message as expired after a certain time and recover the storage. It's not very efficient - but the longer clients spend online, the greater the chance that messages can be passed directly rather than via inefficient relaying.
There's also the issue of backups - there isn't the safety net of emails also being stored on a central server, because there isn't one. So some backup routine might be a good idea. But that brings up another problem - a central server is accessible from any web browser anywhere. If you have a central server, you can check in from home, from work (if they allow it), from your friend's house or an internet cafe on holiday or wherever you want, even from a mobile device like a smartphone. A decentral system such as Murmeli is only available where you have installed it, and even then only when it's been synchronized with your friends. So it's much more oriented towards a single, home-based access point. Which may also be a big problem for some people. If you wanted access from multiple devices, then you could have multiple installations with the same key pair (and hence the same identity), but they would have to be manually synchronised if they're not online at the same time.
Another idea is to install some kind of "personal relay" on a permanent server. This would be hopefully lightweight and low-maintenance, and would just sit there, holding the public keys of you and your friends. It wouldn't know any private keys though, so it would only be able to store and relay encrypted messages to and from you. For Murmeli clients which are only occasionally online, this would provide a useful mechanism for maintaining contact and storing messages. It wouldn't be a single point of failure though, as to you it's just another contact. If it fails, you've still got your other friends acting as relays too.
The prototype Murmeli code is already running on a Raspberry Pi, which provides a very low-cost, low-power option for this personal relay idea. I originally thought the relay would run on a separate server somewhere, but if it can run easily on the Pi underneath the television then that's a much easier solution for maintaining a relay which is available almost all the time.