Decentralized social network wanted
People are getting more concerned with the safety of their personal data
stored at the social network service provider. Many privacy issues such as
private files leakage, manipulation of personal data without permission,
communication censorship have challenged the centralized architecture of
social network. The desire for an architecture where personal data are no
longer concentrated at a central server motivates the development of
decentralized social networks. Diaspora takes the first step by breaking the
centralized server down to a series of regional servers (
pods). A user
registers at a pod that receives and delivers the messages for him. However,
the problem is "what if the user does not trust the pod?". More seriously,
users data at the pod are in plaintext, subject to easier access after attack.
Diaspora does provide an option with higher privacy protection: you can set up your own pod that only serves yourself. If every user applies their own pod, the decentralized social network could have been achieved. Unfortunately, this has never come true. The convoluted installation procedure intimidates most users. This is also true in mainstream P2P platforms such as Freenet, Herbivore, and Kaleidoscope. Normal users can hardly install and maintain these platforms without any technical support. This is the story five to ten years ago. But can we do it now?
With today's advanced platform-neutral, web-based technologies, can we provide the same level of usability in popular social network such as Facebook with enhanced privacy protection? One notable advantage comes from the browser. We believe the current built-in features in browsers are able to accommodate a peer-to-peer network: much more than a simple client-side renderer, nowadays we have WebRTC that enables inter-browser peer-to-peer data channels, and indexed DB that provides persistency as key-value store.
Design of an in-browser social network
Only having P2P data channel and in-browser persistency is far from an operatable social network. We need to design a client-side only logic that is able to orchestrate the social network without a centralized entity. Specifically, we need at least the following three schemes: - A secure signaling and friendship exchange service for the peer-to-peer network that offers both data security & privacy and high deploying scalability. - A mechanism to ensure timeline consistency of posts between sender and receiver without any centralized authority. - An efficient message delivery overlay network that delivers messages to both online and offline friends with low latency.
The Signaling And Friendship Exchange (SAFE) service facilitates peers to exchange friendship requests for establishing shared secrecy, and also exchange network brokering information including metadata, IP address and port number. As SAFE service only provides a platform for peers to exchange information, this service can be hosted in a simple key-value store. Each piece of exchanged data is formatted as a typical json with the key to be only computable and identifiable to the pair of friends. SAFE has no disclose to any user's communication data, friends info, and even the ID. The design of SAFE plays a key role to deliver a private social network.
Timeline consistency of messages is resolved by the receiver proactively. When the messages are sent and the receiver is offline, they are maintained in the DHT for a while using replication and persistence. However, after the message time-to-live expires, the message is deleted from the DHT. If the receiver comes online after the messages have been permanently removed from the DHT, then the receiver cannot access them. However, if the sender sends a new message which has message identifier higher than the identifier of the last successfully recieved message, then the reciever detects this gap and requests for the missing messages. In that case, the sender once again introduces these messages in the DHT.
Post delivery overlay network
As a baseline post delivery design, flooding sync tries to propagate posts to as many friends (and friends of friends) as possible. So the chance for a peer to receive her missed posts from a friend when coming back online is increased. DHT based sync exploits the chance of synchronization from other online users than one's friends.
Prototype and preliminary evaluation
We evalute the performance of flooding sync by simulating users with Webdriver. The simulated users login and logout the service periodically. The post arrival latency and the storage overhead of every online activity is recorded. The result of latency and storage overhead is plotted in the following.
The SAFE store performance is measured with two metrics: throughput and capacity. From the real experiment, the result shows that with a single instance of redis, SAFE can process 1,401 login requests per second, 2,307, 4,549, 5,818, and 6,620 as the number of sharding increses in double, respectively. From the result of storing 192,000 records, experiment shows that a each login request consumes 51K bytes. Assuming 64GB of RAM for the SAFE server, a single instance could store upto 1.34 million users.
One might think that replacing Facebook is a pipe dream, but we will take a bold first step to replace a chatting service for closed groups like a web-based IRC. Stay tuned.