A disclaimer: we are a bunch of software engineers, so what follows is a wild technical thought experiment. Bring your imagination and your architectural chops.
What would a decentralized Facebook look like? Well, users should be able to:
- Create a basic profile
- Maintain one or more lists of friends
- Share content with everyone on one or more of these lists
- Have shared content only accessible by people on the list it was shared with
- View content from all of their connections in one chronological “timeline”
- View content from another user without the other user knowing how many times they’ve viewed it (consider how important it is that you can see someone’s photo on Facebook without them knowing, surreptitious as it sounds)
How would it work? Let’s start with user profiles and content:
- Users can host their own profiles and content, or sign up with a service provider that hosts several users
- Users can create a basic profile, which includeAll Postss their name, date of birth, and other basic biographical data
- When they publish content, it is added to their personal timeline, and an event is shared with their connections notifying them of the new content
How do user connections and sharing work?
- Each user maintains one or more lists of connections – for example, they may have a “friends” list, and a separate “colleagues” list
- When they share content to a particular list, an event notification is shared with all the members on that list
- Sharing of events can use a polling model where users poll for new events from their connections
- alternatively, sharing can use a publish/subscribe mode – in this case, users can subscribe to one of their connection’s events so that events get published to them
How do users protect their content?
- When a user publishes content, it is given a unique ID, and is encrypted with a unique key for that piece of content
- The event notifications sent out for that content has a reference to the content’s unique ID
- The consuming application uses the content ID to ask the publisher for the symmetric key it can use to decrypt the content
- Once it has the symmetric key, the consuming user can access the content
- The publishing user may subsequently refuse to give out the key for a particular piece of content (revoking access)
What all gets protected?
- We protect the user’s profile information (portions of this are given unique IDs), as well as any content the users generate – this may include status updates, longform text, links, photos, location updates, etc.
- Users may opt to make any of their content accessible publicly – in this case, it does not get encrypted
Content mirroring, not racking up a view count
- The encrypted pieces of content, identified by unique IDs can be mirrored by public mirrors or private mirrors – since the data is encrypted, only those who obtain the proper symmetric key can decrypt the content
- Consumers can choose to access content directly from a publisher, or through a public mirror
- Public mirrors would be expected to not make view counts available on pieces of content
What are the potential weaknesses and exploits? Leave your thoughts as a comment