Decentralize 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.
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.
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.
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.
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.
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.
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.
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 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.
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?
One way to handle this is the same way it is handled in the real world: let people call themselves whatever they want, ignoring duplication. Then simply check the unique ID if you are ever unsure who you are dealing with.
Another way would be to establish a name server scheme similar to how unique IP addresses are translated into unique domain names. In this case, the public keys are analogous to IP addresses and usernames to domain names. To decentralize this, user clients and interface providers could keep a list of all the key/name pairs they have encountered. When registering a new one, the user client could “ask around” the network if the name is on anyone’s list. If not, the new key/name pair is announced. If a user encounters a name already in use that is duplicated in their list, the interface could disambiguate with a nonce (1, 2, 3 etc.) or some other distinction.
Another solution would be to use a blockchain to record key/name pairs without duplication. The problem with requiring registration on a blockchain is that it erodes privacy. Blockchains are public by necessity, but not all users are so concerned with name-space duplication that they want the world to know about their DSP identity. They may only be using DSP to connect with their immediate friends and family where disambiguation is not a big issue.
Blockchain registration also requires a fee denominated in the blockchain’s native currency. This presents a bootstrapping problem because new users cannot be expected to pay for using DSP after they have spent decades using modern platforms at no charge (more on this below).
The choice should be put in the users’ hands, not as something they have to think about and deal with, but something their user client or interface provider will. Whether it is a blockchain, name servers or just polling the people you are connected to in the network, there are tradeoffs between cost, privacy and centralization. At the base level, the problem is solved using public keys, but interface providers will have to come up with ways to handle matching usernames to public keys.
Reputation Management
Now that we have profiles, we turn to how those profiles relate to one another. In a perfect world, social networks would be places of civilized informed discussions governed by mutual respect and common decency. Clearly, we do not live in a perfect world. Social media users are more like an unruly mob, and increasing pressure is being put on platforms to moderate content. Platforms find themselves in the impossible position of deciding what content is and is not allowed for billions of users. No matter what they do, some users will be upset.
DSP sidesteps this problem by decentralizing responsibility for rating the reputations of users. Instead of the platform calling the shots for its entire user base, each user keeps a list of ratings in favor or against other users and shares that list with the people in their network. This idea is called Web of Trust (WoT), and it is a beautifully simple way to minimize the impact of bad actors in a decentralized system. It is an online version of what we all do in the real world.
Let’s say you are invited out for coffee by someone on the periphery of your social circle. How do you know if you should accept or not? You ask the people in your circle who you believe are good judges of character. If they all say he is aggressive or boring, you probably won’t go, and vise-versa if their reviews are positive. WoT works the same way. Instead of putting all of your trust in a single platform, you get lots of input from the people in your network you already trust, and they get input from you. Of course, WoT is handled at the protocol level, so users do not have to think about it.
Care will be needed when designing the WoT implementation used in DSP. It should be abstracted as much as possible to accommodate unforeseen applications and put the decision-making power on the side of the user. Here is how it might work: imagine a user named spambot2020 keeps posting links to a get-rich-quick scheme on your carefully crafted, brilliant public messages . You should be able to flag the offending content as “spam.” Content from that account would no longer show up for you. More importantly, it would also stop showing up for people who trust you. The flag would just be another piece of content to be tagged and shared according to DSP’s system of content access and context.
Not all decisions are as easy to make as whether an account is spamming or not, and immediately blocking all posts from a certain account may not be the best action to take. Luckily, WoT is highly flexible, allowing every user to determine how to interpret and handle flags from their network. Flags can be tagged differently (e.g. spam, hate, troll, bot, like, smart, funny) and can be weighted differently according to a user’s preferences. If someone you trust strongly trusts someone else who likes a certain song, well you might like it too. Your own flags and flags of others all add up automatically to help interface providers determine what gets displayed to you and how prominent it is.
This is what platforms do already, each with its own proprietary algorithms. Under DSP, the underlying structure and content of the WoT layer is controlled by the users, so they can choose any interface they want, leading to vastly more variety and options from interface providers.
This reveals the real beauty of WoT: there is no centralized point of view. If I flag someone as a troll, they are a troll to me only. It is not “The Truth.” Some users can take my judgement and weigh it against the accused troll, others can ignore it and still others can find it to be positive, seeing it as a “badge of honor.”
The point is, each interface provider will choose how to filter and display content. In turn, users will be able to choose from a wide variety of options and can even change filters and interfaces day-to-day or moment-to-moment depending on their mood. No one will complain of being banned or censored unfairly again because every user has the right to speak, and every other user has the right to stop listening.
WoT is not just for filtering out bad content however. It is also a decentralized system that helps users choose who they can trust to do business with. As we will see below, WoT will be invaluable as we grapple with how to handle value creation and transfer between users, advertisers and service providers.
Value Creation and Transfer
Social media platforms make their money by selling ad space. Their platform is free and open to the public, but along side the content a user has logged on for, there are also ads. Controversially, platforms use users’ personal data and content to categorize them so they can help advertisers better target potential customers. Under DSP, service providers don’t have access to user content, users do. Thus, a reformulation of this successful ad-driven business model will be needed if we are to decentralize social media completely.
Currently, platforms act as a trusted middle man between advertisers and users. Advertisers pay the platform, trusting their ads will be displayed to the types of users agreed to as often as agreed to. Advertisers come to value the platforms that generate the most traffic to their links, but really what they value is the users. It is the user that generates value by looking at brand ads, clicking on ads and ultimately making purchases or doing what the advertisers hoped they would. Users create value, so it is users who should be paid.
However, platforms do provide a valuable service to advertisers, so we must make sure DSP can do the same. For example, DSP must ensure ads are not being served to a bunch of fake accounts set up just to collect ad revenue, and that the right ads are being displayed to the right users. This is where WoT comes back into play with an elegant solution.
Here is how it might work: advertisers bid on ad space for each user they wish to target, and the user collects the revenue for each ad displayed on their screen. The user’s client cryptographically signs the ad and sends it to the advertiser, so they know their ad was seen. If a user clicks on an ad, the advertiser knows this too because the user lands on the advertiser’s site. If the user does what the advertiser wants them to do (e.g, make a purchase or click a link), they send the user a signed receipt with the value of the user’s action, the time it occurred, and other metadata.
This means that each step of the way, the user has proof of the value they created which they can share publicly to attract more advertisers to bid for their ad space. The signed receipts are like tokens of trust in the WoT. If a user tries to game the system and sell ads to themselves from a dummy account, it won’t matter because those dummy accounts will not have any trust built up with real advertisers. They will just be ignored. So, the more a user clicks on ads and follows through with what the advertisers want, the more proof they will have that they are a good investment to other advertisers and the more money they can make. This kind of advertising is, in a way, even more targeted than that offered by current platforms, and at no point is a user’s content shared or their privacy violated.
There is one problem with this formulation, but again cryptography can provide a solution. A user may want advertisers to know they clicked on an ad and spent $300 on the website they landed on, but maybe not if that website sold certain medication or took donations for a certain political party. Technically, users could choose not to make public the tokens from such sites, but all of this complexity should be hidden from the user anyway. We do not want them to have to make such a difficult decision every time they click a link.
Instead, a profile that is not publicly linked to a user’s main profile should be created specifically for a user’s interactions with advertisers. A user’s reputation and value to advertisers will thus be tied to a randomly generated public key. Advertisers will know the user’s shopping and clicking habits — very valuable information for targeting — but will have no idea who they are or what they do and share on DSP.
It is likely that advertisers won’t analyze and bid on users individually. Surely specialists that can bundle users in different ways (based on their anonymous public profiles) will cater to advertisers. However, this should not pose a centralization problem. There will be few barriers to entry for such specialists because the underlying WoT data is decentralized and public.
An open question is what payment system to use for all this. I do not think DSP should answer this question, but rather should let third party developers create plug-ins. An initial plug-in for a popular payment system supporting micropayments could be developed alongside DSP to get things started. Better yet, a decentralized payment protocol (DPP) could be deployed.
Services
Now that users have money, we can talk about how it can be used to pay for essential DSP services in a decentralized way.
• Content storage and access
One of the services centralized platforms provide is storing and delivering content on demand. Data centers scattered all over the globe are dedicated to this task. For DSP to be truly decentralized, this service must be decentralized too. There cannot be a single entity in charge. Anyone must be able to offer this service with very low barriers to entry, and the users must be in charge of how their data is handled. With users controlling the ad revenue, a narrow competition can be set up whereby content servers try to deliver content as cheaply and quickly as possible.
Here is how it might work in practice: a user searches for a piece of content, the “Charlie bit my finger” video for instance. Content servers answer back with prices. The user client then weighs the speed of the responses and prices and sends payment to the best server, at which point the content is delivered. All of this would be handled by algorithms in a split second without human involvement of course.
It should require little technical skill to set up a content server. People already running web services could install software that utilizes excess storage and bandwidth just for this purpose. Even home computers and devices could serve this function.
WoT could be used to help this system run even smoother. Content servers and users that trust each other can exchange content and payment more loosely rather than bidding for and establishing a transaction for every piece of content. Essentially, content servers could extend a line of credit to users that establish a reputation for following the protocol, or for new users they want to establish a WoT connection with.
Different algorithms could be experimented with on both sides. An explore/exploit algorithm could be deployed for users looking for the cheapest, fastest and most reliable servers on the network. On the server’s end, they will want to store the most valuable content they can: the most frequently accessed.
How that will work in practice is complex because access (demand) is offset by availability (supply). It is better to be the only server hosting content that is accessed 1,000 times per day than one of a million servers hosting content accessed a million times per day. Servers will experiment with different algorithms as they compete for business.
However, it may be that some content is accessed so infrequently that no server will want to host it. Perhaps it is a private message between two people that is very rarely reread. Storage of this content will have to be paid for. Again, servers can compete for the privilege of storing your archived content. Users will want some redundancy here in case the only server hosting their content goes offline.
Under this arrangement, we can expect the cost of data storage and access to be extremely cheap, at or near cost. Given that excess server capacity can be used at zero marginal cost, and that some value may be placed on customer acquisition and WoT ratings, data services may even be provided for free in some cases.
• User interface
Another crucial piece of the DSP puzzle is, of course, what the users experience as they interact with the network. This is what most of us think of when we think of social media: content feeds, friend lists, inboxes, homepages, logos, forums, chat windows, etc. As we have come to expect, platforms have monopolized the user experience for the data sets they control. There is only one place to see your Facebook profile, for example, and that’s facebook.com.
This must be decentralized under DSP so that any website or app can display your content, but without having access to that content. Because users are in control of their content, all they need from interface providers are intuitive and enjoyable ways to interact with that content. Instead of just one layout for Twitter accessible only at twitter.com, anyone should be able to set up a service and experiment with different ways for users to generate and interact with their content.
Imagine a Facebook-style homepage. On the left is a list of your friends, in the middle is your feed of updates about your friends and on the right are a few ads. And let’s say you are viewing this through an app on your tablet. When you open the app, business logic is pulled from the interface provider which tells the app how to generate the page. Essential information — like your profiles, keys and wallet— is stored locally with your user client as part of the app. If it is a fresh installation and you have preexisting profiles, the app will pull your encrypted user file from a content server and you will have to enter your password.
The app will accept the top few bids from advertisers, credit your wallet and display the ads on the right. It will pull your friend list from a content server, along with associated content such as pictures and posts you have been granted access to. The app will use algorithms from the business logic it got from the interface provider to sort and display it all.
For this, the interface provider can charge a fee which can come from the ad revenue generated. As with content servers, stiff competition can be expected between interface providers given users’ very low switching costs. So, instead of the users and advertisers going to the platform who controls the content and interface; the advertisers, content servers and interface providers all go to the user and compete for the user’s attention and value.
An issue arising from this design is that services relying on access to user content are not possible. For example, how can a user search their private messages by key word if those messages are encrypted and spread over several content servers? Ideally, we would not open Pandora’s box and allow service providers access to content, even under the guise of servicing users. That is how we got into the mess we are in. Thankfully, there is often a creative solution letting users have both privacy and functionality.
In the search example above, an interface provider could send the user client an algorithm that indexes the user’s content with key words and stores that index in a separate file accessible only to the user. When the user wants to perform a search, her user client pulls the much lighter index file to search and then pulls only the content matching they key words in the index.
This is a user-centric rather than service-centric engineering paradigm. It preserves privacy, and with ever expanding processing power available on the user side, putting the user at the center of things should not be a problem for most applications.
However, the main difference for the user is the responsibility of remembering and securing the password for their encryption key. If you forget your password, there is no platform you can go to for a reset. Any other solution to this problem will give a third party access to your content.
Perhaps a multi-signature encryption scheme could be deployed where one’s password could be recovered by several trusted parties cooperating. That way no one can access your content by themselves or without your knowledge, and only when you need to recover a password.
Ultimately though, a user-centric system empowers the users, and with power comes responsibility. Given the hacks and data breaches of major platforms in recent years, that is a responsibility that users should want. No one cares about your privacy and security more than you do.
• Edge cases
We know that social media platforms are profitable, so in the aggregate, ad revenue more than compensates for all the services platforms provide. We should therefore expect the ad revenue for the vast majority of individual DSP users to cover the costs of their content servers and interface providers. It is instructive though to look at three edge cases.
At one extreme, there might be users who cannot generate enough ad revenue to cover their costs. It may be that if a user never clicks on ads then advertisers will eventually stop paying to display those ads. However, brand advertisers may still be willing to pay a very small amount, allowing some content delivery. As a worst case, such a user could simply host their own content, eschewing the convenience of a service provider. Or better yet, they could become a service provider themselves and make enough to cover their own DSP use.
At the other extreme, there may be users who are so valuable to advertisers that they bring in more ad revenue than is needed to cover the costs of the various DSP services they use. Given the billions of dollars in profit generated by social media platforms benefiting from the network effect, it is reasonable to expect that many users will profit by using DSP and interacting with their advertisers.
The last outliers we will consider are the users who would rather not see ads and instead pay for DSP services themselves. Such users will have to fund their DSP wallet themselves which will be slowly drained.
The Content Problem
Every solution to a problem sows the seeds for a new set of problems. Take the internal combustion engine for example. It was a dramatic improvement over horse-powered energy. It eliminated equine waste from city streets, freed up capital and vastly expanded our capabilities. No one would want to go back to a time of horse-drawn buggies and plows, but we do have to deal with air pollution, car collisions and other issues. If electric, self-driving cars are the solution to those problems, we can be sure they will eventually be the source of new problems our progeny will have to solve.
DSP helps solve the problems created by the network effect and the centralization of social media platforms. Once adopted, no one will want to return to the days when they had no privacy and only one interface option. However, we will surely have a new set of problems to deal with. An obvious one — one we will have to deal with eventually — is what I call “the content problem.”
As formulated above, we can expect DSP to give rise to a censorship-free domain. If one interface censors a user’s content, they can just move on to another that won’t. That is great if the user is pointing out human rights abuses or is simply exercising free speech. However, not all content is speech. Some content is harmful because it contributes to or directly leads to the harm of innocent people. An obvious example is pedophilia.
If DSP becomes known as a tool for disseminating that kind of content, no one will want anything to do with it. Interface providers, content servers, advertisers, and the developers behind DSP won’t contribute their talent and resources to it. The average user won’t reap all the benefits of decentralization covered above. DSP will have failed.
It could be said that the content problem is caused by the cryptography at the heart of DSP. If DSP did not encrypt user content, the content servers could scan for harmful content and reject it. But this would destroy the privacy of every DSP user, the vast majority of which are regular, law-abiding people. To solve the content problem, we need a way to identify harmful content in a sea of normal content without accessing or seeing any of it. On its face, this seems like an impossible task.
However, I have proposed a solution here called Zero Knowledge Artificial Neural Networks (ZKANNs) that use cryptography and networked machine learning to do just this. Something like it will have to be developed eventually to combat the content problem.
Conclusion
Today’s platforms hold tremendous sway over the attention of users and the value they create. With people locked in via the network effect, platforms can cater to the advertisers, even at the expense of their users. Sophisticated algorithms have been developed to exploit common weaknesses in the human psyche. Vanity, voyeurism and outrage keep users glued to the screen, clicking, scrolling and swiping for more, all so more ads can be displayed.
Under DSP, everyone’s incentives are aligned to serve the user, who will use the interfaces they value most. Personally, I would want to use interfaces that help me feel calm, happy and connected to the people and content I care about.
For DSP to be successful, it must offer the seamless experience the platforms do, but with the added benefits derived from decentralization. The complexities of encryption, content servers, micropayments, ZKANNs, and ad networks must be hidden from the average user. All they need to know is that the system works, and sometimes they even have some extra money in their wallet.
In many ways, DSP will be the fulfillment of the vision of the early Internet, but instead of decentralizing to the domain level, we will decentralize all the way to the users, putting control and privacy where it belongs, in their hands.
End Note
I have refrained from surveying the state-of-the-art and recent developments in decentralization technology. It is difficult to do in part, and impossible to do in whole, from within a prison cell. I am sure many of the ideas above are not new, but I hope my musings on the matter will be valuable in some way to those building and using the DSPs of tomorrow.
