How to revolutionize and decentralize social media? The founder of the Silk Road conceived the idea in prison

How to revolutionize social media and decentralize it? Silk Road Founder Ideas From Prison

Original source: chain smell

The centralization of social media networks has created a host of problems for social media platforms and their users. These include violations of privacy and the impossible task of auditing the content of billions of users.

What I describe below is a "Decentalized Social Protocol" (DSP) that can help solve or mitigate these problems by giving users control of their own content and putting them in charge of value creation and transfer within their network. This is possible by allowing users to choose from a multitude of interface providers, content servers, and advertisers, rather than having a single platform monopolize these essential roles.

I'll describe decentralized solutions for profile management, privacy protection, hosting, user interfaces, AD networks, content filters, metadata, and more. In short, this covers all the basic components of social media.

Principle: everything goes to the center

Needless to say, one of the main design principles of a decentralized protocol is decentralization. But the tendency towards centralisation is strong and centres will form whenever possible, and it takes foresight to predict where they will take root and grow.

Take the TCP/IP and HTTP protocols, which are widely used on the Internet. When they are adopted, they seem to be completely decentralized. Anyone can set up a website, and anyone can access it, as long as they have an Internet connection and an IP address. What could be more egalitarian than that? In the early days of the web, we saw what could be expected to flourish in such an environment.

But no one predicted that network effects would take over.

Anyone can now build a website that competes with Facebook, YouTube, Reddit or Twitter. But no one will use it. It may have better privacy, better features and no advertising, but it doesn't have the other factor that gives these tech giants an insurmountable advantage: other users. Even Google, which has a huge user base, tried to compete with Facebook by building Google+, and after seven years and billions of dollars, it failed.

Under TCP/IP and HTTP, decentralization comes to a screeching halt at URLs. Whoever controls the URL controls all of the content of the URL. As a result, URLs like Facebook.com, Google.com, Amazon.com and others have become some of the most powerful and valuable companies on the planet.

With decentralized social protocols, we have to go even further.

In the social environment, the smallest, unconstrained unit is the individual, the user. So when we talk about decentralization, we're talking about putting all the decision-making power and authority in the hands of the users. Simply giving them the power to set up websites and choose which ones to visit is no longer enough.

Since centralization will spread everywhere possible, designers and developers of decentralized social protocols must do everything they can to prevent it. Unfortunately, it takes imagination and hard work. It is much easier to achieve incomplete decentralization, leaving the really hard parts to others or filling in the blanks with your own centralized platform. The tech giants have partially decentralised. They don't generate content, that's left to the user. Decentralized social protocols must have the functionality they already implement centrally, and design a system that decentralizes those functionality as well.

Who controls the content?

Information is fundamentally different from physical assets. Information can be copied almost free of charge, so there can be ambiguity when people talk about "owning" data. Copyright law exists to counter this richness inherent in information, to prevent duplication (and to protect the interests of content creators). Classification and confidentiality laws also penalize people for sharing information without their consent. P2P file sharing, however, undermines these laws; The emergence of whistlers has also broken secrecy laws. It becomes very difficult to control information and stop it from spreading.

In a decentralized system, a central agency cannot be relied on to enforce such laws, so we must process information on predefined terms. We're not talking about who owns user content, we're talking about who has access to user content.

The default position of modern social media platforms is that they own the content and centrally control access. Under a decentralized social protocol, content creators (users) should control access using an encryption scheme involving key sharing. Whenever possible (ideally), unencrypted user content cannot be accessed by a service provider, and only those whose creator has granted access to it can access it.

Encryption puts control entirely in the hands of the key-holder, so the location of the encryption key in a decentralized social protocol will point the way as we look for places where we can curb decentralization. The key must be managed by the user as much as possible (ideally). Unless specifically created for the public, all information, whether stored or transmitted, should be encrypted by default.

This is a radical shift from the current paradigm. With users in control of their own data, network effects lose their only place. If the content and associations that make up the various social networks are managed at the protocol level, the site will lose its monopoly on users.

Once again (as in the early days of the Internet), anyone can build a competing website or app, only this time users will be in control of all their own content and whatever else they have access to, rather than empty-handed. Switching costs for users would be minimal, as the new site would simply be a new interface for the same content. Such an environment will allow innovation to flourish, expand user choice, and dramatically improve all aspects of the user experience.

Money is critical!

Social media platforms generate tens of billions of dollars in revenue each year, almost all of which is generated by advertising. It's easy to ignore the money issue, let the decentralized social protocol service providers invent their own business models, and hope that they can perform well and meet the needs of their users with low switching costs. But the assumptions built into the agreement led to the world as it is today.

We must face the fact that money is a key element of centralisation. Users bring in advertisers, and advertisers bring in money, and money pays for the expansion and development of services, and better services bring in more users. Money is crucial to this feedback loop, which draws everyone to the same service provider, whose real business is to match ads for users' eyeballs.

This is probably the most challenging part of designing decentralized social protocols, but it is arguably the most important. In any case, the user must be at the heart of the value creation and transfer process. Given that user concerns are the source of system value, this problem should be surmountable.

Reconstruct social media

With the above design principles in mind, let's take a look at the relationships among stakeholders in a modern social media platform and how these relationships can be reconstructed within a decentralized social protocol.

Figure 1

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

Figure 2

Supported by decentralized social protocols, the new system must be user-centric.

As Figure 2 shows, users are the link between three other stakeholders: interface providers, content servers, and advertisers. Instead of a platform acting as a link between the user and the advertiser, the advertiser pays the user directly and bids to place ads on the user interface. Interface providers and content servers would then compete for that AD revenue. Instead of a single platform providing interactive interfaces, many interface providers can provide their services to users. Instead of a platform owning and controlling all content, content servers compete to host users' encrypted content.

With a decentralized social protocol, the user can control all the keys and control all the value generated by the system.

This user-centric paradigm requires a rethink of how online services are designed and built. The current platform can be divided into three parts: the content, the user interface, and what is sometimes called the "business logic." Business logic is all the instructions that the platform uses to collect relevant content and send it to the user interface display. It is an algorithm for searching, sorting, and processing content in real time. Recommendation engines, aggregators, and various forms of AI are all business logic.

Figure 3

Figure 3 provides a simplified illustration of how content can be delivered to users through the current centralized platform. The user makes a request through the user interface, which passes the request to the business logic server (Steps 1 and 2). The server determines what content is needed and then fetches it from the content server (steps 3 and 4). The content to be displayed is then prepared 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 platform's computer, while the user interface (such as a browser or application) runs on the user's computer.

Under decentralized social protocols, because the interface providers do not have access to the content, they cannot perform business logic on their own. This must be done on the client side through what is called the "user client".

The user client is simply an application or browser plug-in that executes business logic and manages the user's profile and wallet. The interface provider's function then is simply to send the business logic to the user client, instructing it to collect and compile the content for display through the user interface.

Figure 4.

Figure 4 illustrates how this works. The user again makes a request through the user interface, which is passed to the interface provider's business logic server (Steps 1 and 2). The interface provider then sends the appropriate business logic back to the user client at the user (step 3). The user client executes the business logic -- gathering content from the content server as needed -- and sends the output to the user interface for display to the user (steps 4 through 7). Step 6, which is performed between the user client and the user interface, is run locally on the user device. A single application or browser with a decentralized social protocol plug-in can handle both the user client and the interface, so the user client can be "in the background" from the user's perspective.

For simplicity, advertisers are not shown in Figures 3 and 4. If the above operation is indeed working well, the business logic server is connected in Figure 3 and the user client is connected in Figure 4.

More complex relationships may also be possible. For example, the user client can modify the initial request before it is sent to the interface provider based on user Settings, wallet balance, or any other locally stored information. None of this is demonstrated in the figure, so what you see here is a basic reorganization of the social network.

What is a social network?

So far, we've been talking about design principles at a relatively high level. The rest of this article discusses the idea of how decentralized social protocols would work in practice. Think of them as a starting point, not a final answer, to this question.

What is a decentralized social protocol, in essence? If we look at the major social media platforms, we'll see Twitter with its emphasis on short public statements, Facebook with its emphasis on sharing with friends, Reddit with its focus on niche communities, Instagram with its focus on pictures, YouTube with its focus on videos, and so on. We don't need to duplicate a decentralized version of each of them, because they are essentially the same, only different in the way they communicate and share content with others. That's all.

Designing decentralized social protocols from this level of abstraction both simplifies it and maximizes its coverage.

All of the social media platforms listed above, many of which exist today and some of which are yet to be imagined, should be able to run on decentralized social protocols. The dimensions that distinguish these platforms (and any communication platform) are as follows:

Content type

Content access

context

Content type

There is essentially no difference between video, pictures, audio, text, or any other type of content. They are both degradable to the numbers 1 and 0 and need to be processed in the same basic way. Storage, access, context, and various metadata, decentralized social protocols should be handled in the same way regardless of content type. Instagram, YouTube and SoundCloud are basically the same site, just different types of content. Decentralized social protocols should be abstracted so that all content can be supported, including new content types (e.g., VR, haptics).

Content access

Public tweets, status updates to friends, group chats, and private chats; They vary depending on who has access to the content. Decentralized social protocols will need to use encryption to ensure that only licensed people can view content, but be flexible enough so that interface providers can design a rich variety of content-sharing mechanisms.

Exposure content is easy to work with because everyone can access it, so no encryption is required. To limit access, we need encryption. One approach is to use symmetric ciphers to encrypt the content so that it is only accessible to those who hold a key specific to the content, and then distribute that key to the party (or parties) that shares the content using asymmetric ciphers.

Needless to say, this complexity doesn't show up to the user. 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.

context

When it comes to communication, context is crucial. Depending on the context, a joke can become a threat, and a gag can become a sage. All content has its own context, so a decentralized social protocol must have rich ways to capture context as metadata so that content can be presented as intended by the creator.

The context of the content is often other content: comments or "likes" of the video, retweets of negative votes, etc. A simple finger pointing to the referenced content is sufficient. However, this and all content needs to be categorized.

You need to integrate a system into a decentralized social protocol that can capture everything from subreddit to Moments, from pnkedin-style sites to blogs. One way is to use tags. I suggest gathering context categories from the current platform and compiling a tag list. These should not be hard-coded into decentralized social protocols, but should be open as documentation for service providers to learn from and add to.

As usual, this complexity does not affect what appears in the user's view. Users often don't consciously think about context when creating content, they just know that they're tweeting, Posting to MBlockquotee subreddit, or clicking the heart-shape icon next to their favorite video. The generated content should be automatically tagged based on the business logic of the interface provider used (see below for more information). This way, no matter what interface you use, other interface providers will know how to interpret and display the content to their users when the user generates it.

So if someone "likes" your content on a Twitter-style site and someone else "likes" your content on a Facebook-style site, everyone who views your content will see two likes, no matter which site someone else is on.

By tweaking these three parameters, you can replicate all kinds of platforms using decentralized social protocols. More importantly, other social media and communications services that have failed to gain an audience should now discover that they can meet the needs of niche communities without having to fight against network effects.

One could argue that there is a lack of "content constraints" in the three lists above. Isn't Twitter different by limiting users' tweets to 280 characters? This is certainly the case, but a decentralized social protocol does not need to deal with content constraints because it can be implemented through context.

For example, when using a Twitter-style service, content generated with its interface (tweets) could be tagged like this. The interface does not allow users to generate content that is more than 280 characters long, so anything in the interface that is tagged as a tweet cannot be more than 280 characters long. The Twitter-like service does not simply show tweets of more than 280 characters to other users if they are being independently generated.

Personal Data Management

Users are the key to bringing decentralized social protocol protocols to life. The main challenge with decentralized protocols when working with user data is namespaces. A centralized platform handles its namespace by putting a list of all registered user names in one place and checking for duplication when a user tries to register a new name. (Of course, users will have to re-register on each platform they use, and may find that the user name they registered on one platform has been taken by someone else on another).

For decentralized protocols, things are not so simple. There is no central list to query, and no central authority to refuse to repeat.

However, we can use cryptography to come up with solutions. 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 a decentralized social protocol network, while the private key will be retained by your user client and used to prove that you are behind that identity. The public key is pseudorandom generated, so the chance that two people will be born with the same key is very small and can be safely ignored. A: wow! You now have a unique name and identity on the network. But almost no one wants to be identified as a random looking string.

One way to deal with this problem is the same as in the real world: let people call themselves what they want and ignore repetition. When you're not sure who you're dealing with, just check the person's unique ID.

Another approach is to set up a name server mechanism, similar to how a unique IP address translates to a unique domain name. In this case, the public key is similar to the IP address and the user name is similar to the domain name. For decentralization, user clients and interface providers can keep a list of all key/name pairs they encounter. When registering a new name, the user client will "ask around" to see if the name already exists in any lists. If not, announce the generation of a new key/name pair. If the user encounters a name that has been repeatedly used in the list, the interface might disambiguate it with random numbers (1, 2, 3, and so on) or some other distinction.

Another solution is to use the blockchain to record that there are no duplicate key/name pairs. But the trouble with a rule that requires registration on a blockchain is that it erodes privacy. Blockchains are by all means public, but not all users care so much about namespace duplication that they want the world to know their decentralized social protocol identity. They may only use decentralized social protocols to connect with friends and family, and disambiguation is not a big problem.

Blockchain registration also requires a fee denominated in the blockchain's native token. This bothers distribution, because after decades of free access to modern web platforms, new users can't be expected to pay for decentralized social protocols (see below for more). The choice should be in the hands of the user, not something they have to think about and deal with, but something their user client or interface provider should do. Whether it's a blockchain, a name server, or just asking your friends on the network, there's a trade-off between cost, privacy, and centralization. At the bottom level, the public key can solve this problem, but the interface provider has to figure out a way to deal with matching the user name to the public key.

Reputation management

Now that we have user data, let's look at how these user data relate to each other. In an ideal world, social networks would be places for civilized and intelligent discussion based on mutual respect and common decency. Obviously, we don't live in a perfect world. Social media users are more like thugs, and platforms are increasingly under pressure to post only mild content. The platform found itself unable to decide what its billions of users would and would not allow. Whatever they do, it will frustrate some users.

Decentralized social protocols avoid this problem by decentralizing the responsibility of rating a user's reputation. Instead of dictating to the entire user base, each platform keeps a score sheet that is thumb up or clicked on 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 beautiful, simple way to minimize the impact of bad actors in a system. It's an online version of what we do in the real world.

Suppose someone on the edge of your social circle invites you for coffee. How do you decide whether to accept it or not? You ask people in your circle who are accurate in your opinion. If everyone says he's aggressive or boring, then you might not show up if their comments are positive, and vice versa. World of Tanks works on the same principle. Rather than putting all your trust in a single 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 level, so it's not a problem for the user.

When designing WoT landing mechanisms for decentralized social protocols, be careful. It should be as abstract as possible to accommodate unforeseen applications and put decision rights at the user's end. Here's how it might work: Suppose a user named spambot2020 keeps Posting links to get-rich-quick projects in your carefully crafted public message. You should be able to mark the offending content as "spam." The contents of this account will no longer be displayed for you. More importantly, it won't show up to the people who trust you. This tag may be another piece of content tagged and shared according to the content access and context system of decentralized social protocols.

Not all decisions are as easy as flagging an account as spam, and blocking all posts in one account at once may not be the best option. Fortunately, WoT has a high degree of flexibility, allowing each user to determine how to interpret and handle tokens in their network. Tags can be labeled differently (for example, spam, hate, badass, bot, like, smart, funny) and can be weighted differently depending on the user's preferences. If the person you trust strongly trusts other people who like the song, you're likely to like it, too. Your own logo and others' logos are automatically added together to help the interface provider determine what to show you and how eye-catching it is.

Existing platforms already do this, each with its own proprietary algorithms. With a decentralized social protocol, the underlying architecture and content of the WoT layer is controlled by the users, so they can choose any interface they want, and the interface providers will have more variety and more choices.

This reveals the true beauty of WoT: there is no centralized point of view. If I label someone as a goblin, that person is just a goblin for me. This is not the "truth." Some users can accept my judgment and weigh in on the alleged manipulation, others can ignore it, and others can view the label as a positive comment, a "badge of honor."

Crucially, each interface provider will choose how to filter and display content. Users, in turn, will be able to choose from a very rich range of options, and will even be able to change the filtering criteria and interface daily or from time to time depending on their mood. No one will complain about being unfairly gagged or censored anymore, because every user has a voice and every other user has the right not to listen to him or her.

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

Value creation and transfer

Social media platforms make money by selling advertising space. Their platform is free and open to the public, but it also includes advertising in addition to user-selected content. Controversially, platforms use users' personal data and content to categorize ads so that they can help advertisers target potential customers more precisely. Under decentralized social protocols, service providers do not have access to user content, while users do. Therefore, if we are to fully decentralize social media, we will need to redesign this already very successful ad-driven business model.

Currently, platforms act as trusted middlemen between advertisers and users. Advertisers pay for the platform and trust that their ads will be shown to the user type of the agreement at the frequency of the agreement. Advertisers are starting to focus on the platforms that drive the most traffic to their links, but what they really value is users. Users create value when they view a brand AD, click on it, and eventually make a purchase, or do what the advertiser wants. Users create value, so they should be paid.

However, platforms can provide valuable services to advertisers, so we must ensure that decentralized social protocols can do just that. For example, a decentralized social protocol must ensure that ads are not placed in a bunch of fake accounts that may have been created solely to collect AD revenue, and that the right ads are displayed to the right users. This is where WoT comes back into play with an elegant solution.

It might go something like this: Ads bid for AD space for each user that fits their positioning, and users receive revenue for each AD displayed on their screens. The user's client uses a password to sign the AD and then sends it to the advertiser, so the advertiser knows their AD has been seen. If the user clicks on the AD, the advertiser knows this because the user is on the advertiser's website. If the user did something the advertiser wanted them to do (such as make a purchase or click on a link), the advertiser sends the user a signed receipt containing the value of the user's action, when it happened, and other metadata.

This means that at every step of the user's journey, there is evidence of value being created, which they can share publicly in order to attract more advertisers to bid on their AD space. Signed receipts are like trust tokens in WoT. If a user tries to trick the system and sell ads to themselves through virtual accounts, it doesn't matter because these virtual accounts don't establish any trust with the real advertiser and they will be ignored. So the more times a user clicks on an AD, and complies with the advertiser's demands, the more he can prove to other advertisers that he is a good investment, and the more money he can make. In a sense, such ads are more targeted than those currently offered on the platform, and never share a user's content or invade their privacy.

There is a problem with this architecture, but once again cryptography can provide a solution. Users may want advertisers to know that they paid $300 for clicking on an AD and going to the site, but if the site sells certain drugs or accepts donations for a political party, they may not want to let people know. Technically, users can choose not to expose tokens from such sites, but in any case, all of these complexities should be hidden from users. We don't want them to have to make such a difficult decision every time they click on a link.

Instead, create an undisclosed user profile that links to the user's primary profile and is dedicated to the user's interaction with advertisers. Thus, a user's reputation and value to advertisers will be tied to a randomly generated public key. Advertisers will know users' shopping and clicking habits -- useful information for targeting customers -- but not who they are, or what they are doing and sharing on decentralized social protocols.

Advertisers may not analyze and bid on individual users. Surely experts can package users into different categories in different ways, based on their anonymous and publicly available profiles, to suit advertisers. However, this should not cause the problem of centralization. There are few barriers to entry because the underlying WoT data is decentralized and public.

An open question is which payment system will be used to do all this. I don't think decentralized social protocols should answer that question, but rather third-party developers creating plug-ins. The initial plug-in for the popular payment system supporting micropayments can be developed together with the decentralized social protocol to facilitate the launch of the decentralized social protocol. Better yet, you can deploy a Decentralized Payment Protocol (DPP).

service

Now that users have money in their hands, we can talk about how to pay for the necessary decentralized social protocol services in a decentralized way.

Content storage and access

One of the services offered by a centralized platform is to store and deliver content on demand. Data centers scattered around the globe are dedicated to this task. Because a decentralized social protocol must be truly decentralized, the service must also be decentralized. There can be no single entity responsible for this. Anyone must be able to offer the service at a very low threshold, and users must be responsible for what they do with their data. With users controlling AD revenue, there can be a fierce competition, and content servers will try to deliver content as cheaply and quickly as possible in this market.

In practice this might work: a user searches for a piece of content, such as the "Charlie bit my finger" video. The content server replies with a quote. The user client weighs response speed and price, and then sends the payment to the best server, where the content is delivered. All of this, of course, will be handled by algorithms in a flash, without human intervention.

Setting up a content server should require minimal technical skill. To do this, people who are already running web services can install software to take advantage of their excess storage and bandwidth. Even home computers and devices can do this.

WoT can be used to help the system run more smoothly. Content servers and users who trust each other can more easily exchange content and pay for it without having to bid and strike a deal for each content. In essence, the content server can grant a series of credits to users who have established a reputation for following the protocol, or to new users with whom they wish to establish a WoT connection.

Both sides can experiment with different algorithms. Explore/Exploit (E/E) algorithms can be deployed for 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 they can: the most visited content.

The actual operation in practice will be complicated because access (demand) is constrained by availability (supply). Being the only server that hosts content 1,000 times a day is better than being one of a million servers that hosts content 1 million times a day. Servers will try to use different algorithms when competing for business.

However, some content may be so poorly accessed that no server is willing to host it. It may be a private message between two people that is rarely re-read. There will be a fee for storing such content. Similarly, servers can compete for the privilege of storing your archive content. Users need to have some back-up in these cases in case the only server hosting their content goes down.

Under such an arrangement, we can expect that the cost of data storage and access will be very cheap, equal to or close to the cost. Assuming you can use the extra server capacity at zero marginal cost and get some value in terms of customer acquisition and WoT scoring, in some cases you can even provide the data service for free.

The user interface

Of course, another crucial part 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 streams, friend lists, inboxes, home pages, avatars, forums, chat Windows, etc. Unsurprisingly, the platform monopolizes the user experience of the data with the data set it controls. For example, there is only one place to view your Facebook profile, facebook.com.

It must be decentralized under a decentralized social protocol, so that any website or application can display your content without having to access it. Since users have control over their content, all they need from an interface provider is an intuitive, pleasant way to interact with that content. Anyone should be able to set up the service and try different ways for users to generate and interact with their content, not just a Twitter page layout that can only be accessed on Twitter.com.

Imagine a Facebook-style home page. On the left is a list of your friends, in the middle is a feed of updates from your friends, and on the right are some ads. Let's say you're viewing this content from 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 page. Basic information, such as personal information, keys, and wallets, is stored locally with the user client as part of the application. If this is a new application, and you already have a pre-installed profile, the application will pull the encrypted user profile from the content server and you will have to enter a password.

The app will accept the highest bid from advertisers, credit your wallet, and display ads on the right side. It will extract your list of friends from the content server, along with related content, such as pictures and posts to which you have been granted access. The application will sort and display all the content using algorithms in the business logic obtained from the interface provider.

To do this, the interface provider can charge for it, and the user can pay for it out of the advertising revenue generated. As with content servers, you can expect intense competition among interface providers because switching costs for users are very low. As a result, instead of users and advertisers controlling the platform for content and interfaces, advertisers, content servers, and interface providers will compete for users' attention and value.

One problem with this design is that services that rely on accessing user content will be impossible. For example, if users' private messages are encrypted and spread across multiple content servers, how can users search for their private messages by keyword? Ideally, we wouldn't open Pandora's box and allow service providers access to content, even under the guise of providing a service to the user. That's how we got into trouble. Thankfully, there is usually an innovative solution that gives users both privacy and functionality.

In the search example above, the interface provider could send an algorithm to the user client to index the user's content using keywords and store that index in a separate file accessible only to the user. When a user wants to perform a search, her/his user client will search the index file with a smaller size, and then PPL will only produce content that matches the keywords in the index.

This is a user-centric rather than service-centric engineering paradigm. It protects privacy, and as the processing power of the client expands, putting the user at the center of things won't be a problem for most applications.

But from the user's point of view, the main difference is the responsibility to remember and protect their key-safe words. If the user forgets the password, there is no platform to reset it. Any other solution to this problem will make your content accessible to third parties.

It might be possible to deploy a multi-signature encryption scheme in which several trusted partners can recover a person's password. This way, no one can access or access your content on their own, except when you need to recover your password.

Ultimately, a user-centered system empowers users, and with power comes responsibility. Given the number of hacks and data breaches on major social platforms in recent years, users would expect such a solution and the autonomy it brings. No one cares more about your privacy and security than you do.

Edge cases

We know that social media platforms can be profitable, so in total dollar terms, advertising revenue is more than the cost of all the services the platform provides. Therefore, we expect the vast majority of individual decentralized social protocol users to receive enough advertising revenue to cover the cost of their content servers and interface providers. But it's instructive to look at three edge cases.

In one extreme case, some users may not be able to generate enough advertising revenue to cover their expenses. One possibility is that advertisers will eventually stop paying to display ads if users never click on them. However, brand advertisers may still be willing to pay a small fee to allow some content to be delivered. In the worst case, such users may simply hold onto their own content, ignoring the convenience provided by the service provider. Or better yet, they can become service providers themselves and have enough revenue to meet their decentralized social protocol usage needs.

At the other extreme, there may be users who are so valuable to advertisers that the AD revenue they bring in exceeds the cost of paying for the various decentralized social protocol services. Given that social media platforms are benefiting from network effects and generating billions of dollars in profits, it is reasonable to expect that many users will profit by using decentralized social protocols and interacting with advertisers.

The final scenario we're considering is a group of isolated users who would rather not see ads and receive no AD revenue and pay for decentralized social protocol services out of their own pocket. Such users will have to top up their decentralized social protocol wallets themselves, and the money will run out.

Content problem

The solution to each problem sows the seeds of a new set of problems. Take the internal combustion engine. The internal combustion engine is a great improvement on horsepower. It has removed horse dung from city streets, freed up money and greatly expanded human capabilities. No one wants to go back to the horse and cart and the plow, but we do have to deal with air pollution, car crashes and other problems. If electric, driverless cars can solve these problems, we can ensure that they will eventually be the source of new problems that our children and grandchildren will have to solve.

Decentralized social protocols help solve the problems caused by network effects and the centralization of social media platforms. Once adopted, no one wants to go back to the days when there was no privacy and only one interface option. But there is no doubt that we will encounter a new set of problems. The obvious problem -- the one we'll eventually have to deal with -- is what I call the "content problem."

As mentioned above, we can expect decentralized social protocols to be censorless territory. If one interface reviews the user's content, the user can move to another interface that does not review the user's content. If the user is pointing out human rights violations, or simply exercising freedom of speech, that's a good thing. But not all of it is free speech. Some content is harmful because it can directly or indirectly cause innocent people to be harmed. One obvious example is paedophilia.

If a decentralized social protocol is known as a tool for delivering this kind of content, no one wants to have anything to do with it. Interface providers, content servers, advertisers, and the developers behind decentralized social protocols are not contributing their talents and resources. The average user will not be able to reap all the benefits of the above decentralization. Decentralized social protocols will fail.

Arguably, the content problem is caused by the encryption technology at the heart of decentralized social protocols. If the decentralized social protocol does not encrypt user content, the content server can scan for harmful content and reject it. But it would destroy the privacy of every user of decentralized social protocols, most of whom are ordinary, law-abiding citizens. To solve the content problem, we need a way to identify harmful content in the ocean of normal content without having to visit or see any of it. On the face of it, this seems mission impossible.

Here, however, I propose a solution called zero-knowledge artificial neural networks (ZKANN), which uses cryptography and network machine learning to do just that. Ultimately, something similar has to be developed to solve the content problem.

conclusion

Today's social platforms have a huge impact in capturing users' attention and creating value. By locking people in through network effects, platforms can cater to advertisers, even at the expense of their users. Platforms have developed sophisticated algorithms to exploit common weaknesses in the human psyche. Vanity, voyeurism and rage keep users staring at the screen, tapping, refresh and swiping for more, which all show up more ads.

With a decentralized social protocol, everyone is motivated in line with the service users, who will use the interface that values them most. Personally, I want to use interfaces that make me feel calm, happy, and connected to the people and content I care about.

For a decentralized social protocol to be successful, it must provide the seamless experience that today's social platforms offer, but with the added benefits of decentralization. The complexities of encryption, content servers, micropayments, Zkann and AD networks must disappear from the average user's view. All the users need to know is that the system is working and sometimes they even have some extra money in their wallets.

In many ways, decentralized social protocols are the fulfillment of the early vision of the Internet, but instead of decentralizing to the domain level, we decentralized to users across the board, putting control and privacy in their own hands.

By the way, I didn't do any specific research on the state of the art or the latest developments in decentralized technologies. It is difficult to do some research in a prison cell, and impossible to do all of it. I'm sure many of the ideas above are not new, but I hope my ideas will be helpful to those who build and use decentralized social protocols in the future.

The original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia