Deface, a decentralized Facebook

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

Cloud pricing is unfair

Is it fair to round the CPU usage of a virtual machine to the nearest hour when charging customers for cloud computing? We were curious about this so we thought we would ask the Internet. Of course, we wanted to get people’s opinions on cloud pricing overall so we asked about more than just the rounding of CPU use. We are not statisticians so the approach we took was rather simple, and took the form of an online survey. Our audience was a broad group of people involved in software, and included many independent developers, as well as those working as part of an organization.


When making the decision to go with a particular platform, by far the most important factors were the cost and quality of service. Surprisingly, brand name and trust was only somewhat important for many developers, especially those who were independent. The importance of brand name and trust was higher for those making the decision for teams and organizations.


The question we were most interested in was which pricing model was most appealing to users. The results showed that customers preferred to be charged a flat fee per month for a virtual machine – the Digital Ocean model. A similar model of paying a flat fee per month for a cloud application was also deemed fair. The most prevalent model used by AWS, Azure and many other providers of charging per unit of resource used was not particularly appealing when compared to the flat-fee approaches. Interestingly, those surveyed said that when their cloud applications exceeded a certain cost (when being charged per resource usage), they actually preferred if they were switched automatically to a flat-fee model for the remainder of the billing period instead of having their applications suspended. This seems to indicate that when it comes to pricing, users are finding being charged per unit of resource consumed complex and unpredictable. They strongly favor a pricing model that allows them to have a predictable cost per month.

Finally, to answer to the original question: is it fair to round to the nearest hour when charging users for CPU use? A most definite no.

While the results seem to indicate some solid opinions, I do want to point out that the survey is still open and if you have experience with cloud platforms and want to opine – follow the link below to our survey:

Opinions on cloud pricing