Change Facebook to a Peer-to-Peer architecture

         Please send any feedback to me.

Motivation section
New Architecture section
Notes section


With revelations of NSA spying, many people feel any central-server service is bad: it provides a single place, out of the user's control, where all of user's info can be grabbed (legally or illegally, by hacker or corporation or law enforcement or NSA) and all of user's activity can be monitored in real-time.

Distributed, peer-to-peer systems reduce this problem: a user's data can be stored in a place under that user's control, or spread across the system, and there is no one place where N users can be monitored.

The following is a proposed way Facebook Corp could change the Facebook system to a distributed, peer-to-peer architecture.

Anticipated criticisms:

New Architecture:

  1. Facebook Corp owns and runs a couple of central servers:

  2. Any number of companies run Content Servers, storing encrypted Facebook data: Each item has an encrypted owner-Credential / itemID pair associated with it. If someone wants to edit or delete the item, they have to present the encrypted pair to authorize the request. Anyone can read the encrypted items from the server by presenting the itemID, but can't read the encrypted Credential/itemID pairs.

  3. There is a layer of Anonymizers, which prevent the servers from knowing locations or IDs of user machines. Anyone can run an Anonymizer. They just pass requests and responses back and forth.

  4. Each user will run their own little Facebook service and Facebook database on their machine.

    The database contains the user's info: This data is not known to anyone else or stored anywhere else.

    A single machine could run the services and databases for multiple users (such as in a family) and for multiple Groups.

    How does a user use Facebook if they are not at their home machine, and their home machine is shut down ? They can't. (Unless they take their database with them, on a thumb-drive. And if the home machine IS running, they could access the database across the internet.)

    For people who don't want to run a local service on their machine, or leave their home machine running while they are traveling, hosting services could offer to run services for many users. But this eliminates most of the privacy gain. At least it would spread the total data across many companies, not have it solely in Facebook Corp.

  5. Keep the standard web-based Facebook UI. Just have it connect to the local service. It must not connect to the other servers. The local service will connect through Anonymizers to the other servers.

  6. When user creates a new Post or Comment or Photo, a notification is sent to every one of user's Friends.

    Sending may fail, if the Friend is offline. Notifications may be batched together and sent after some delay, to avoid too much traffic.

    The notification includes a unique key T1 (single-key symmetric encryption) needed to decrypt the contents of the Post or Comment etc, as well as the Content Server ID and item ID needed to retrieve the item.

  7. When user boots up their machine and starts up their peer service, the service must ask all Friends and Groups if there are any new Posts or Comments, any new Notifications, any new Photo's, etc.

  8. Any time a user reads a Thread from a Content Server, the CS contacts the Ad Server to fetch an ad to return with the Thread data.

    Some amount of user-specific and context-specific information will be sent with each ad request, to allow the ads to be targeted. The UserID or User Credential will not be sent; the information will be something like "user is white male 50-60 years old, location is ZIP code 94086, context keywords are Tea Party destroy government".

    The ad must not contain any "active" content, anything that would make the user's browser contact another machine as it renders the ad. If it did, someone could use that to figure out which user machine is accessing which Threads or other items.

    It is okay for an ad to contain links which the user may choose to click on. The links should not contain any info identifying the Thread or the User, unless the user consents.

  9. Applications could be run on central servers, with some user-specific or context-specific information sent to them. Or they could be run locally, on the user's machine ?

  10. Each User has a public key (stored in the ID Server), and a private key (stored in the database on the User machine).

    If a user U1 wants to create a new Thread, they pick one of their 100 credentials at random, generate a new Thread-specific key T1 (single-key symmetric encryption), save both, and send this to a Content Server:
    (Encrypted with CS's public key:)
    • "New Thread" command code,
    • Thread owner Credential,
    • Keywords related to post content (for ad targeting purposes),
    • Text/links of the post content (encrypted with T1).
    • List of Comments (empty):
      • Comment owner Credential,
      • Keywords related to comment content (for ad targeting purposes),
      • Text/links of the comment content (encrypted with T1).
    Thread-specific key T1 is saved in the User's database, not sent to Content Server. Content Server returns a new Thread ID when the operation is complete. When User notifies Friends of the new Thread, the notification contains the Content Server ID, Thread ID and key T1, so the Friends can retrieve and decrypt the content.

    To read the Thread, user U2 generates a one-time key X1 and sends this command to the Content Server:
    (Encrypted with CS's public key:)
    • "Read Thread" command code,
    • Thread ID,
    • General data related to user U2 (for ad targeting purposes).
    • Key to use to encrypt the response: X1.
    Response from Content Server to user U2:
    (Encrypted with key X1)
    • Text/links of the post content (encrypted with T1).
    • List of Comments:
      • Text/links of the comment content (encrypted with T1).

    To edit a Comment owned by U3 in the Thread, user U3 sends this command to the Content Server:
    (Encrypted with CS's public key:)
    • "Edit Comment" command code,
    • Thread ID,
    • Comment number within Thread.
    • Comment owner's Credential,
    • Text/links of the new comment content (encrypted with T1).


Last update: November 2013.

Bookmark and Share

Home       Site Map

Privacy policy