Original title: "Decentralize Social Media》

Original title: "

Author: Ross Ulbricht

Original compilation: jane, 36 krypton

Guide: Today Twitter announced that it has accepted Musk’s $44 billion acquisition proposal and will complete the transaction this year. Musk said that he hopes to make Twitter more decentralized by enhancing new features of the product and making the algorithm open source to increase trust. In this regard, former Twitter CEO Jack Dorse agreed: Twitter should become a public product at the protocol level, not a company.

The decentralization of social media is a long-term trend. In the case of decentralization, users can fully enjoy the convenience brought by the network, and can also have the control and privacy of their own content. This is the original intention of the Internet. The author of this article is Ross Ulbricht, the founder of SilkRoad. He published this article in April 2021 and talked in detail about some of his thoughts on the decentralization of social media.

Below I describe a decentralized social protocol (DSP) that can help solve or alleviate these problems by giving users control over their own content and taking charge of value creation and transfer within the network. This vision is made possible by allowing users to choose from a multitude of interface providers, content servers, and advertisers, rather than a single platform monopolizing these necessary roles. I will describe decentralized solutions, including those for profile management, privacy protection, hosting, user interface, ad networks, content filters, metadata, and more. In short, this covers all the basic building blocks of social media.

first level title

1. Everything goes to the center

It goes without saying that one of the main design principles of a decentralized protocol is decentralization. However, the tendency towards centralization is strong. Centers form whenever possible, and it takes foresight to predict where centers will take root and grow.

Take the widely used TCP/IP and HTTP protocols on the Internet as examples. When they are adopted, they appear to be completely decentralized. Anyone can create a website, and anyone can access it, as long as they have an Internet connection and an IP address. What could be more equal than this? We saw the early web thrive in this environment. However, no one foresees that network effects will play a leading role.

Today, anyone can build a website that competes with Facebook, YouTube, Reddit, or Twitter. But it doesn't matter anymore, because no one will use it. It could have better privacy protections, better features, and be ad-free, but it doesn't have the insurmountable advantage these tech giants have: other users. Even Google, which has a huge user base, tried to compete with Facebook by building Google+, but after spending 7 years and billions of dollars, it ultimately failed.

In the context of TCP/IP and HTTP protocols, decentralization stops abruptly at the URL. Whoever controls the URL controls everything behind it. As a result, URLs like facebook.com, google.com, amazon.com, and others have made some of the most powerful and valuable companies in the world.

Under DSP, we have to go even further.

Since centralization will creep and grow wherever it can, decentralized social protocol designers and developers must do everything in their power to prevent centralization. Unfortunately, this requires imagination and hard work. It is much easier to achieve partial decentralization and leave the really hard parts to others or fill in the gaps with your own centralized platform. Tech giants have achieved partial decentralization. They don't generate content, that's left to the user. Decentralized social protocols must have their centralized functions, and design a system that also decentralizes these functions.

first level title

2. Who controls the content?

Information is fundamentally different from physical assets and can be replicated essentially at no cost, so people can get confused when they talk about "owning" data. Copyright law exists to counter this inherent abundance of information and prevent duplicative copies (for the benefit of content creators). The same goes for laws about secrecy, which penalize those who share information without consent. But P2P file sharing broke those laws; whistleblowers broke secrecy laws. It becomes very difficult to control information and prevent its spread.

In a decentralized system, a central authority cannot be relied upon to enforce such laws, so we must process information on pre-specified terms. We're not talking about who owns user content, but who has access to user content. The default position of modern social media platforms is that the platform owns the content and enforces access centrally. Under DSP, content creators (users) should use encryption schemes involving key sharing to control access. Where possible (and ideally), service providers do not have access to unencrypted user content, only those whose creators have granted access to it.

Encryption puts control directly in the hands of key holders, so where we keep cryptographic keys in a decentralized social protocol will point us in the right direction as we look for places where we can curb centralization. Keys must be in the user's hands as much as possible (and ideally). Unless specifically created for the public, all information, whether stored or transmitted, should be encrypted by default.

Again (like the early internet), anyone can build a competing website or application. Only this time, instead of empty-handed, users will be in control of all their own content and the rest of the content they have access to. Switching costs for users will be minimized as the new website will simply be a new interface for the same content. Such an environment will allow innovation to flourish, expand user choice, and dramatically improve every aspect of the user experience.

first level title

3. Money matters

Social media platforms bring in tens of billions of dollars in revenue every year. Almost all of this revenue comes from advertising. Ignoring the funding problem is simple, let the decentralized social protocol service provider invent its own business model, and hope that the provider can perform well and meet the needs of users when the switching cost of users is low. However, assumptions built into the protocol have led to the way our world is today.

This is probably the most challenging part of DSP design, but it's also arguably the most important. Regardless, users must be at the center of this value creation and delivery process. Considering that user attention is the source of system value, this problem should be surmountable.

first level title

4. Reframe social media

Keeping the above design principles in mind, let’s take a look at the relationships among stakeholders of next-generation social media platforms and how these relationships should be reconstructed under DSP.

Figure 1 depicts the four components that make up the current platform-centric paradigm. There are three stakeholders: platform (red), advertiser (green), and user (blue). Everything goes through the platform. The platform owns and centrally controls the content server, stores the content generated by users through its interface, and extracts some content from the content for display. Crucially, the platform serves as a link between users and advertisers. Advertisers pay the platform to display ads to users, which generates clicks for the advertiser. Under this architecture, the platform holds all the keys. It controls all the value generated by the system.

Under DSP, the system must be user-centric. As shown in Figure 2, the user is the link between the other three stakeholders: interface provider, content server and advertiser. Instead of a platform acting as a link between users and advertisers, advertisers pay users directly to place ads on the user interface through bidding. Interface providers and content servers will then compete for this advertising revenue. It is no longer a single platform that provides an interactive interface, but many interface providers can provide users with their services. Instead of platforms owning and controlling all content, content servers compete to host users' encrypted content. Under the decentralized social protocol, users can control all keys and control all value generated by the system.

This user-centric paradigm requires a rethink of how online services are designed and built. Current platforms can be broken down into three parts: content, user interface, and what is sometimes called "business logic". "Business logic" is all the instructions the platform uses to collect relevant content and send it to the user interface for display. This is where the algorithms to search, sort and manipulate content come in. Recommendation engines, aggregators, and various forms of artificial intelligence are all business logic.

Figure 3 simply demonstrates how to deliver content to users through the current centralized platform. The user makes a request through the UI, and the UI passes the request to the business logic server (steps 1 and 2). The server determines what content is needed, and fetches it from the content server (steps 3 and 4). The content to be displayed is then prepared and sent to the UI, which displays it to the user (steps 5 and 6). Business logic and content servers are controlled by the platform and run on the platform's computers, while user interfaces (such as browsers or applications) run on users' computers.

Under DSP, since the UI providers do not have access to the content, they cannot execute the business logic themselves. This has to be done on the user side through the so-called "user client". A user client is simply an application or browser plug-in that performs business logic and manages a user's profile and wallet. The function of the interface provider is then just to send the business logic to the user client instructing it to collect the content and compile it for display through the user interface.

For simplicity, advertisers are not shown in Figures 3 and 4. If advertisers are added, they will be connected between the business logic server in Figure 3 and the user client in Figure 4. More complex relationships are also possible. For example, a user client can modify the initial request before it is sent to the interface provider based on user settings, wallet balances, or any other locally stored information. All of this is not shown in the graph, so the graph only sees a basic reorganization of the social network.

first level title

5. What is a social network?

So far, we've been discussing design principles at a fairly high level. The remainder of this article discusses ideas on how decentralized social protocols might work in practice. Think of them as starting points for discussion, not final answers.

What is the core of DSP? If we look at the major social media platforms, we see that Twitter focuses on short public statements, Facebook emphasizes sharing with friends, Reddit focuses on niche communities, Instagram focuses on pictures, YouTube focuses on videos, and so on. We don't need to copy a decentralized version for each of them, because their essence is the same, the difference is only in the way of communicating and sharing content with others. That's all. Dealing with DSP design from this level of abstraction can simplify it as well as maximize it.

All of the social media platforms listed above, and many more, whether existing or not yet imagined, should be able to run on the DSP. The dimensions of differentiation of these platforms (and any communication platform) are as follows:

content type

content access

context

1) Content Type

There is no intrinsic distinction between video, image, audio, text, or any other content type. They can all be reduced to 1s and 0s and need to be handled in the same basic way. Storage, access, context, and various metadata (just to name a few) should be handled the same way by the DSP regardless of content type. Instagram, YouTube, and SoundCloud are basically the same site, they just emphasize different types of content. DSP should be abstracted so that all content - including new content types (eg VR, haptics) - can be supported.

2) Content access

Public tweets, friend status updates, group chats, private messages, they all vary depending on the access rights to the content. DSPs will need to use encryption to ensure only those with permission can view content, but also be flexible enough that interface providers can devise a wide variety of schemes for sharing content.

Public content is easy to handle, since everyone can view it, so no encryption is required. In order to restrict access, we need encryption. One way to do this is to use symmetric cryptography to encrypt content so that only those with a key specific to that content can view it, and then use asymmetric cryptography to distribute that key to the parties sharing the content .

Needless to say, this complexity is hidden from the user's eyes. Users just need to know that new content has been shared with them.

By default, service providers (interface providers and content servers) cannot access unencrypted content.

3) Context

When it comes to communication, context matters. Depending on the context, a joke can become a threat, and a troll can be a philosopher. All content has context, so DSPs must have a robust way to capture context as metadata so it can be rendered as the content creator intended.

Often, the context of content is other content: a comment or like on a video, a thumbs down, a retweet, etc. A simple pointer to what is being referenced will suffice. However, this and all content needs to be categorized.

We need to integrate a system into a decentralized social protocol that can capture everything from subreddits to Moments, from LinkedIn-style sites to blogs. One way is to use tags. I suggest collecting contextual taxonomies from current platforms and compiling a list of tags. These should not be hardcoded into a decentralized social protocol, but should be open as documentation for service providers to learn from and add to.

Usually, this complexity should be hidden from the user. When users create content, they often don't consciously think about context, they just know they're tweeting a question, posting to the cat master meme subreddit, or clicking the heart icon next to their favorite video. Generated content should be automatically tagged according to the business logic of the interface provider used (see below for more information). That way, no matter what interface is used, when a user generates content, other interface providers know how to interpret and display the content to the user.

For example, if someone likes your content on a Twitter-style site and another person likes you on a Facebook-style site, everyone who views your content will see both, no matter which site they use. Like.

By tweaking these three parameters, all of the various platforms can be replicated using a decentralized social protocol. More importantly, in the absence of network effects, other social media and communication services that failed to gain audiences should now find that they can serve the needs of niche communities.

For example, for a twitter-style service, content generated using its interface (tweets) could be marked as such. The interface does not allow user-generated content to exceed 280 characters, so anything marked as a tweet on the interface will be limited to 280 characters. If a user independently generates a tweet longer than 280 characters, the twitter service will not display it to other users.

first level title

6. Configuration file management

The user is the link that brings life to the DSP protocol. A major challenge for decentralized protocols when dealing with user profiles is namespaces. Centralized platforms handle their namespaces by keeping a list of all registered usernames in one place and checking for duplicates when a user tries to register a new name. (Of course, users must re-register on each platform they use, and may find that the username they registered on one platform has already been taken by someone else). Things are not that simple for a decentralized protocol. There is no central list to query, and no central authority to reject duplicates.

However, we can turn to cryptography for a solution. . Public key cryptography will make it easy for anyone to create public and private key pairs through any interface provider. The public key represents your identity in the decentralized social protocol network, while the private key will be kept by your user client and used to prove that it is you behind that identity. The public key is generated pseudo-randomly, so the chances of two people generating the same key are very small and can be safely ignored. look! Now you have a unique name and identity on the web. But who wants their name to be a random string of characters?

One way to deal with this is the same way you deal with it in the real world: let people call themselves whatever they want, ignoring repetition. Then, if you're not sure who you're dealing with, just check the unique ID.

Another approach is to set up a name server scheme, similar to how unique IP addresses are translated into unique domain names. In this example, the public key is analogous to an IP address, and the username is analogous to a domain name. To achieve decentralization, user clients and interface providers can keep lists of all key/name pairs they encounter. When registering a new name, the user client can "ask" the network if the name is on anyone's list. If not, a new key/name pair is announced. If the user comes across a name that's already been reused in the list, the interface might disambiguate it with a random number (1, 2, 3, etc.) or some other distinction.

Another solution is to use a blockchain to record unique key/name pairs. The problem with registering on the blockchain is that it invades privacy. Blockchains are necessarily public, but not all users care so much about namespace duplication that they want the world to know their decentralized social protocol identities. They might just use a decentralized social protocol to connect with friends and family, and disambiguation isn't a huge concern.

Blockchain registration also requires the payment of a fee denominated in the blockchain’s native token. This creates a problem because new users have been using modern platforms for free for decades, and it is impossible for them to pay to use the DSP anymore.

The choice should be decided by the user, this is not a problem that the user has to consider and deal with, but a problem that the user client or interface provider needs to consider and deal with. Whether it's a blockchain, a name server, or simply polling connected people in the network, there are trade-offs between cost, privacy, and decentralization. Under the hood, this can be solved with public keys, but the interface provider has to figure out some way to handle matching usernames to public keys.

Below I describe a decentralized social protocol (DSP) that can help solve or alleviate these problems by giving users control over their own content and taking charge of value creation and transfer within the network. This vision is made possible by allowing users to choose from a multitude of interface providers, content servers, and advertisers, rather than a single platform monopolizing these necessary roles. I will describe decentralized solutions, including those for profile management, privacy protection, hosting, user interface, ad networks, content filters, metadata, and more. In short, this covers all the basic building blocks of social media.

first level title

7. Reputation management

Now that we have user profiles, let's see how these user profiles relate to each other. In a perfect world, social networking would be a place for civilized, informed discussion, guided by mutual respect and shared decorum. Obviously, we don't live in a perfect world. Social media users are more like an unruly mob, and there is growing pressure on the platform to moderate content. Platforms find themselves in the awkward position of not being able to decide what content is and isn’t available to their billions of users. No matter what they do, some users will still be unhappy.

Decentralized social protocols avoid this problem by decentralizing the responsibility of scoring user reputations. Instead of dictating the entire user base, each platform maintains a rating list of likes and dislikes by other users and shares that list with the rest of the network. This idea is called the Web of Trust (WoT), and it's a very simple way to minimize the influence of bad actors in a decentralized system. It's an online version of what we do in the real world.

Suppose someone on the fringes of your social circle invites you for coffee, how do you know if you should accept or not? If everyone says he's aggressive or boring, you probably won't go on the date, if they comment positively, and vice versa. WoT works on the same principle. Instead of placing all your trust in one platform, get a lot of input from people in your network that you already trust, and they get input from you. Of course, WoT is handled at the protocol layer, so users don't have to worry about specific issues.

Care needs to be taken when designing a WoT implementation for DSP. It should be as abstract as possible to accommodate unforeseen applications and leave decision-making power to the user. Here's how it might work: Suppose a user named spambot2020 keeps posting links to get-rich-quick schemes in your crafted public messages. You should be able to mark this offensive content as spam. Content from this account will no longer be visible to you. What's more, it won't be in front of people who trust you either. The tag may be another piece of content tagged and shared under the content access and context system of the decentralized social protocol.

Not all decisions are as easy as labeling an account as spam, and blocking all posts from an account at once may not be the best option. Fortunately, WoT is highly flexible, allowing each user to determine how to interpret and process signs in their network. Tags can have different labels (e.g., spam, hate, bullshit, bot, like, smart, funny) and can be weighted differently based on user preferences. If someone you trust strongly trusts other people who like a song, chances are you'll like it too. Your own logo and other people's logos are automatically added together to help the interface provider determine what to show you and how prominently it is.

This is something that existing platforms are already doing, each with their own proprietary algorithms. Under DSP, the underlying structure and content of the WoT layer are controlled by users, so they can choose any interface they want, and then interface providers will have more varieties and provide more choices.

This reveals the real beauty of WoT: no centralized perspective. If I flag someone as a troll, they are only a troll in my eyes. It's not the "truth". Some users can accept my judgment and certainly ignore it, while others can see this label as a positive and see it as a "badge of honor".

However, WoT is not just for filtering bad content. It is also a decentralized system that helps users choose business partners they can trust. As we will see below, the WoT will be invaluable in solving the difficult problem of how value is created and transferred between users, advertisers, and service providers.

first level title

8. Value creation and transfer

Social media platforms make money by selling advertising space. Their platform is free and open to the public, but in addition to the content that users log into, there are advertisements. Controversially, the platform uses users' personal data and content to categorize users in order to help advertisers better target potential customers. Under DSP, service providers cannot access user content, while users can. Therefore, this successful ad-driven business model needs to be redesigned if we are to fully decentralize social media.

Currently, platforms act as trusted intermediaries between advertisers and users. Advertisers pay the platform, trusting that their ads will be shown to users at the agreed frequency. Advertisers are starting to look at the platforms that drive the most traffic to their links, but it's the users that they're really looking at. It's users who create value by seeing a brand's ad, clicking on it and ultimately buying, or doing what the advertiser wants them to do. Users create value, so users should be paid.

However, platforms do provide a valuable service to advertisers, so we must ensure that DSPs do the same. For example, DSPs must ensure that ads are not served to a bunch of fake accounts set up solely for ad revenue, and that the correct ads are shown to the correct users. WoT provides an elegant solution for this.

Here's how it might work: Advertisers bid for an ad spot for each user they wish to target, and users earn revenue from each ad that appears on their screen. The user's client cryptographically signs the ad and sends it to the advertiser so the advertiser knows that his ad has been seen. If a user clicks on an ad, the advertiser also knows this because the user lands on the advertiser's website. If the user does something the advertiser wants them to do (such as make a purchase or click a link), the advertiser sends the user a signed receipt containing the value of the user action, when it occurred, and other metadata.

This means that every step of the way, users have proof of the value they created, which they can share publicly to attract more advertisers to bid for their ad slots. In WoT, a signed receipt is like a symbol of trust. If users try to take advantage of the system and sell themselves ads through a dummy account, that's fine too, since those dummy accounts don't have any trust relationship with the real advertisers and they'll just be ignored. So, the more times users click on the ad, the more they can prove to other advertisers that they are a good investment, and the more money they can make. To some extent, this type of advertisement is more targeted than that provided by existing platforms, the user's content will not be shared, and the user's privacy will not be violated.

There is a problem with this architecture, but cryptography can provide a solution. A user might want to let an advertiser know that they clicked an ad and spent $300 on the site they landed on, but if the site sold certain drugs or accepted donations for a political party, the user might not want to let that be known. people know. Technically, users can choose not to disclose tokens from such sites, but all these complexities should be hidden from users anyway. We don't 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 the user's main profile should be created specifically for the user's interaction with the advertiser. Therefore, the user's reputation and value to the advertiser will be tied to the randomly generated public key. Advertisers will know a user's shopping and clicking habits—very valuable targeting information—but not who they are or what they're doing and what to share on the DSP.

An open question is what payment system to use to make this happen. I don't think DSP should answer this question, but let third-party developers create plugins. An initial plug-in for a popular payment system supporting micropayments can be developed with DSP to kickstart the work. Even better, a decentralized payment protocol (DPP) can be deployed.

first level title

9. Service

Now that users have money, let's talk about how to pay for the necessary decentralized social protocol services in a decentralized way.

1) Content storage and access

One of the services provided by centralized platforms is the storage and delivery of content on demand. Data centers all over the world are dedicated to this task. For a DSP to be truly decentralized, the service must also be decentralized. There cannot be a single entity responsible for this. Anyone must be able to provide this service with very low barriers to entry, and users must be responsible for how their data is handled. With users controlling advertising revenue, there is a fierce competition for content servers to try to deliver content as quickly as possible at the lowest possible cost.

Here's how it might work in practice: a user searches for a piece of content, and the content server replies with an offer. The user client weighs responsiveness and price, then sends the payment to the best server, where the content is delivered. Of course, all of this will be handled by algorithms in a split second, without human intervention.

Setting up a content server shouldn't require much technical skill. People who are already running web services can install software that takes advantage of excess storage space and bandwidth for this purpose. Even home computers and other devices can do this.

WoT can make this system run more smoothly. Instead of bidding and establishing deals for each piece of content, content servers and users who trust each other can exchange content and pay more loosely. Essentially, content servers can extend credits to users who have built a reputation for adhering to the agreement, or to new users who want to establish a WoT connection.

Both parties can try different algorithms. An explore/exploit (explore/exploit, E/E) algorithm can be deployed by users looking for the cheapest, fastest and most reliable servers on the network. On the server side, they want to store the most valuable content possible: the most frequently accessed content.

How it works in practice will be complicated as access (demand) is offset by availability (supply). Better to be the only server hosting 1000 visits per day than one of a million servers hosting 1 million visits per day. The server will try to use different algorithms when grabbing business.

However, some content may be accessed so infrequently that no server is willing to host it. Maybe it's a private message between two people that is rarely re-read. There is a fee to store this content. Likewise, servers can compete for the privilege of storing your archived content. Users need some redundancy 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 very cheap, at or close to cost. Given that excess server capacity can be used at zero marginal cost, and some value may be placed on customer acquisition and WoT scoring, data services may even be provided for free in some cases.

2) User interface

Of course, another crucial piece of the decentralized social protocol puzzle is the user experience when interacting with the network. It's what most of us think of when we think of social media: content feeds, friend lists, inboxes, homepages, avatars, forums, chat windows, and so on. Unsurprisingly, platforms monopolize the user experience of data with the datasets they control. For example, there is only one place to view your Facebook profile, facebook.com.

This has to be decentralized at the DSP so that any website or app can display your content without accessing it. Because users are in control of their own content, all they need from the interface provider is an intuitive and fun way to interact with the content. Rather than just having one Twitter layout on twitter.com, anyone should be able to build a service for users and experiment with different ways to generate and interact with content.

Imagine a Facebook-style homepage. On the left is your friend list, in the middle is your friend's updates, and on the right are some advertisements. Let's say you're viewing this content through an app on your tablet. When you open the application, the business logic is extracted from the interface provider, which tells the application how to generate the pages. Essential information, such as profile, keys, and wallets, is stored locally with the user client as part of the application. If it's a fresh install of the app, and you already have a pre-configured profile, the app will fetch the encrypted user profile from the content server and you will have to enter a password.

The app will accept the advertiser's highest bid, credit your wallet, and display the ad on the right. It will fetch your friends list from content servers, along with related content such as pictures and posts to which you have been granted access. The app will sort and display all content using algorithms in the business logic obtained from the interface provider.

For this purpose, the interface provider may receive a fee from the advertising revenue generated. As with content servers, intense competition among interface providers may arise due to the very low switching costs for users. As a result, users and advertisers no longer turn to platforms that control content and interfaces. Advertisers, content servers, and interface providers all move closer to users, competing for their attention and value.

One problem that arises with this design is that it is not possible for services that depend on access to user content. For example, how can users search their private messages by keyword if those messages are encrypted and distributed across multiple content servers? Ideally, we would not open Pandora's box and allow service providers to access content, even under the guise of serving users. That's why we're in our current predicament. Thankfully, there is often a creative solution that allows users to have both privacy and functionality.

In the search example above, the interface provider could send the user client an algorithm that indexes the user's content by keywords and stores this index in a separate file that is only accessible to the user. When a user wants to perform a search, the client's terminal searches the lighter index file, and then searches only for content that matches keywords in the index.

This is an example of user-centric rather than service-centric engineering. It preserves privacy, and as client-side processing power continues to scale, putting the user at the center of things won't be a problem for most applications.

However, in the case of decentralization, the user's main difference is the responsibility to remember and protect the encryption key passphrase. If you forget your password, there is no platform you can go to reset it. Any other solution to this problem would give third parties access to your content.

Perhaps a multi-signature encryption scheme could be employed, in which several trusted collaborating parties can recover an individual's password. This way, no one alone can access or access your content, only when you need to recover your password.

But in the end, user-centric systems empower users, and with power comes responsibility. Given the hacks and data breaches of major platforms in recent years, this is something users should want to take on. No one cares more about your privacy and security than you.

3) Edge use cases

We know that social media platforms are profitable, so in general, advertising revenue outweighs all the services offered by the platform. Therefore, we should expect the vast majority of DSP users to have their advertising revenue cover the costs of their content server and interface providers. Still, it is instructive to look at three edge cases.

At one extreme, there may be users who do not generate enough ad revenue to cover their costs. If a user never clicks on an ad, the advertiser will eventually stop paying for those ads to be displayed. However, brand advertisers may still be willing to pay a small fee to allow some content to be published. At worst, such users can simply host their own content, avoiding the convenience offered by the service provider. Or better yet, they can become their own service provider, making enough money to cover their own DSP usage needs.

The last scenario we consider is that of some solitary users who would rather see no ads and not receive any advertising revenue, and pay for decentralized social protocol services out of their own pockets. Such users will have to recharge their decentralized social protocol wallets themselves, and the recharge amount will slowly be depleted.

first level title

10. Content Issues

Every solution to a problem sows the seeds for a new set of problems. Take the internal combustion engine as an example. That's a huge improvement over horsepower. It removed horse manure from city streets, liberated capital, and vastly expanded our capabilities. No one wants to go back to the days of the horse-drawn cart and the plow, but we must address air pollution, car accidents, and other problems. If electric, self-driving cars can solve these problems, we can be sure that they will eventually become the source of new problems that our descendants will have to solve.

DSP solves the problems caused by network effects and centralization of social media platforms. Once adopted, no one wants to go back to a time when there was no privacy and only one interface choice. However, we will definitely have a new set of problems to deal with. One obvious problem -- one that we eventually have to address -- is what I call the "content problem."

As mentioned above, we can expect DSP to produce a censorship-free realm. If one interface censors users' content, they can move to another interface that doesn't. If the user is pointing out a human rights violation, or simply exercising free speech, then that's a good thing. However, not everything is free speech. Some content is harmful because it directly or indirectly causes harm to innocent people.

If DSP becomes the vehicle for distributing this kind of content, no one wants to have anything to do with it. Interface providers, content servers, advertisers, and developers behind decentralized social protocols will not contribute their talents and resources to this. Regular users will not have access to all the benefits of decentralization described above. Decentralized social protocols will fail miserably.

first level title

in conclusion

in conclusion

Today's social media platforms wield enormous power in capturing users' attention and the value they create. Platforms lock people in through network effects and can cater to advertisers, even at the expense of users. Platforms have developed sophisticated algorithms to exploit common weaknesses in the human psyche. Vanity, voyeurism and anger keep users staring at the screen, clicking, swiping and swiping, wanting to see more so more ads can be shown.

Under DSP, everyone's motivation is to serve the user, and the user will use the interface they value most. Personally, I want to use an interface that makes me feel calm, happy, connected to people I care about, and fulfills me.

For DSPs to be successful, they must provide the seamless experience that platforms provide, with the added benefit of decentralization. The complexities of encryption, content servers, micropayments, ZKANN, and ad networks must be hidden from ordinary users. They just need to know that the system works and sometimes even brings users extra revenue. In many ways, DSP will realize the vision of the early Internet, but instead of decentralizing to the domain level, we will decentralize all the way to users, putting control and privacy in the hands of users themselves.