Decentralized social network
Social networking online is not the same as social networking in real life. Online social networking consists of many users creating profiles and storing their data on a dedicated server. A user does not have to be online for other people to see their profile or send messages to them. It is very convenient this way because users can always be connected so long as they have an internet connection.
Real life social networking is different. In real life, people would gather at a place; such as a cafe or bar, and if you wanted to talk to somebody you would have to walk up to them and speak face to face. Both parties must be at the same location in order to cooperatively communicate.
Even though social networking online is convenient, users are required to give up their privacy. Users must be willing to trust their data being stored on a remote server and they must trust that their profile is not being viewed by anyone they don’t want to share information with. Real life social networking, though not as convenient as online, gives people full control of who they communicate with and what information they share.
The inherent design of the internet encourages the current model of online, centralized social networks because of the client-server model. It is too risky for all users to trust their personal information to one online service. That service could fail or become corrupt.
Users should be able to communicate with each other but their data should not be stored on the cloud. Each user’s data should be stored on their own machine respectively. And any communication should be engaged in full cooperation: no stalking, lurking, or spying.
A peer to peer connection is preferred for such a social network. This means that users will be connected directly to each other and the data they exchange will not pass between a central server. How can this be possible without the clients setting up a server themselves and port forwarding? I believe the answer lies in a technique known as TCP hole punching. An article called “Peer-to-Peer Communication Across Network Address Translators” discusses the technical details of how TCP hole punching works in order to establish a direct connection between two clients. Step by step, this is what will happen (all happening on the same software port):
* Client A sets up a listening socket
* Client A connects to Server S
* Client A sends it’s private address to Server S
* Client B sets up a listening socket
* Client B connects to Server S
* Client B sends it’s private address to Server S
* Client A asks Server S to connect to Client B
* Server S sends the public and private addresses of Client B to Client A
* Server S sends the public and private addresses of Client A to Client B
* Client A tries to connect to both addresses of Client B
* Client B tries to connect to both addresses of Client A
* Once a connection is established, both clients would then be able to communicate autonomously.
Using this method, a decentralized social network could be established where users could rendezvous at a server but their communication would be direct and private. The server would simply display some welcome message or news and have a list of users to connect to. Various server nodes could be set up to cater to certain audiences or hobbies. Nodes could even be set up to represent real places, much like how GeoCities operated. A node may even be set up on a private network and users on that network could have their own local social network without ever having internet access. Users with smart mobile devices could have their own social network in one room or building. File sharing would be direct and free from eavesdropping or data modification.