January 23, 2022

Decentralized social media

Today, the centralization of social networks has led to many problems for social platforms in general, and also for their users.This includes privacy breaches and the daunting task of moderating content posted by billions of users every day. Below, I describe a decentralized social protocol (DSP) that can help or at least mitigate these problems by giving users control over what they post and the ability to personally contribute to the creation of social value and its transmission over the network.


This protocol will allow usersindependently choose the interface, server and advertising providers, and not be content with the services of any one platform that monopolizes these essential things.

I describe decentralized solutions formanage profile, privacy, hosting, user interface, ad network, content filters, metadata and more. In general, all the major components of social networks.

Decentralization everywhere

It is not necessary to remind, but, the basic principledevelopment of a decentralized protocol is, accordingly, decentralization. However, as of today, the trend towards centralization is still too strong. Centralized nodes have the opportunity to grow freely, and it is easy to predict where they will appear and how they will develop.

Let's take a look at the main TCP / IP protocols andHTTP, which are extremely widely used on the web today. When they first appeared, they seemed to be completely decentralized. Anyone could create a site and anyone could access it. The only requirement to enter is an Internet connection and an IP address. What could be more egalitarian? We saw the early web flourish, which is what we expected from such an environment. However, no one foresaw how significant the network effect would play.

And it doesn't matter what anyone elsecan create a site to compete with Facebook, YouTube, Reddit, or Twitter. Nobody will just use it. And while it has better privacy protections, cooler features, and no ads, it still won't have one important thing that gives these tech giants an overwhelming advantage: a large number of other users. Even when Google, already having a massive market share, tried to compete with Facebook to promote Google+, it ended up doing nothing after seven years and billions of dollars spent.

After the advent of TCP / IP and HTTP - decentralizationliterally tripped over the URL. Whoever controls the URL controls everything behind it. For example, these are URLs like Facebook.com, Google.com, Amazon.com, etc. They are backed by the strongest and richest corporations on the planet. But, with DSP we will go further.

In the setting of social networks, the most insignificantand an ordinary user is practically a disenfranchised unit. Therefore, when we talk about decentralization, we, first of all, mean the transfer of all powers into the hands of ordinary users. Because simply being able to create websites and decide which ones to visit is no longer enough.

As centralization will evolve everywhere,where possible, DSP designers and developers should do their best to discourage it. Unfortunately, this takes imagination and effort. It's much easier to move away from full decentralization, leave the really tricky parts to others, or fill the gap with your own centralized platform.

It's worth noting that tech giants are alreadypartially decentralized. They don't generate content. Users do it. In turn, the DSP must not only take advantage of the functions that are, today, centralized, but also, be sure to decentralize them.

Who controls the content?

Information is fundamentally different from physicalproperty. It can be endlessly duplicated for almost free, so when someone talks about data ownership it can be confusing. Copyright laws exist to combat this inherent abundance of information, to prevent copies from being copied (for the benefit of the content creator). There are also nondisclosure laws that punish people for sharing information they have pledged to keep secret. However, these laws are undermined by peer-to-peer file sharing in the case of copyright and whistleblowers in the case of secrecy. Yes, information is difficult to control and keep locked up.

But, in a decentralized system, you cannotrely on a central authority to enforce such laws, so you have to deal with information, figuratively speaking, on its terms. And instead of figuring out who owns the user's content, we should ask - who has the right to access that content. The default position of modern platforms is that the platform owns the content and centrally grants access rights.

But according to the DSP concept the creatorcontent (user) must control access himself using an encryption scheme that includes key sharing. Wherever possible (ideally generally), service providers should not have access to unencrypted user content. Only those who have been granted access rights should have it.

Encryption transfers control directly tothe hands of the key holders, so the location of these keys is the most centralized point. Accordingly, ideally, users should have the keys. All information stored or transmitted should be encrypted by default, unless specifically designed to be shared.

This is a radical shift from the current paradigm.When users control their own data, the network effect loses its sole support. If the content and connections that make up the various social networks are managed at the protocol level, websites lose their exclusive monopoly on their users.

Again (as with the early internet)anyone can create a competing website or app. Only this time, instead of being empty, it will provide users with all their content, as well as the content of other users that they have access to. The user will have minimal switching costs because the new website will simply be a new interface to the same content. Such an environment will lead to a flourishing of innovation, empowering users and improving every aspect of their work.

Money matters

Social media platforms bring intens of billions of dollars in profits. This income is generated almost exclusively from ad placement. It would be easy to ignore the problem of money and allow DSP service providers to invent their own business models and hope that, given the low user switching costs, the providers will behave correctly and meet the needs of the users. However, this is a flawed approach already implemented in existing protocols, which led to what we have today.

The fact that we have to put up withis that money is a key element of centralization. Users attract advertisers, advertisers bring in money, money goes to expand and develop the service, and the best service brings even more users. Money is needed for this feedback loop that draws everyone to the same service provider whose real business is to dock your eyeballs with ads.

This is possibly the hardest part of DSP todesign, but, at the same time, the most important. Either way, users need to be at the center of this value creation and transfer process. Given that user attention is the source of value for this system, the problem should not be insurmountable.

Restructuring social media

Considering the above design principles,let's look at the relationship between stakeholders within modern social media platforms and how these relationships should be restructured within the DSP.


Shown above are the four components that make upparadigm inherent in modern platforms. There are three stakeholders: platform (red), advertisers (green), and users (blue). Everything goes through the platform. The platform owns and centrally manages the content server. She stores content created by her users and displays it through her interface. It's important to note that the platform sits between users and advertisers. Advertisers pay the platform to show ads to users and generate their clicks. Within this structure, the platform owns all the keys. She controls everything that is generated by this system.


In turn, according to the DSP concept,the system should be user-centered. As shown in the figure, the user is between three other stakeholders: interface providers, content servers, and advertisers.

Thus, instead of a platform standing deadBetween users and advertisers, advertisers pay users directly by offering bids for ad placement on their interface. Interface providers and content servers are also competing for this ad revenue. Now, instead of a monolithic platform providing an interface, many interface providers are able to offer their services to users. And instead of the platform owning and controlling all the content, the content servers compete to host the user's encrypted content. It is important that within the framework of the DSP, the user owns all the keys and controls everything that the system generates.

This user-centered paradigmrequires rethinking how online services are designed and built. Modern platforms can be conceptualized in three parts: content, user interface, and what is sometimes called "business logic." Business logic is all the instructions that the platform uses to collect relevant content and send it to the user interface for display. This is where the algorithms for searching, sorting and managing content work. Recommendation engines, aggregators, and various forms of artificial intelligence are all business logic.


The figure shows a simplified version of howcontent is delivered to the user by current centralized platforms. The user makes a request through the user interface, which passes the request to the server responsible for the business logic (steps 1 and 2). This server determines what content is needed and retrieves it from the content server (steps 3 and 4).

The content is then prepared for display andsent to the user interface, which displays it to the user (steps 5 and 6). The servers responsible for business logic and content are controlled by the platform and run on its hardware, while the user interface (for example, in a browser or application) runs on the user's computer.

Within the DSP, since the interface providers do nothave access to content, they cannot execute business logic on their own. This has to be done on the user side by what is called a "user client".

The custom client is just an applicationor a browser plug-in that can perform business logic tasks and manage user profiles and wallet. In turn, the function of the interface provider is to simply pass the output of the business logic module to the user client, instructing it to collect content and compile for display through the user interface.


The figure shows the whole process.Here, again, the user makes a request through the user interface, which is passed to the server that handles the business logic and belongs to the interface provider itself (steps 1 and 2).

The interface provider then sendsthe corresponding business logic processing results back to the user client (step 3). The user client processes the received business logic, collects the necessary information from the content servers, and displays the result through the user interface (steps 4 through 7).

The sixth step, between the customclient and user interface, occurs locally directly on the user's device. In this way, a single application or browser with a DSP plug-in can handle both the user client and the interface, so the user client is “under the hood”.

For simplicity's sake, advertisers do notmarked in the third and fourth figures. But, if present, they will be connected to the server responsible for the business logic in the third figure and the user client in the fourth figure.

More complex relationships are also possible.For example, a user client can modify the initial request prior to sending it to the interface provider based on user preferences, wallet balance, or any other locally stored information.

All this is excluded from the presented diagrams to simplify the display of the main structure.

What is a social network?

So far, we have discussed design principlesat a fairly high level. The rest of this article explores ideas for how DSP can (perhaps should) work in practice. Think of them as starting points for discussion, not definitive answers.

What is DSP in essence?If we look at the main social media platforms, we see Twitter with its emphasis on short public statements, Facebook with its emphasis on sharing information with friends, Reddit with its niche communities, Instagram with its photos, YouTube with its videos, etc.

What we don't need is a separate protocol foreach of these services because at a basic level they are all similar. Each one represents a separate way of communicating and sharing content with others. This is the whole point.

Approaching DSP design from this abstract level will both simplify the task and maximize overall coverage.

As conceived, all social networking platforms listed above, and many others, both existing and not yet invented, should be able to work on the DSP protocol.

The dimensions by which these platforms (and any communication platform) differ - they depend on the type of content, access rights to the content, and the overall context.

Let's take a closer look at each point.

Content type

There is nothing that fundamentally distinguishes betweenany video, images, audio, text or any other type of content. All of this can be reduced to simple ones and zeros, and they can be handled in the same way.

Things like storage, access, context andvarious metadata (these are just a few) - may well be processed through the DSP, regardless of the type of content. Instagram, YouTube and SoundCloud are basically the same website and only differ in the type of content they focus on.

In turn, the DSP should be abstracted in such a way that all content can be supported on it, including new types, for example, VR, tactile content, etc.).

Content access rights

Public tweets, status updates for friends,group chats, private direct messages - all of these can be assigned different access rights. The DSP will need to use encryption to ensure that only those with permission can view the content. At the same time, a certain flexibility is required so that interface providers can develop a variety of content exchange schemes.

Public content is easy to process because it can be viewed by everyone, so no encryption is required. But to restrict access, we need encryption.

One way to do this is encryptioncontent using a symmetric cipher so that only people who have a key specific to that content can view it. Also, they should be able to distribute this key to the parties with whom they want to share the content.

It goes without saying that this complexity must be hidden from the user. All the user needs to know is that he has been given access to new content.

But, in any case, by default, service providers (interface providers and content servers) should not have direct access even to unencrypted content.


When it comes to communication, context hascrucial. Depending on the context, a joke can be a threat and a troll a philosopher. Therefore, all content has context, so the DSP must have a reliable way of capturing context as metadata so that it can be presented according to the intent of the content creator.

Quite often, the context for content can beother content: comment or like on a video, downvoted, retweet, etc. In general, a simple link to content should be sufficient. However, this content and everything else will still need to be classified.

The DSP will need to include a system thatcan cover everything from subreddits to circles of friends, from LinkedIn-style website to blogs. One way to do this is with tags. I suggest collecting contextual taxonomy from current platforms and compiling a tag list. They should not be hardcoded into the DSP, but rather should be available as documentation for service providers from which they can draw and add metadata.

And again, this complexity must be hidden fromuser. When a user creates content, they usually don't consciously think about context - they just tweet something, post a cat meme on Reddit, or click on the heart icon next to a cool video.

Created content should be flaggedautomatically according to the business logic of the interface provider being used (details below). This way, no matter what interface is used when a user creates content, other interface providers will know how to interpret and display it to their users.

So, for example, if someone liked your content ona Twitter-style site and someone else has liked it on a Facebook-style site, then everyone who views your content, no matter what site they use, will see two likes.

In general, different platforms, varying these threeparameter can operate on a single DSP protocol. More importantly, without the network effect to combat, other social media and communication services that might not have been able to reach audiences before will find that they can indeed serve niche communities.

True, the above does not say anything about the limitationcontent. But, isn't the same Twitter distinguished by the fact that its users are limited to 280 characters? This is indeed the case, but content limitation is not something that should be handled in the DSP, so again this can be achieved through context processing.

For example, in the case of a Twitter-style servicecontent created using its interface (tweets) can be tagged as such. The interface will not 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 generated a tweet longer than 280 characters on their own, Twitter would simply not show it to other users.

Profile Management

Users are what give life to the protocolDSP. The main problem with the decentralized protocol when dealing with user profiles is the namespace. Centralized platforms handle their namespace by keeping a list of all registered usernames in one place and checking for duplicates when a user tries to register a new name.

Although, if a user decides to register on several popular platforms at once, he may find that his registered name on one platform is already taken on another.

But, be that as it may, for a decentralized protocol, everything is not so simple. There is no central checklist and no central authority to reject duplicates.

However, we can ask for a solution tocryptography. Public key cryptography will allow anyone to easily create a public / private key pair using any interface provider. The public key represents your identity on the DSP network, while the private key will be stored by your customer user and used to verify your identity.

The public key is generated pseudo-randomly,therefore, the likelihood that two people will generate the same key is so small that they can be safely ignored. Voila! You now have a unique name and identity on the network. But who wants to be known as an arbitrary looking string of characters?

One way to deal with this is the same asthis is done in the real world: let people call themselves what they want, ignoring the problem of duplication. Then just check the unique ID if you're not sure who you are dealing with.

Another way is to create a nameserver schema,similar to how unique IP addresses are resolved to unique domain names. In this case, public keys are like IP addresses, and usernames are like domain names.

To decentralize this, customcustomers and front-end vendors could keep a list of all key / name pairs they encountered. When registering a new user, the client-user can go to the network and check if this name is on someone else's list. If not, a new key / name pair is declared. If the user is faced with the fact that the chosen name is already used by someone and is in someone's list, the interface can eliminate the duplicate by means of a random nonce parameter (1, 2, 3, etc.) or some other difference.

Another solution is to use blockchain forrecords key / name pairs without the risk of duplication. But, the problem with requiring registration on the blockchain is that it undermines privacy. The blockchain is publicly available when needed, and not all users are so concerned about namespace duplication to let the world know their personal ID in the DSP. After all, they can only use DSP to communicate with their closest friends and family, where takes are not such a big problem.

Registration on the blockchain also requirescertain costs expressed in his coins. This poses a problem in the first phase, as new users cannot be expected to pay to use DSP after they have used modern platforms for decades at no cost. (details below).

In any case, the choice should remain forusers, but, they don't have to think about it themselves and deal with it directly - this is a task for the developers of the user client that they decide to use. Whether it's a blockchain, a nameserver, or just checking the names of other users on the network, there is always a trade-off between cost, privacy, and centralization. At a basic level, the problem is solved with public keys, but front-end vendors will have to figure out ways to handle the mapping of usernames to public keys.

Reputation management

Now that we have profiles, we will consider,how they interact with each other. In an ideal world, social media could be a place for civilized, informative discussions based on mutual respect and general decency. But, obviously, we do not live in an ideal world.

Social media users are more likean uncontrollable crowd, and there is increasing pressure on platforms to moderate content. At the same time, platforms find themselves in a rather difficult position, deciding which content to allow and which to ban for billions of users. And no matter what they do, some users will still be upset.

DSP solves this problem by decentralizingresponsibility for assessing the reputation of users. Instead of the platform making its own decisions regarding its entire user base, each user will maintain a list of ratings in favor of or against other users and share this list with people on their network.

This idea is called Web of Trust (WOT) and it isa great simple way to minimize the impact of "bad members" in a decentralized system. This is an online version of what we have been doing in the real world for a long time.

Let's say you are invited for a cup of coffee by someone on the periphery of your social circle. How do you know if you should agree or not?

In this case, you can ask about thisacquaintances from your circle who, in your opinion, are well versed in people. If they all say he's aggressive or boring, you probably won't go, and vice versa if their reviews are positive.

WoT works the same way.Instead of completely trusting one platform, you get a lot of information from people on your network that you already trust, and they also get information from you. At the same time, WoT is processed at the protocol level, so users do not need to think about how it works.

True, in the process of implementing WOT in DSP,it will take some care. The system should be abstracted as much as possible in order to take into account various unforeseen things and completely delegate the authority in terms of decision-making to the user.

This is how it might work:imagine a user named spambot2020 keeps posting links to the get-rich-quick scheme in your carefully crafted, brilliant public posts. Here, you should be able to mark offensive content as spam, after which content from that account will no longer be displayed to you. More importantly, it will also stop appearing in people who trust you. The tag will be just another piece of content that will be tagged and transmitted according to the content access system and the DSP context.

But, we must admit that not all decisions are so easy.accept as a question of what is spam and what is not, and immediately blocking all messages from a particular account may not be the best solution.

Fortunately, WoT is highly flexible.allowing each user to determine how to interpret and process tags from their network. Tags can be different: spam, hate, troll, bot, like, smart, funny, etc., and can also be weighted in different ways according to the preferences of a particular user.

If someone you trust has a lot of trustsomeone else who likes a certain song, well, you might like it too. In general, both your own tags and those of other users are automatically folded to help interface providers determine what is displayed to you and how noticeable it is.

All of this reveals the true beauty of WoT:no centralized point of view. If I mark someone as a troll, then he is a troll only for me. And this is not the ultimate truth. Some users may take my judgment and compare it to the accused troll, others may ignore it, and still others may find it simply positive and take into account.

The point is that every interface provider willchoose how to filter and display content. In turn, users will be able to choose from a wide range of options and can even change filters and interfaces from day to day or moment to moment depending on their mood.

No one will complain about having him againbanned or unfairly censored because every user has the right to speak and every other user has the right to stop listening.

However, WoT is not just for filteringbad content. It is also a decentralized system that helps users choose who they can trust to conduct business. As we will see below, WOT will be invaluable when we decide how to create value and transfer it between users, advertisers and service providers.

Value creation and transfer

Platforms are known to make money -selling advertising space. They are free and open to the public, but in addition to the content the user is logged in to, there are also ads. And it is not certain that platforms are not using users' personal data and content to categorize preferences to help advertisers better target leads.

Therefore, according to the DSP concept,service providers do not have direct access to user data, but users themselves do. Thus, complete decentralization of social media will require a redesign of this ad-driven, successful business model.

Yes, currently, platforms are performing inas a reliable intermediary between advertisers and users. Advertisers pay the platform with the expectation that their ads will be shown to the types of users that have been agreed, and as often as agreed.

Further, advertisers begin to appreciateplatforms that generate the most traffic from their links, but they value the users themselves even more. After all, it is a simple user who creates the ultimate value by viewing ads, clicking on ads and making purchases, or what advertisers want. In general, if users create the main value, then they need to pay.

However, platforms provideadvertisers are a really valuable service, so you need to make sure the DSP can do the same. For example, a DSP must provide assurance that ads are not shown on just a few fake accounts set up to generate ad revenue and that the right ads are being served to the right users. It is here that WoT returns to the game, along with an elegant solution.

This is how it might work:advertisers place bids on the purchase of advertising space aimed at a specific category of users, while the users themselves receive income for each ad displayed on the screens of their devices. Additionally, the user client signs each ad with a cryptographic key and sends it to the advertiser so that he knows that his ad has been seen. If the user clicks on the ad, the advertiser will also know about this, because the user went to the advertiser's website.

If the user does what the advertiserwants him to do (for example, make a purchase or click on a link) - he sends back to the user a kind of signed receipt, where the user's actions, the time of their execution and other metadata are indicated.

This means that at each stage the user hasthere is evidence of the value he has created that he can share publicly to attract more advertisers to bid for his ad space.

In this case, signed receipts are likesign of trust in WoT. If a user tries to cheat the system and sell ads to himself from a fictitious account, it won't matter, because these fake accounts won't have any credibility with real advertisers. They will simply be ignored.

Thus, the more the user clickson ads and does what advertisers want, the more proof he has that he is a good investment for other advertisers and the more money he can make.

This type of advertising is, in a sense, even moremore targeted than what modern platforms offer and in no way represents shared content with the user or a violation of their privacy.

There is one problem with this formulation, but againthe same cryptography can provide a solution. Yes, a user may want advertisers to know that they clicked on an ad and spent $ 300 on their site, but they may not want to. After all, perhaps this site sells certain specific drugs or accepts donations for a specific political party. Technically, users may not publish tokens from such sites, but all these difficulties, in any case, should not concern the user directly. We don't want him to have to make a difficult decision every time before clicking on a link.

For example, you can create a profile that is notpublicly linked to the user's main profile, in general, it is created specifically for the user to interact with advertisers. Thus, the reputation and value of the user for advertisers will be tied to only a randomly generated public key.

Advertisers will know the user's habits,for example, what kind of purchases he makes and what buttons he clicks, which is very valuable information for targeting, but they will have no idea who this user is, as well as what he does and what he shares in DSP.

However, it is likely that advertisers are notwill analyze and place bets for each user separately. Undoubtedly, there will be specialists who will connect users in various ways (based on their anonymous public profiles) and serve the interests of advertisers. However, this should not create problems with centralization. In principle, such specialists will have few obstacles to work, because the basic WoT data is decentralized and publicly available.

The question remains, which payment systemuse for all this. I don't think DSP should answer this question, but rather should allow third party developers to create plugins. To get started, an initial plugin for any popular payment processor that supports micropayments can be developed along with the DSP. But, even better would be to deploy a decentralized payment protocol (DPP).


Now that users have money, we can talk about how it can be used to pay for basic DSP services in a decentralized way.

Storing and accessing content

One of the services provided by centralized platforms is the storage and delivery of content on demand. Data centers around the world address this challenge.

In turn, for the DSP to be reallydecentralized, this service should also be decentralized. There shouldn't be just one person in charge. Anyone should be able to offer this service with very low barriers to entry, and users should be responsible for how their data is processed.

Since users are already in controladvertising revenue, in addition, niche competition can be created in which content servers will try to deliver content as cheaply and quickly as possible.

Here's how it might work in practice:a user searches for a piece of content, such as the video “Charlie bit my finger”. Content servers offer their own shipping charges. The user client then estimates the response rate and shipping cost, and then sends the payment to the best server and receives the content. All this can be processed by algorithms, without human intervention, in a split second.

To configure the content server, you mustvery little technical skill is required. People who already have web services can install software that uses excess storage space and bandwidth just for this purpose. Even home computers and devices could perform this function.

WoT could be used to help thissystem run even smoother. Content servers and users who trust each other can exchange and pay for content more freely, instead of having to bid and set a transaction each time for each piece of content. Basically, content servers can provide a line of credit to users who have proven themselves by following protocol rules, or to new users they want to contact.

In general, on both sides it will be possibleexperiment with different algorithms. Analytical algorithms can be deployed to users looking for the cheapest, fastest, and most reliable servers on the network. Presumably, on the server side, they want to store the most valuable content, i.e. most visited.

How it will work in practice is difficultsay because access (demand) is offset by availability (supply). It is better to be the only server hosting content accessed 1000 times a day than one in a million servers hosting content accessed a million times a day. Servers will experiment with different algorithms as they compete for business.

However, it may happen that access tosome content is hosted so infrequently that no server wants to host it. Perhaps this is a personal message between two people that is very rarely re-read. You will have to pay to store this content. Again, servers can compete for the privilege of storing your archived content. At the same time, users will need some excess storage space in case the only server hosting their content goes down.

According to this, everyone can expect thatthe cost of storing and accessing data will be extremely low or close to the cost. Given that excess server capacity can be utilized at zero marginal cost and that customer acquisition and WoT ratings can add value, in some cases, data services can be provided free of charge.

User interface

Another important part of the DSP implementation task isthis is, of course, what users experience when interacting with the network. This is what most of us think about when we think of social media: content channels, friend lists, mailboxes, home pages, logos, forums, chat windows, etc. Here, as expected, platforms have completely monopolized the user interface for the data they manipulate. For example, there is only one place where you can view your Facebook profile, and that is facebook.com.

It should be decentralized within the DSP,so that any website or application can display your content, but not have access to that content. Since users are in control of their content, all they need from interface providers is intuitive and enjoyable ways to interact with that content. Instead of just one Twitter layout, available only at twitter.com, anyone should be able to customize the service and experiment with different ways of creating and interacting with their content.

Imagine a home page in styleFacebook. On the left is a list of your friends, in the middle is your news feed about your friends, and on the right is a few announcements. And let's say you view it through the app on your tablet. And when you open the application, the interface provider, based on the results of the business logic server, tells the application how to create the page

However, important information such as yoursprofiles, keys and wallet are stored locally in your user client as part of the application. If this is a fresh install and you already have existing profiles, the application will fetch your encrypted user file from the content server and you will be required to enter your password.

In turn, the application will accept severalthe best bids from advertisers, will fund your wallet and display ads on the right. It will fetch your friends list from the content server along with related content such as photos and posts that has been shared with you. To sort and display all this - the application will use the business logic algorithms obtained from the interface provider.

The interface provider may charge a fee for this,which can be obtained from advertising revenue. As with content servers, fierce competition between interface providers can be expected given the very low user switching costs. Thus, instead of users and advertisers moving to a platform that controls the content and interface - the advertisers, content servers and interface providers themselves go to the user and compete for the user's attention and the value that he creates.

But, in connection with this approach, there isthe problem is that the work of services that are based on free access to user content will not be able to work. Well, how will a user search for their private messages by keyword - if they are encrypted and distributed across multiple content servers? Ideally, you shouldn't open Pandora's box and give service providers full access to content, even under the guise of serving users. After all, we just got into the trouble in which we find ourselves today. But fortunately, there is still a creative solution that takes into account both privacy and functionality.

In the above example, the interface providercan send an algorithm to the user client that will index the user's data for further search for keywords and save this index in a separate file accessible only to the user himself. Eventually, when searching, the user client will use the lighter index file and then extract content from it that matches the requested keywords.

It is important that this engineering paradigm is notservice-oriented, and, first of all, is designed for the interests of the user. It really helps to maintain confidentiality. Moreover, in view of the constantly growing computing power on the user's side, placing the user at the center of all this should not be a problem for most applications.

However, here the main difference for the user isis the emergence of a responsibility to remember and protect the password for your encryption key. If you forget your password, there is no platform you can go to to reset it. Any other solution to this problem will give third parties access to your content.

While it is possible to deploy an encryption scheme withmultiple signatures, whereby a user's password can be recovered by multiple cooperating trusted parties. This way, no one will be able to access your content on their own or without your knowledge, and will only come into play when you need to recover your password.

In general, yes - user-centeredthe system expands its capabilities, but along with power comes responsibility. But given the hacks and data leaks on major platforms in recent years, this is a responsibility that users might want to take on. After all, no one cares about your privacy and security more than you.

Boundary cases

We know that social media platformsare profitable, so the aggregate ad revenue more than compensates for all the services provided by these platforms. Therefore, we should expect ad revenue for the vast majority of individual DSP users to cover the costs of their content servers and interface providers. However, there are three extreme cases worth considering.

For example, there will be users who cannotReceive enough ad income to cover your expenses. It may be that if a user never clicks on an ad, advertisers will eventually stop paying to serve those ads.

However, it is possible that advertisers are allthey will be willing to pay a very small amount by allowing some ads to be shown. In the worst case, the user can post his own content somewhere by opting out of the services of the service provider. Or better yet, they can become a service provider themselves and earn enough to cover their own DSP usage.

In principle, on the other hand, on the contrary, there will beusers who are so valuable to advertisers that they receive more ad revenue than is necessary to cover the costs of the various DSP services they use. Given the billions of dollars in revenue generated by social media platforms that benefit from the network effect, it is reasonable to expect many users to make a profit using DSP and interacting with their advertisers.

The last extreme we will consider isusers who choose not to see ads and will instead pay for DSP services themselves. Such users will have to replenish their DSP wallet themselves, which will slowly deplete.

Content problem

Often, solving a problem sows the seeds for a new one.set of problems. Take an internal combustion engine, for example. This was a significant improvement over the horse. It has eliminated horse waste from city streets, freed up capital, and greatly expanded our capabilities.

No one would like to go back to the timeshorse-drawn carriages and plows, but now we have to deal with air pollution, car accidents and other problems. And if electric self-driving cars are the solution to these problems, then we can be sure that, in the end, they will become a source of new problems that our offspring will have to solve.

DSP helps solve the problems posed by networkthe effect and centralization of social media platforms. Once adopted, probably no one wants to go back to the days when they had no privacy and only one interface option. However, we will undoubtedly have a new set of problems to deal with. The obvious problem that we will eventually have to deal with is what I call the "content problem."

As stated above, we can expectthat the creation of DSP will lead to the emergence of a censorship-free information distribution system. And if one interface censors the user's content, they can simply navigate to another, which does not. It's great if the user is outraged by human rights violations or just wants to enjoy free speech.

However, not all content is an expressionfreedom of speech. Some content is harmful because it contributes to or directly results in harm to innocent people. An obvious example is pedophilia.

If DSP becomes known as a tool fordistribution of this kind of content, no one wants to have anything to do with it. Interface providers, content servers, advertisers and DSP developers will not invest their talents and resources in this. The average user will not be able to take full advantage of decentralization described above, and DSP will fail.

It can be assumed that the problem with the contentrelates to the encryption underlying DSP. And if the DSP does not encrypt user-generated content, then content servers can scan for malicious content and reject it. But, this will violate the privacy of every DSP user, the vast majority of whom are ordinary, law-abiding people.

To solve the problem with the content, we needa way to identify harmful materials in the sea of ​​ordinary information without gaining access to them or seeing them. At first glance, this seems like an impossible task.

However, I can point to a solution underZero Knowledge Artificial Neural Networks (ZKANNS), which use cryptography and networked machine learning to do this. Something like this should eventually be designed to combat the content issue.


Modern platforms are having a huge impactto the attention of users and the value they create. People are captivated by the network effect, so platforms can serve advertisers, even at the expense of their users.

To exploit common human weaknessespsyche complex algorithms have been developed. Vanity, unhealthy curiosity, and outrage make users stick to the screen by clicking, scrolling, and swiping to view even more ads.

But, within the framework of DSP, all incentives are focused onserving users who will use the interfaces they value the most. Personally, I would like to use interfaces that help me feel calm, happy, and connected with people and content that I care about.

In order for a DSP to be successful, it mustensure the smooth operation of platforms, but, with the added benefits of decentralization. The intricacies of encryption, content servers, micropayments, ZKANN 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 a little extra money in their wallet.

In many ways, DSP will be the epitome ofvisions of the early Internet, but instead of decentralization at the domain level, we completely decentralize the network of users, giving them control and privacy where they need to be, i.e. in their hands.

I have refrained from reviewing the state of the art andthe latest developments in the field of decentralization technologies. It is difficult to do it in part and impossible to do it completely while in a prison cell. I am sure that many of the above ideas are not new, but I hope that my reflections on this issue will be of some use to those who create and use the DSPs of tomorrow.

Author: Ross Ulbricht

Facebook Notice for EU! You need to login to view and post FB Comments!