Table Of ContentDecentralize Social Media
by Ross Ulbricht
Centralization of social media networks has led to a host of problems for social media platforms
and their users. These include privacy breaches and the impossible task of moderating the
content of billions of users.
Below I describe a decentralized social protocol (DSP) that can help solve or mitigate these
problems by giving users control over their own content and putting them in charge of value
creation and transfer within their networks. This is made possible by allowing users to choose
from a multitude of interface providers, content servers and advertisers, rather than a single
platform that monopolizes these essential roles. I describe decentralized solutions to profile
management, privacy, hosting, user interfaces, ad networks, content filters, metadata and more.
In short, all the essential components of social media.
Decentralize Everything
It goes without saying, but one of the primary design principles of a decentralized protocol is
decentralization. However, the tendency toward centralization is powerful. Centers will form
whenever possible, and it takes foresight to predict where they will take root and grow.
Take the TCP/IP and HTTP protocols widely used on the Internet. When they were adopted,
they appeared to be totally decentralized. Anyone could set up a website and anyone could access
it. An internet connection and IP address were the only barriers to entry. What could be more
egalitarian? We saw with the early web the kind of flourishing we would expect from such an
environment. However, no one foresaw the dominant role the network effect would play.
Today, it doesn’t matter that anyone can set up a website that competes with Facebook,
YouTube, Reddit or Twitter. No one will use it. It could have better privacy protections, better
features and no ads, but it won’t have the one thing giving these tech giants an insurmountable
advantage: other users. Even when Google, with its massive preexisting user base, tried to
compete with Facebook by making Google+, it eventually failed after 7 years and billions of
dollars spent.
1
Under TCP/IP and HTTP, decentralization stopped at the URL. Whoever controls the URL
controls everything behind it. The result has been that URLs (facebook.com, google.com,
amazon.com, etc.) have become some of the most powerful and valuable corporations on the
planet. Under DSP, we must go further.
In a social setting, the smallest, irreducible unit is the individual, the user. So when we talk about
decentralization, we are talking about putting all the decision-making power and authority in the
hands of the users. Giving them the power to build websites and choose which ones to visit is no
longer enough.
Because centralization will develop wherever it can, DSP designers and developers must do
everything possible to discourage it. Unfortunately, that takes imagination and effort. It is far
easier to stop short of full decentralization, to leave the really difficult parts to others or to fill in
the gap with your own centralized platform. The tech giants are already partially decentralized.
They do not generate content. That is left to the users. DSP must take the features they have
centralized and design a system that decentralizes those too.
Who Controls the Content?
Information is fundamentally different from physical property. It can be duplicated at essentially
no cost, so when one talks about “owning” data, it can be confusing. Copyright laws exist to
combat this abundance intrinsic to information, to prevent copies of copies (for the benefit of the
content creator). So do laws about classification and secrecy which punish people for sharing
information they have agreed not to. However, these laws are undermined by peer-to-peer file
sharing in the case of copyright and by whistleblowers in the case of secrecy. It is difficult to
contain and control information.
In a decentralized system, a central authority cannot be relied on to enforce such laws, so we
have to deal with information on its terms. Rather than talking about who owns a user’s content,
we should be asking who has the right to access their content. The default position of modern
social media platforms is that the platform owns the content and centrally enforces access rights.
Under DSP, the content creator (the user) should control access with an encryption scheme
involving key sharing. Wherever possible (ideally as a rule), service providers should not have
access to unencrypted user content. Only those whom the creator has granted access should have
it.
2
Encryption places control squarely in the hands of the keyholders, so the location where the
encryption keys in DSP are kept will be a guide for us as we look for where centralization can
take hold. As much as possible (ideally as a rule), keys must reside with the users. All
information, whether stored or in transit, should be encrypted by default, unless specifically
created for the public.
This is a radical shift from the current paradigm. With users in control of their own data, the
network effect loses the only leg it had to stand on. If the content and associations that make up
the various social networks are managed at the protocol level, websites lose their monopolies
over their users.
Once again (as with the early web) anyone will be able to set up a competing website or app. Only
this time, instead of being empty, users will see all of their content and others’ content they have
access to. There will be minimal switching costs for the user because the new website will just be
a new interface to the same content. Such an environment will lead to a flourishing of
innovation, expanding users’ options and improving every aspect of their experience.
Money Matters
Social media platforms bring in tens of billions of dollars in revenue every year. This revenue is
generated almost exclusively by ad placement. It would be easy to ignore the issue of money and
let DSP service providers invent their own business models and hope that, given users’ low
switching costs, providers will behave and cater to the users’ demands. However, this was the
assumption built into the protocols that led to where we find ourselves today.
The fact we have to contend with is that money is a key element in centralization. Users bring
advertisers, advertisers bring money, money pays for expansion and development of the service,
and a better service brings yet more users. Money is essential to this feedback loop that draws
everyone to the same service provider, whose real business is that of matching eyeballs to
advertisements
It may be the most challenging part of DSP to design, but it is arguably the most important.
Somehow, the users must be at the center of this process of value creation and transfer. Given
that user attention is the source of value in the system, the problem should not be
insurmountable.
3
Restructuring Social Media
With the above design principles in mind, let’s look at the relationships between the stakeholders
in modern social media platforms and how those relationships should be restructured under
DSP.
Figure 1 depicts the four components that make up the current platform-centric paradigm. There
are three stakeholders: the platform (red), advertisers (greed) and users (blue). Everything
passes through the platform. The platform owns and centrally controls the content server. It
stores the content generated by its users through its interface and pulls from that content for
display. Crucially, the platform sits between the users and the advertisers. Advertisers pay the
platform to display ads to the users which generates clicks for the advertisers. Under this
structure, the platform holds all the keys. It controls all the value generated by the system.
4
Under DSP, the system must be user-centric. As seen in Figure 2, the user sits between the other
three stakeholders: interface providers, content servers and advertisers. Instead of a platform
wedged between the users and advertisers, advertisers pay users directly by bidding for ad
placement on their interface. Interface providers and content servers then compete for this ad
revenue. Instead of a monolithic platform providing the interface, many interface providers can
offer their services to users. And instead of the platform owning and controlling all content,
content servers compete to host the user’s encrypted content. Under DSP, the user holds all the
keys and controls all the value generated by the system.
This user-centric paradigm requires a rethinking of how online services are designed and built.
Current platforms can be conceptualized in three parts: the content, the user interface and what
is sometimes referred to as “business logic.” Business logic is all the instructions the platform
uses to gather relevant content and send it to the user interface to be displayed. This is where
algorithms for searching, sorting and manipulating content live. Recommendation engines,
aggregators and various forms of AI are all business logic.
5
Figure 3 shows a simplified version of how content is delivered to the user by current, centralized
platforms. The user makes a request through the user interface which passes the request to the
business logic server (steps 1 and 2). That server determines what content is needed and gets it
from the content server (steps 3 and 4). The content is then prepared for display and sent to the
user interface which displays it to the user (steps 5 and 6). The business logic and content
servers are controlled by the platform and run on the platforms’s computers while the user
interface (e.g, a browser or app) is run on the user’s computer.
Under DSP, because the interface providers do not have access to the content, they cannot
execute business logic themselves. This must be done on the user’s side by what is called a “user
client.” The user client is just an app or browser plug-in that can execute business logic and
manage the user’s profiles and wallet. The function of the interface provider then is simply to
send business logic to the user client, instructing it to gather content and compile it for display
through the user interface.
6
Figure 4 shows how this is done. Again, the user makes a request through the user interface
which gets passed to the interface provider’s business logic server (step 1 and 2). The interface
provider then sends the appropriate business logic to the user client back on the user’s side (step
3). The user client executes the business logic — gathering content as needed from content
servers — and sends the output to the user interface for display to the user (steps 4 and through
7). Step 6, the step between the user client and user interface happens locally on the user’s
device. A single app or a browser with a DSP plug-in could handle both the user client and
interface, so the user client could be “under the hood” from the user’s perspective.
For simplicity, advertisers are not shown in Figures 3 and 4. Had they been, they would have
been connected to the business logic server in Figure 3 and the user client in Figure 4. More
complex relationships are also possible. For example, the user client could modify the initial
request before it is sent to the interface provider based on user settings, wallet balance, or any
other locally stored information. All of this is left out of the figures so the basic restructuring can
be seen.
What is a Social Network?
So far we have been discussing design principles at a fairly high level. The rest of this paper
addresses ideas for how DSP could (perhaps should) work in practice. Consider them a starting
point for discussion as opposed to final answers.
7
At its heart, what is DSP really? If we look at the major social media platforms, we see Twitter
with its emphasis on short public statements, Facebook with its emphasis on sharing with
friends, Reddit with its niche communities, Instagram with its pictures, YouTube with its videos,
etc. What we don’t need is a different protocol for each of these services because at their heart,
they are all the same. Each is a different way to communicate and share content with others.
That’s it. Approaching the design of DSP from this level of abstraction will both simplify it and
maximize its reach.
All the social media platforms listed above and many more — both existing and yet to be
imagined — should be able to work on DSP. The dimensions on which these platforms (and any
communication platform) vary are as follows:
Content type
Content access
Context
Content type
There is nothing fundamentally different between video, images, audio, text or any other content
type. They can all be reduced to ones and zeros and will need to be handled in the same basic
ways. Storage, access, context and various metadata — to name a few — should be handled in the
same way by DSP regardless of content type. Instagram, YouTube and SoundCloud are basically
the same website, varying only by the type of content they emphasize. DSP should be abstracted
such that all content — including new content types (e.g. VR, haptic) — can be supported.
Content access
Public tweets, status updates to friends, group chats, private direct messages; they all differ
based on who has access to the content. DSP will need to use encryption to ensure that only
those with permission may view content but also be flexible enough that a wide variety of
schemes for sharing content can be engineered by interface providers.
Public content is easy to handle because everyone is allowed to view it, so no encryption is
necessary. To limit access, we need encryption. One way to do this would be to encrypt the
8
content using a symmetric cypher so that only people with a key specific to that content could
view it, and then to distribute that key to the party(s) the content is being shared with using an
asymmetric cypher.
It goes without saying that this complexity should be hidden from the user. All the user need
know is that new content has been shared with them.
By default, service providers (interface providers and content servers) should not have access to
unencrypted content.
Context
When it comes to communication, context it critical. Depending on context, a joke can be a
threat, or a troll can be a philosopher. All content has a context, so DSP must have a robust way
to capture context as metadata so it can be presented as the content creator intended.
Quite often the context for content is other content: a comment or a “like” on a video, a
downvote, a retweet, etc. A simple pointer to the content referenced should suffice. However,
this content and all content will need categorization.
A system will need to be incorporated into DSP that can capture everything from subreddits to
friend circles, from a LinkedIn-style website to blogs. One way to do this is with tags. I suggest a
taxonomy of contexts be gathered from the current platforms and a list of tags be compiled.
These should not be hard-coded into DSP, but rather should be available as documentation for
service providers to draw from and add to.
As usual, this complexity should be hidden from the user. When a user creates content, they
usually do not consciously think about context, they just know they are tweeting, posting to a cat
meme subreddit or clicking a heart icon next to a video they like. The content generated should
be tagged automatically according to business logic from the interface provider being used (more
on this below). That way, regardless of what interface is being used, when a user generates
content, other interface providers will know how to interpret and display it to their users.
So, for example, if someone “likes” your content on a Twitter-style website and someone else
“likes” it on a Facebook-style site, everyone viewing your content, regardless of which site they
are using, will see two likes.
9
By varying these three parameters, all of the various platforms can be reproduced using DSP.
More importantly, without the network effect to contend with, other social media and
communication services that have been unable to gain an audience should now find they can
cater to niche communities.
One could argue that “content constraint” is missing from the above list of three. Isn’t what sets
Twitter apart the fact that its users are limited to 280 characters? That is indeed the case, but
content constraint is not something that needs to be handled by DSP because it can be achieved
via context.
For example, in the case of a Twitter-style service, content generated using its interface (tweets)
can be tagged as such. The interface won’t allow the user to generate anything longer than 280
characters, so all content tagged as a tweet from that interface will be 280 characters or less. If a
user were to generate a “tweet” longer than 280 characters independently, the twitter-service
would simply not display it to other users.
Profile Management
Users are what bring life to the DSP protocol. The main challenge for a decentralized protocol
when dealing with user profiles is the name space. Centralized platforms handle their name
space by keeping a list of all registered usernames in one place and checking for duplication
when a user tries to register a new name. (Of course, users must re-register on every platform
they use and may find their registered username on one platform is taken on another). For a
decentralized protocol, things are not so simple. There is no central list to consult and no central
authority to reject duplicates.
However, we can turn to cryptography for a solution. Public key cryptography would allow
anyone to easily create a public and private key-pair through any interface provider. The public
key represents your identity on the DSP network while the private key would be kept by your
user client and used to prove you are behind that identity. The public key is generated pseudo-
randomly, so the odds of two people generating the same key are so small they can safely be
ignored. Voila! You now have a unique name and identity on the network. But who wants to be
known as a random-looking string of characters?
10
