Considerations regarding a p2p social network

While the are many social networks in the wild, most rely on data stored on a central site owned by a third party.

I'd like to build a solution, where data remains local on member's systems. Think of the project as an address book, which automagically updates contact's data as soon a a contact changes its coordinates. This base idea might get extended later on...

Updates will be transferred using public/private key cryptograph开发者_运维百科y using a central host. The sole role of the host is to be a store and forward intermediate. Private keys remain private on each member's system.

If two client are both online and a p2p connection could be established, the clients could transfer data telegrams without the central host.

Thus, sender and receiver will be the only parties which are able create authentic messages.

Questions:

• Do exist certain protocols which I should adopt?
• Are there any security concerns I should keep in mind?
• Do exist certain services which should be integrated or used somehow?

More technically:

• Use e.g. Amazon or Google provided services?
• Or better use a raw web-server? If yes: Why?
• Which algorithm and key length should be used?

UPDATE-1

I googled my own question title and found this academic project developed 2008/09: http://www.lifesocial.org/.

The solution you are describing sounds remarkably like email, with encrypted messages as the payload, and an application rather than a human being creating the messages.

It doesn't really sound like "p2p" - in most P2P protocols, the only requirement for central servers is discovery - you're using store & forward.

As a quick proof of concept, I'd set up an email server, and build an application that sends emails to addresses registered on that server, encrypted using PGP - the tooling and libraries are available, so you should be able to get that up and running in days, rather than weeks. In my experience, building a throw-away PoC for this kind of question is a great way of sifting out the nugget of my idea.

The second issue is that the nature of a social network is that it's a network. Your design may require you to store more than the data of the two direct contacts - you may also have to store their friends, or at least the public interactions those friends have had.

This may not be part of your plan, but if it is, you need to think it through early on - you may end up having to transmit the entire social graph to each participant for local storage, which creates a scalability problem....

The paper about Safebook might be interesting for you. Also you could take a look at other distributed OSN and see what they are doing.

None of the federated networks mentioned on http://en.wikipedia.org/wiki/Distributed_social_network is actually distributed. What Stefan intends to do is indeed new and was only explored by some proprietary folks.

I've been thinking about the same concept for the last two years. I've finally decided to give it a try using Python.

I've spent the better part of last night and this morning writing a sockets communication script & server. I also plan to remove the central server from the equation as it's just plain cumbersome and there's no point to it when all the members could keep copies of their friend's keys.

Each profile could be accessed via a hashed string of someone's public key. My social network relies on nodes and pods. Pods are computers which have their ports open to the network. They help with relaying traffic as most firewalls block incoming socket requests. Nodes store information and share it with other nodes. Each node will get a directory of active pods which may be used to relay their traffic.

The PeerSoN project looks like something you might be interested in: http://www.peerson.net/index.shtml

They have done a lot of research and the papers are available on their site.

Some thoughts about it:

• protocols to use: you could think exactly on P2P programs and their design
• security concerns: privacy. Take a great care to not open doors: a whole system can get compromised 'cause you have opened some door.
• services: you could integrate with the regular social networks through their APIs

People will have to install a program in their computers and remeber to open it everytime, like any P2P client. Leaving everything on a web-server has a smaller footprint / necessity of user action.

Somehow you'll need a centralized server to manage the searches. You can't just broadcast the internet to find friends. Or you'll have to rely uppon email requests to add somenone, and to do that you'll need to know the email in advance.

The fewer friends /contacts use your program, the fewer ones will want to use it, since it won't have contact information available.

I see that your server will be a store and forward, so the update problem is solved.