Hi Maciej,

I think you and Kuba are on to something.

A few times now, whenever I’ve remembered that Twitter could cut my startup off from their API whenever they feel like it, I’ve considered the challenges involved in just building a decentralized Twitter. But after reading your post it occurs to me I was thinking too small. Decentralizing the user data that powers all the social networks is far more interesting than decentralizing any single one.

One big question I have — and you probably omitted this on purpose — is where the social graph data would live. Would each application own it’s own social graph? Or would the social graph also be decentralized and be metadata next to userfeeds on the blockchain? There are cases to be made for both. If each application owns it’s own social graph, then it’s easier to have social networks for different types of media layered over userfeeds. You could have a “Twitter” where you follow the userfeeds you want to get short notifications from, an “Instagram” where you could follow the userfeeds whose pictures you want to see, a “YouTube” where you subscribe to the videos posted by various userfeeds, and so forth. However, the downside of doing it this way is that the switching costs between networks are still high. If you want to switch between two versions of “Twitter”, you would have to re-follow all the same userfeeds. This would work against the central thesis of your proposal — that applications should be forced to compete in terms of user experience and not monopolize data. Perhaps there could also be a way to build the idea of “following” into the protocol for userfeeds, but allow the user to decide what kinds of media they want to follow from each userfeed? Then any media-specific applications, that arose from this protocol would need only make their “following” user interactions correspond to a user “following” that type of media from the userfeed. For example, if you hit subscribe on “YouTube1”, then switch to “YouTube2”, you would still be able to access all the accounts you’ve subscribed to, because your video-type userfeed subscriptions live on the blockchain, and not in either YouTube application.

The risk in making the underlying data too open though, is that the application developers won’t have enough of a financial incentive (due to the lack of ability to monopolize) to build very interesting applications, and thus the entire userfeeds application ecosystem may not be able to compete with the existing centralized social networks.

I think userfeeds could also have potential for journalists. What is a news publisher’s website or app but a collection of journalists’ userfeeds, with some human editorial input for ranking and a fancy UI? By employing journalists, publications are essentially buying the exclusive rights to market any content the journalists create and sell advertising against it. But this system is a result of readers following publications over individual journalists. If the contributions of individual journalists are valuable enough, and doing so is easy enough, then readers may start following the journalists directly. And if advertising is built into the protocol, those journalists could have their own way of earning revenue, which would allow them to maintain their independence. Or, if there is some way for journalists to license their content (like the advertising protocol but in reverse? — we pay you, not to put our content on your feed, but to buy your content for ours) to publications with superior distribution channels, that could be another path to revenue and independence.

One of the major challenges I could see you and Kuba facing in developing this is that unless you already have the killer app for a decentralized network, you don’t have very much financial incentive to build the network yourself. The path that OpenBazaar is taking, for example, seems to be to first build the network through a community-driven open source effort, but then also get a head start on building the applications that will form the core of their business. The head start is important because the OpenBazaar network is open and anyone else can compete with their applications. The nature of decentralized networks makes it difficult for any single entity to extract value from them, which is kind of the point (though not everything is about money; it could be great fun to decentralize a few network monopolies).

I’m sure there is some kind of solution to this. Perhaps application developers could share the cost of the network? You would think that rational self-interest on the part of application developers would compel them to support the protocol layer, similar to how Mozilla, Google, Microsoft, Apple and Oracle all push web standards forward and implement them in their own browsers. But the risk is a tragedy of the commons scenario where all application developers wait for someone else to do it…

I really like where you’re taking this. I’ve been thinking about blockchain potential for decentralizing networks for some time and yours is the most coherent writing I’ve found on it. I think the technological issues are going to be hard, but the governance issues — aligning incentives between the protocol, developers, and users — may be even harder. I’m looking forward to reading more of your thoughts on this and I’m also always happy to brainstorm on the subject if you guys want.

P.S. The irony of discussing this on Medium isn’t lost on me :)

CEO at @SpankChain , Summoner of @MolochDAO , ConsenSys Alum

CEO at @SpankChain , Summoner of @MolochDAO , ConsenSys Alum