Maitrī Whitepaper
A TWO-LAYER NETWORK FOR ENABLING AND ENCOURAGING COOPERATIVE COMPETITION IN SOCIAL MEDIA
Co-author: Jesse Katz
Abstract
Social media is a modern example of a natural monopoly, as strong network effects lead to winner-take-all outcomes.
Interoperability is essential for competition but is disincentivized by the current social media model. It is more profitable for a dominant player to close off their network, and players who might wish to interoperate have no way to guarantee against such an outcome. As a result, there is no basis for trust that is required for interoperability.
This paper presents a new mechanism design which aligns incentives to establish trust in interoperability, allowing for social media applications to benefit from their combined network effects while they compete with one another. No single entity can control the entire network, and the incentive to interoperate persists even for dominant players.
The resulting ecosystem will offer users many benefits over the existing social media model, including more individual agency, more choices in features and functionality, better privacy and control over their data, improved security, a unified user interface for all applications, and the ability to share in the value they help to create. As a result, this new model has the potential to rival, and eventually overtake, existing social media monopolies.
1. Social Media: State of Monopoly
“Markets without competition are not markets at all, just as a one-party state cannot be a democracy”
- Eric A Posner & E. Glen Weyl
1.1 Concentration of Power
The monopolistic nature of social networks has resulted in a tremendous centralization of power in a few companies, allowing them to undermine our individual agency and threaten our democracy.
Social media companies have inserted themselves as gatekeepers to relationships that they have no right to own. They demand our content and data, violate our privacy, and censor our speech. If we do not comply, we can be cut off from people who mean the most to us.
While the consolidation of traditional media has enabled higher levels of subversive influence over public policy and election outcomes, social media companies have amplified that to an alarming degree, with over half of Americans now obtaining their news from the same entity. This unprecedented potential for censorship and propaganda is exponentially multiplied by their ability to manipulate the social cues we use to interpret that information¹. Concentrating this power in the hands of a few CEOs poses an existential threat to our democratic institutions.
At the root of these problems is a lack of competition. Due to the strong network effects inherent to the industry, users amass to a single network. If your friends and family were distributed across multiple networks, they would be unable to interact with one another. In order to have multiple social media companies co-exist and compete, their applications must be interoperable.
However, to-date, interoperability has been elusive, on both the regulatory and the free market fronts. The focus of this paper is to describe a mechanism design, built on blockchain technology, that introduces cooperative competition into social media by aligning incentives and enabling interoperability. The goal is to turn a parasitic industry into a healthier and more symbiotic ecosystem that we will refer to as Maitrī².
¹ Over time, we’ve learned not to trust everything we read or everything we see on TV. But we have an ingrained tendency to match our beliefs and behaviors to that of the group. This phenomenon, known as conformity, can be easily exploited by companies which greatly influence what we are shown or how many likes a post receives.
² Maitrī is a Sanskrit word for benevolence, loving-kindness, friendliness, amity, good will, and active interest in others.
1.2 Regulatory Shortfall
Traditional regulatory approaches to this type of problem have involved breaking up monopolies. However, those breakups all involved utilizing existing technologies. For example, consider the break-up of AT&T in 1984. Even though the telephone industry benefited from strong network effects, phone networks were already interoperable, such that splitting AT&T into seven smaller companies did not cut people off from one another.
On the contrary, in the case of social networks, regulators would have to mandate that brand new technology be developed in order to enable interoperability. We have not seen this in anti-trust regulation, and when it has been suggested, it is fraught with practical and legal challenges. Even if it were possible, that would be a suboptimal solution, as these types of regulations would likely stifle innovation and open the door to regulatory capture. Well-resourced companies have proven adept at lobbying for regulations to serve their interests and create barriers for new entrants.
1.3 Free Market Shortfall
Left up to the free market, the incentives are stacked against interoperating.
While the early days of the internet saw wide adoption of open protocols (SMTP, IRC, NNTP, etc.), over time proprietary approaches that maximized profits won out. In social media, the most profitable strategy for the dominant player (one with the largest market share) is to build a wall around their user base. Due to network effects, users have to come to the dominant network to be able to interact with the highest number of other users, leading to an inevitable winner-take-all outcome. Once the competition is eliminated, there is nothing to prevent the monopoly player from extracting a disproportionate value from those users.
It’s worth noting that in other industries, we have seen open-source and interoperable solutions successfully take on and disrupt dominant players. One example is the success of Google and ARM in dislodging the combination of Microsoft and Intel when smartphones came out. For years, Microsoft and Intel (dubbed ‘Wintel’) captured the vast majority of the PC value chain, leaving the rest of the ecosystem with near-zero aggregate profit. The arrival of smartphones presented an opportunity to reorder the industry. In order to avoid falling into the same trap, the rest of the ecosystem elected for Google’s open-source Android operating system and ARM’s open-license chipset. If either Google or ARM ever attempted to extract a disproportionate share of profit, the smartphone manufacturers could always fork the code / license. This instilled trust among all the players that they would not find themselves on the losing end of another Wintel deal.
In a similar vein, we could imagine a group of interoperable social networks joining forces to create a larger social network and take on the dominant players. However, the difference is that there is no way to permanently ‘open-source’ your network, because the value of the network is not in the code itself but in the nodes (users) and the connections between them. While a company can make their network interoperable with other networks, and even open-source the code, there is no guarantee that they won’t wall off from the network if and when they become large enough. In other words, the trust model that was created in the smartphone industry using an open-source approach cannot be replicated here. And because everyone knows that the incentive for the dominant player is to wall themselves off at some point, there is not enough trust to interoperate.
2. Decentralized Trust
2.1 Achieving Trust with the Blockchain
Recent advancements in blockchain technology present us with new ways of establishing and maintaining trust.
One potential way to approach decentralized trust is to embed all of the logic of interoperability into a smart contract. However, that is not a viable option in this case. Even if technically feasible, there would be no way to mandate participation. Once a dominant player acquired enough users, they could simply stop using the blockchain and wall themselves off.
Instead, Maitrī incentivizes interoperability, even for dominant players, and only requires that we trust all players will act in their own interest. Placing the rules on a decentralized blockchain ensures that they will not change in the future.
With these assurances, multiple social media companies can join forces to create a larger combined social network to rival and overtake the current monopolies.
2.2 A Note on Centralized vs. Decentralized Applications
There are many great projects building decentralized social network applications on the blockchain, and the goal of this paper is not to propose another one. Instead, Maitrī encourages interoperability and competition between applications, whether centralized or decentralized, with the goal of providing users with the most options.
3. Achieving Interoperability
3.1 Why Direct Interoperability Won’t Work
It might appear that the most straightforward way to achieve interoperability is for all the social networks to directly connect with one another. However, this presents several problems.
First and most importantly, as long as applications continue to serve as gatekeepers, there is no way to remove the incentive for a dominant player to wall themselves off when they become large enough.
In addition, major conflicts of interest would arise from direct competitors interoperating. All sorts of tricks and methods could, and would, be used to undermine interactions with users on a competing network.
Finally, it is technically inefficient, as each network would have to set up its own API, and connect to all the other networks’ APIs. For example, to have 15 smaller networks interoperate directly, this would require a total of 15 APIs and 210 API connections³.
³ Each of the 15 networks would need to develop its own API, and would need to connect to 14 other APIs, requiring 15 x 14 = 210 total connections.
3.2 Introducing a Two-Layer Network
To solve these problems, the network is split into an Application Layer and a Platform Layer.
At the Application Layer are all the individual applications, such as photo sharing, messenger, live feed, news sharing, microblogging, short-form videos, events, etc.
At the Platform Layer are gateways which combine all the applications into a unified user interface (see Appendix A). These platforms serve as neutral parties for applications to connect to, removing the need for competing applications to interoperate directly with one another.
Each user would access the entire network and all of their applications through a single platform.
A helpful analogy might be the console game industry, where the console serves as a platform and the games are the applications. Another one is the PC industry, where the operating system is the platform and the applications are, well… the applications.
Example of three applications interoperating through one platform
3.3 Emergent Greater Network Effects
The positive aspects of network effects are retained at both the Application and the Platform Layers. For example, users can interact with other users on the same platform, as well as other users on the same application, even if those users are on a different platform.
The diagram below illustrates what this might look like.
This two-layer network would have the following properties:
- Applications compete with other applications at the application layer and interoperate at the Platform layer; no need to directly interoperate with each other
- Similarly, platforms compete at the platform layer and interoperate at the Application Layer; no need to interoperate directly with each other
- The entire Maitrī network emerges as a result of the interplay between the Application and the Platform Layers, and no single entity controls the entire network
3.4 Two Layer Network: Example
To illustrate, suppose we have a close group of friends: Bob, Alice, Sarah, Jim and Frank.
Today, if these five friends wish to interact with one another, they all have to be on the same social media application.
In the Maitrī two-layer network, we could imagine the following selection of platforms and applications by these users
We can visualize this by labeling them as users on the diagram:
In this example, any of these users can interact with any other at one, or both, layers of the network.
For example, Bob can interact with Alice in two places: Platform 1 and Application 1. He can also interact with Sarah on Application 1, with Frank on Application 1, and with Jim on Platform 1.
We can map out all their potential points of interaction as follows:
Even though the five users access different combinations of platforms and applications, there is a greater network effect which emerges, allowing all five friends to interact and maintain relationships with one another.
Certain entities are a single point-of-interaction for certain relationships. For example, Bob can only interact with Sarah on Application 1, so the provider of Application 1 does have power over that connection. But it is a limited power, because no single entity controls the entire network, and if Application 1 does not serve Bob and Sarah’s interest, they can choose another application to maintain their relationship.
There is one more scenario, not covered in the diagram above, in which two friends could find themselves sharing zero common platforms or applications. This is addressed by a decentralized directory and messaging application, and will be covered in a later section.
Beyond maintaining relationships, any use case can be split into several competing applications while still maintaining network effects. See Appendix B for an example using a tweeting-style application).
3.5 Introducing the Players
Three different types of entities interact in this ecosystem:
- Network Application Provider (NAP) – provides and hosts one or multiple applications to the ecosystem
- Network Platform Operator (NPO) - operates a platform which connects to, and unifies, multiple applications
- Users – the end users of the platforms and applications
Going forward, we will refer to NAPs and NPOs by their acronyms.
3.6 Two-Layer Interoperability
The three problems with direct interoperability outlined previously are addressed by the two-layer network as follows:
First, and most importantly, the incentive is eliminated for a dominant player to wall themselves off and ride the network effects to a winner-take-all outcome. If a dominant NAP chooses to wall themselves off, they won’t run away with a majority of the network, as all its users also exist at the Platform layer and can re-establish relationships with each other on other applications. Similarly, if an NPO attempts to wall themselves off, its users also reside at the application layer, and can switch to another platform to maintain their ability to interact on those applications. In a later section, we dive deeper into the game theory of how a variety of strategic scenarios might play.
Second, there are no conflicts of interest arising from interoperating directly with competitors. The two-layer network does not require individual applications to directly interoperate with other applications, nor platforms with other platforms.
Lastly, the system for interoperability via APIs is significantly more efficient. Using the prior example of 15 social networks, imagine there are 15 NAPs and 3 NPOs. Instead of 15 open APIs, only 3 need to be developed (one by each NPO). In addition, each NAP only has to interface with those 3 APIs instead of 15, requiring a total of only 45 interfaces instead of the previous 210.
3.7 Incentives to Participate and Interoperate
For this design to work, the NAPs and NPOs must be incentivized to interoperate with one another, and the users must be incentivized to access the network through a platform. At a summary level, this is accomplished by the following design:
- NAPs generate revenue through their chosen revenue model, which is shared with NPOs and users (see Appendix E for implications of sharing revenue with users)
- NPOs serve as intermediaries between users and applications, and allow access to users in exchange for revenue share
- While users can choose to engage directly with applications, they must access the network through a platform if they want to participate in revenue share
Aside from the revenue share, users are incentivized to access the network through a platform for the aggregation benefits. These include a superior user experience from a unified UI, scalability to access many more applications, and curation of those applications.
In order to generate revenue, NAPs must interoperate with NPOs to reach users who access the network through a platform.
NPOs must interoperate with NAPs in order to earn revenue and provide a wider application offering to their users.
In other words, NAPs and NPOs each have half of a successful business model and are therefore incentivized to work together.
4. Smart Contract
4.1 Smart Contract: Rules
Translating the above design, we would encode the following rules into a smart contract running on a decentralized blockchain (technical implementation will be covered in a later section):
- For each user interacting with an application, the NAP will pay the NPO based on an agreed-upon metric (e.g. time spent on the app) and an agreed-upon price (e.g. amount per second).
- The payment will be split 50 / 50 between the NPO and the user
- In order to enter into the smart contract and be eligible for their portion of the payment, the user must initially access the network through a Maitrī portal, which will redirect the user to their chosen platform
In other words, all of the revenue share will flow through the smart contract. Building on the prior diagram, smart contracts are added to the ecosystem:
4.2 Thwarting Sybil Attacks / Fake Accounts
While the smart contract is permissionless, there is no incentive to create fake NAP or NPO accounts, as they can’t generate revenue without users, and in order to attract users they must offer a product with real value.
On the other hand, the overall network design does create a strong incentive for sybil attacks via fake user accounts. Since users receive a share of the revenue, it could be profitable to create fake or bot accounts as long as the NAP and NPO can be fooled into believing that it is a valuable, revenue-generating user⁴.
Although the NAP and NPO agree on a price for every user, and can set the price to zero for accounts which are clearly fake, there will inevitably be accounts whose authenticity is difficult to determine. For these accounts, there is a mechanism by which the NAP and NPO can still transact while removing the incentive for the fake account. The NPO can set a ‘verified’ flag for each user. If the NPO marks the user as verified, the transaction continues as previously outlined. If the user is not verified, then the transaction is augmented such that the tokens which would otherwise go to the user’s wallet get burned instead.
NPOs receive the same amount of revenue regardless of verification, so there is no incentive to over-verify or under-verify accounts. NPOs are incentivized to verify real accounts, or those users may switch to another platform in order to earn tokens. They are also disincentivized from verifying fake accounts, as having fake accounts is dilutive to the overall revenue model - NAPs may start discounting pricing on all accounts due to some fraction of them being fake.
We expect NPOs to take different approaches to verification methods, including those based on IDs, phone numbers, bank accounts, or more anonymity-preserving metrics such as social proof, posting activity, etc. Verifying and certifying identities could also be done by third-party organizations or by decentralized projects.
⁴ It’s important to note that this will only be applicable to certain revenue models, such as advertising. If the NAP’s revenue model is subscription or ecommerce, then the fake account would actually have to spend money to receive back a fraction, which would not be profitable (the issue of chargebacks can be solved by delaying payment to new users until they’ve established a history).
4.3 Smart Contract: Robustness and Flexibility
The smart contract outlined above is deliberately intended to be relatively simple and general-purpose, for several reasons.
First, complexity breeds vulnerabilities, such as bugs and loopholes, which will inevitably be exploited.
Second, by keeping only the bare minimum on the blockchain, no restrictions are imposed on the type of applications which can run on the social network. All API communications required between the applications and the platforms are kept off-chain, placing no additional load, nor technical dependencies, on the blockchain.
Third, any and all revenue generation models which the NAP may employ are supported. Whether the revenue is generated through advertising, or paid subscription, in-game purchases, ecommerce, etc., the rules can still be implemented as outlined, and that revenue will be shared with NPOs and users.
Finally, we maintain flexibility as to how users are valued. An NAP and NPO can select any metric, such as time spent, or clicks, or posts, purchases, etc. as long as they agree on the metric and price in advance (see Appendix D for how this price negotiation might occur).
In summary, this simplicity and flexibility is important to foster innovation, as we cannot predict today what type of applications, business models, or user activity will be created in the future.
4.4 Smart Contract: Simple yet Critical
Although a relatively small part of the overall design is implemented directly on the blockchain, it is absolutely critical in creating and maintaining decentralized trust. The rules in the smart contract create the incentives for a two-layer network, and a two-layer network creates a system in which a dominant player is incentivized to remain interoperable. And by embedding these rules in a decentralized smart contract, all the players can trust that the rules cannot be changed.
In other words, without the blockchain component, no one would have the trust to interoperate, and the entire solution would not be possible.
5. Privacy, Permissions and Censorship
5.1 Privacy
The majority of user data will be stored off-chain, either by the NAP, NPO, or both where applicable. As alluded to previously, we would expect different NAPs and NPOs to offer different levels of privacy, and for this to be one of the dimensions on which they compete. We would also expect they will offer different packages, such as subscription, to users who care more about privacy and are willing to pay for it.
In addition, the two-layer design allows users to manage their privacy by maintaining different identities across applications (see Appendix C).
Certain data will exist on-chain, such as how a specific user interacted with a certain application and how that was priced. For privacy reasons, it is critical that this information cannot be tied back to any specific individual. This will be covered in further detail in the technical implementation section.
5.2 Permissions and Censorship
The smart contract will impose no permissions or censorship, and will operate on a permissionless, censorship-resistant blockchain. Anyone will be allowed to become an NAP, an NPO, or a user, and to participate in the smart contract with that role.
Permissions and censorship will be handled at the Platform and Application Layers. No entity or user will be forced to interact with any other entity or user, and will be free to select its own level of permissions and censorship as to who, and what type of activities, are allowed on their individual platform / application.
This is a model which works well as long as there is competition, providing users with options without imposing any one-size-fits-all value system on all the participants.
5.3 Decentralized Directory and Messaging Application
It is essential to have a neutral application within the ecosystem which serves the simple functionality of providing a directory of all the users, as well as the ability to directly message any other user in that directory. To illustrate why, consider a couple of scenarios:
The first was alluded to earlier, which is that two users could end up with zero overlap between their chosen platforms and applications, leaving them with no way to interact. For example, if John and Jane are friends in real life, it could happen that John selects Platform 1, and uses Applications 1, 2, 3 and 4, and that Jane selects Platform 2 and uses Applications 5, 6, 7 and 8. As a result, they would not be able to form a connection or communicate with each other at either the Platform or the Application Layer.
A second scenario is one where two users do use a common application, but that application may censor communication between them. For example, if John is on Platform 1 and Applications 1 and 2, and Jane is on Platform 2 and Applications 2 and 3, they can interact and communicate with each other on Application 2. However, if John wants to invite Jane to Application 1, and Application 1 is a competitor to Application 2, Application 2 may censor John’s communication such that Jane never receives the invite.
If all users are part of the same decentralized directory and messaging application, they will always be able to connect and communicate with one another, creating a level of censorship-resistance. In order to ensure that this application remains neutral and does not abuse its power, it should be a decentralized application.
6. Value Proposition to the User
The following sections summarize the value proposition to users that the Maitrī ecosystem would bring compared to the current monopoly model of social media.
6.1 Value Proposition Resulting from Cooperative Competition
While platforms and applications cooperate on network effects, they compete along other dimensions, such as features, price, privacy, and security.
It is difficult to enumerate all the benefits which competition brings, but it’s worth mentioning a few of the major ones. First, there is innovation. Current social media monopolies only innovative enough to maintain their monopolistic position, and most of their innovations consist of copying features and acquiring competitors. However, if we look at competitive markets, especially platform-application ecosystems, we see a tremendous amount of innovation. Windows OS has millions of applications, as do the Android and Apple app stores. And it is hard to overstate the quality and innovativeness of video games. It is impossible to imagine today all the innovations which will result from an open, competitive ecosystem in social media, but it is safe to say that it will be a better result than the dozen or so applications we see among today’s monopolies.
Another benefit from competition is much higher attentiveness to users’ needs and demands. Users have been demanding better privacy, security and control over their data for years, but social media giants have not been forced to pay any attention to them. Users’ complaints about misinformation and click-bait, censorship without accountability, and manipulation of their time and attention, fall on deaf ears. In competitive industries, businesses have to treat users much better for fear of losing them, and we expect a similar dynamic to play out in social media.
Lastly, in addition to the benefits stated above, there is an inherent value to having choices. We don’t all listen to the same music, or drive the same type of car, or live in a neighborhood with a homeowners’ association; likewise, we don’t all want a social media experience with the same UI, the same policies and algorithms, and the same one-size-fits-all values.
6.2 Value Proposition from Revenue Share
Sharing revenue with users is not only morally imperative, but creates a more symbiotic ecosystem with several benefits to users. There is the monetary benefit, and the psychology that comes with knowing that they are sharing in the value that they helped to create. In addition, it also serves to align incentives between users, NPOs, NAPs, and advertisers (if applicable). This sets the stage for win-win outcomes. For example, users might create more content on the applications in order to increase their revenue. Or they might work with NAPs and advertisers toward more curated ads that they are willing to view or engage with.
6.3 Value Proposition from a Unified UI
There is a great convenience that users will enjoy from being able to access all their social media applications in a single place, with a single login, and with a consistent UI and behavior between those applications. In addition, with wide adoption, there will be a single point of access to reach anyone else on the network, regardless of which platform or applications they are participating on.
7. Game Theory Scenarios
There are potential strategic actions that individual players can take which, if successful, could result in a less competitive environment, a lower monetary gain for users, or a diluted user experience. In order to check the robustness of the system design, we consider the following scenarios.
7.1 NAP uses ecosystem to capture a large user base and then walls itself off
This scenario involves an NAP joining the ecosystem, developing one or more ‘killer apps’, and using it to build up a large, loyal user base. Once it grows large enough, it walls itself off by breaking interoperability with NPOs, requiring users to access it directly in order to use its app(s). By doing so, the NAP would no longer have to share revenue with NPOs and users.
However, strong incentives would remain for the NAP to maintain interoperability. By walling itself off, it would lose a subset of users who are not willing to switch away from their platform and lose the benefits of being part of a larger network (access to more users and to other applications).
Additionally, unless it offers commensurate revenue share, it would create a monetary disincentive for users to access its applications directly. Lastly, even among the users it retains, the NAP would have to consider the damage to its brand with users grown to appreciate an open ecosystem.
7.2 NPO uses ecosystem to capture a large user base, then swaps in its own applications and walls itself off
This is similar to the prior scenario, except it is the NPO instead of the NAP walling itself off. An NPO could use the ecosystem to grow a large user base, and begin offering its own applications, and then over time wall itself off to competing applications. This could be done either directly (more functionality directly at the NPO level), or indirectly by creating NAPs and granting those NAPs preferential treatment. This is a very realistic scenario, and is likely to happen to some extent. However, the incentives are toward remaining interoperable.
A familiar example in the PC industry is Microsoft starting with Windows OS, and over time developing and bundling its own apps with Windows. The most egregious case was the bundling of Internet Explorer. A less drastic one is how Microsoft withheld certain features from Office on the competing Mac OS platform. Yet, overall, Windows as a platform remains largely interoperable, with millions of applications available to Windows users. A platform is most valuable when it has a broad set of quality applications, and is dependent on outside developers to compete in this regard. Likewise, in the gaming console space, while certain games are exclusive to specific consoles, the vast majority of games are compatible with multiple consoles.
We expect network platforms to employ a similar strategy. They may favor certain applications, or make some of them exclusive, but in order to compete they will need to remain largely open and interoperable.
And ultimately, even if an NPO chooses to fully wall itself off, users could switch to another NPO with minimal adverse effects (still maintaining their relationships and access to most of their applications).
7.3 Collusion at the Application Layer or Platform Layer
In this scenario, two or more NAPs agree to connect directly and integrate with each other’s applications, cutting out the platforms. Alternatively, two or more NPOs could do the same in order to cut out the NAPs. In a case where only a few players dominate a single layer (application or platform), this could pose a threat to the overall ecosystem by eliminating competition at that layer.
The threat of collusion exists across many industries, and is no less present in this environment where NAPs or NPOs might form anti-competitive agreements. This type of behavior would likely be legally prohibited under existing antitrust laws in many places. The higher the combined market-share of the colluders, the more likely these laws are to be enforced.
On the other hand, in cases where the colluders have relatively low combined market share, the incentive would be against collusion, even without legal enforcement. For example, if several NAPs colluded to interoperate with each other and otherwise walled themselves off, they would exclude themselves from the network effects of the larger network, and would not benefit from such an action. In addition, they would invite new competitors to enter the space, as the NPOs and users would suddenly be in need of new applications to replace the walled-off ones.
7.4 Large NAP and large NPO form strategic partnership to capture the network
This scenario is probably the most threatening to the entire ecosystem. If a dominant NAP partners with a dominant NPO to interoperate only with one another and wall themselves off from the rest of the ecosystem, this could have a significant adverse impact on the remaining network.
The size of the impact would depend on (a) how dominant each player is in their respective layer, (b) how correlated users are between the NAP and the NPO (ie how likely are users who use that NAP to also use the NPO), and (c) how many applications those users use from other NAPs.
For example, if a single dominant NAP reaches 60% of the total users with its applications, and a single dominant NPO hosts 70% of the user base, then the percent of users who are on both the NAP and NPO could be anywhere between 30% (lowest possible correlation – the least number of users overlap between the NPO and NAP) and 60% (highest possible correlation – all of the NAP users are on the dominant NPO). In a random distribution, we would expect the overlap to be 42% (0.7 x 0.6 = 0.42).
Lastly, out of those 42% of users, how many are also using applications on other NAPs which they find valuable? The lower that number, the easier it would be for the NAP and NPO to wall themselves off, as those users are more likely to stay on the newly created closed network.
In other words, in order to protect against this scenario, it is important that the market share does not become too concentrated in a single NAP and single NPO, and that users use multiple applications across several NAPs.
7.5 Existing monopoly player (e.g. Twitter) competes by sharing revenue with users
If the Maitrī ecosystem is successful enough to threaten existing social media monopolies, they might choose to compete by offering revenue share to their users. They could either implement the revenue share on their own, or they might utilize the Maitrī smart contracts while remaining walled off from other NAPs and NPOs. However, simply copying the revenue share would not give their users access to the broader network effects, the unified UI and the applications that presented the threat in the first place.
7.6 NAP makes side payments to NPO for preferential treatment
An NAP could make a side agreement with an NPO for favorable treatment in exchange for payment. This can be done via a variety of methods. For example, the NPO could make the NAP’s apps more accessible or prominent in the UI, or it could throttle the performance of competing applications.
In practice, there is no way to prevent this type of behavior, and it does occur in other industries, including those with platform / application models. For example, when you purchase a new smartphone, it often comes pre-installed with certain applications which the phone manufacturer favors. But they only do this to an extent and still allow you to replace the vast majority of those apps, as there is a practical limit to what customers will tolerate before switching to a competitor.
We would expect to see similar games played in the Maitrī ecosystem to an extent, as there are conflicting incentives for the NPO to favor NAPs versus the user experience it aims to optimize, and there is a point of equilibrium between the two.
7.7 NAP makes side payments to NPO in order to cut out the users from the revenue share
The mechanism design intends for NPOs to negotiate smart contract pricing with NAPs on the behalf of themselves and the users. However, an NPO and an NAP could potentially agree to artificially discount the pricing on-chain and settle the difference off-chain in order to avoid paying users their share of the revenue.
While these types of side payments could be problematic, NPOs must compete for users who might switch to another platform where they can earn more revenue. In addition, if the public learned that the NAP and NPO had such a side arrangement, it could harm their brands.
Another way to compete is for honest NPOs to make certain legally-binding statements in their terms of service and marketing materials that they do not accept side payments, leaving dishonest NPOs to either imply that they do, or lie (with legal consequences).
7.8 NPO directly advertises to users, cutting out NAP and users from ad revenue
In this scenario, an NPO directly contracts with advertisers to display additional ads to users on its platform. The advertising revenue generated in this manner would be fully retained by the NPO, and not shared with either the NAP or the user.
For business models which rely on advertising, it is worth noting that for any user experience, there is an optimal number of ads. Displaying fewer-than-optimal ads leaves revenue on the table, and displaying too many ads dilutes the user experience, inducing users to either switch to a competitor or simply stop using the service altogether.
NPOs cannot prevent NAPs from serving ads within their applications, mainly because there is no technical way to discern what is actually an ad. If an NPO chooses to serve additional ads to the same user, it will start to push the total ads the user sees into a sub-optimal territory.
An NPO may be willing to lose some users and the revenue they generate, in exchange for additional ad revenue on the remaining users, but only up to a point. In addition, even the retained users will be worth less to the NAPs as the number of ads increases, reducing the price the NAPs would be willing to pay for those users.
As a result, we may see some direct ads from NPOs, but not too many, as the total number of ads self-regulates.
8. Governance and Core Values
As outlined here, pure token-based governance has too many vulnerabilities, and will not be employed. We are enthusiastic about ongoing research and experiments in different tokenized governance models, but none have yet stood the test of time and scale.
To date, the best decentralized governance has been achieved through establishing legitimacy at the social layer, held together by a shared set of values. The broader community holds leadership accountable through adoption/retention, and ultimately a threat of a hard fork. Maitrī governance will follow this model until a better one is proven out.
In order to fund development while maintaining neutrality, an independent, non-profit organization will be established.
The foundation’s mission will be to promote competition and innovation in social media, and will be founded on the following values:
- Political power should be as decentralized as possible to limit government oppression
- Freedom of speech is the foundation of a free society – it enables all other freedoms
- People should share in the value that they help to create
- Privacy is a core human right, and should be maintained to the maximum degree possible
- Competition lies at the heart of human progress, driving innovation and consistent improvements in price and quality
9. Building Maitrī
The Maitrī ecosystem consists of the following:
- Applications
- Platforms
- Blockchain components (smart contracts and decentralized directory and messaging)
The good news is that not everything needs to be built from scratch, as many social media applications already exist. For the vast majority of these applications, the biggest challenge is that they are up against the strong network effects of the dominant player in their category. These applications can be invited to become NAPs on Maitrī by connecting to the APIs of the Platforms, offering them access to a broader user base and greater network effects, while still allowing them to retain their direct users. The more applications join, the greater the network effects, creating an even more compelling reason to join.
On the other hand, the platforms do not exist today. Building these will be the largest undertaking initially, especially given the complexity of a unified UI, large data and open APIs. However, if at least one platform is proven successful, this will invite more competition into the space.
Lastly, the blockchain components are needed, including the smart contract and the decentralized directory and messaging application. Ideally, the latter can be selected from existing decentralized applications instead of built from scratch. The selection criteria and technical implementation of these components is covered in the next section.
10. Technical Implementation: Blockchain Components
10.1 Blockchain Selection
It would be preferred to leverage an existing blockchain for Maitrī. In evaluating and selecting a blockchain, the requirements are as follows:
- Support smart contracts
- As decentralized as possible - a blockchain tying together a global social network must be censorship-resistant
- Scalable to hundreds of millions of transactions per day. Exact requirements will depend on the total number of users and how frequently transactions are settled.
- There must be a way to keep transactions on the blockchain private
Given the above, the blockchain which best meets these criteria today is the Ethereum blockchain, combined with a layer 2 scaling and privacy solution. The most promising layer 2 for this purpose is Aztec Network.
10.2 Web Portal
In order to create a persistent user ID and participate in revenue sharing, first-time users will need to access the network through a web portal.
This portal will:
- Generate a unique user ID and a wallet address which will be owned by the user even if they switch platforms
- Allow the user to select an NPO
- Redirect the user to the NPO’s platform and pass the user ID and wallet address to the NPO
Subsequently, users can access their platform’s URL directly, as the NPO will have this information stored, and will only need to revisit the portal when they wish to switch platforms.
10.3 Network Token
A new token will be issued under the ERC20 standard. The token will be called [TBD].
A total of [TBD] tokens will be created initially and issued to the founding team, early developers, and the Foundation. After the initial issuance, no additional tokens will be created. As a result, the total supply of the token will be deflationary over time, as there is a mechanism for burning tokens but no mechanism for issuing new ones.
The Foundation will then set aside allotments of tokens for (a) raising funds to fund future development, and (b) granting to early NAPs, NPOs, and users to drive adoption.
10.4 Smart Contract Implementation
10.4.1 Overview
In designing the smart contract, a few things are worth noting:
- For any given user accessing an application through a platform, the NAP and NPO both know how a user behaved on that application
- Higher flexibility and simplicity can be achieved if the tracking of user behavior for settlement purposes is kept off-chain
- The NAP and NPO are playing a repeat game across many users and across time, making cheating on any one user interaction highly disincentivized, as well as immaterial
10.4.2. Initiating a Smart Contract
A smart contract will be created for every combination of NAP, NPO and user, unless there is an existing open smart contract for that combination.
When a user uses an application, the NPO will initiate a smart contract with the following information:
- The wallet addresses of the NAP, the NPO, and user in that transaction
- A verification flag for the user set to either ‘true’ or ‘false’
- An agreed-upon price-per-unit
- Contract closing terms:
a. An agreed-upon confirmation window, expressed in number of seconds
b. Error threshold percentage
The price and unit of measure can be agreed-upon off-chain between the NAP and NPO. For example, when Bob begins using a specific application, the NAP and NPO can agree on time (seconds) as the unit of measure and a price of 0.05 tokens per second. All that needs to be provided to the contract is the value of 0.05, as the rest can be managed off-chain (see settlement and dispute sections).
10.4.3 Closing a Smart Contract
Either the NAP or the NPO can choose at its discretion to trigger a closing of the smart contract⁵.
At this time, the entity triggering the closing of the contract will provide the quantity of the unit of measurement. For example, if the NPO triggers the closing, and the unit of measurement was time (seconds), and Bob spent 5 minutes on an application at the time the contract is closed, the NPO will submit a value of 300 (seconds).
Once the NPO triggers the process to close a smart contract, the counterparty (in this case, the NAP) will then have the time allotted in the confirmation window to respond. If the NAP either confirms, or does not respond, the smart contract will accept the NPOs input value and proceed to settlement.
If the NAP wishes to reject, it will submit what it believes is the correct quantity, and the smart contract will enter a ‘dispute’ state.
⁵ Blockchain transaction fees serve as a disincentive to closing out smart contracts too frequently. However, an NPO might prefer a more frequent settlement for cash flow purposes, or either party might wish to avoid leaving too large of an amount tied up in a single smart contract in the case of a dispute. In addition, either party might decide that the rate negotiated for that contract should be re-negotiated, so they may choose to close it out and open a new one.
10.4.4 Settlements and Disputes
If the smart contract proceeds to settlement, the calculated quantity of the token will be paid from the NAP as follows:
- 50% of the token quantity to the NPO’s wallet
- If the verification flag is set to ‘true’, 50% of the token quantity to the user’s wallet
- If the verification flag is set to ‘false’ 0% of the token quantity to the user’s wallet and 50% of the token quantity to an eater address, effectively burning the tokens
If a smart contract enters a ‘dispute’ state, it will first be sent back to the original entity (in the example above, the NPO) to confirm the new proposed quantity. The confirmation process will work similarly to the initial round; the NPO will have a time duration equal to the length of the confirmation window to respond, and a ‘confirm’ or a no-reply will send the contract into settlement at the new quantity.
If the NPO disagrees, it may enter a new quantity which is different from the NAP’s submission, in which case the contract will close out as follows:
The objective of the above is to allow contracts to settle which were deemed ‘close enough’ in advance by the NPO and the NAP (small differences may arise due to technical reasons), and to send anything more divergent to an off-chain resolution process.
Because the NAP and NPO are playing a repeat game, the off-chain resolution process can be similar to any other payables / receivables process between entities. Ultimately, they will either reach an agreement or settlement on what is owed and paid, or will choose to stop doing business with one another.
10.5 Decentralized Directory and Messenger Application
The goal of the decentralized directory and messenger application (DDMA) is to provide a single universal application through which every user of Maitrī can be located and messaged regardless of which platforms or applications they are using. Similar to the access portal, a user will retain their login info to the DDMA as they switch between platforms and applications.
When a user account is created via the access portal, an account will also be created on the DDMA and the login credentials will be provided to the user. It is possible that the DDMA could also provide the functionality of the access portal, such that a single account and login serves both purposes.
For the DDMA, it would be preferred to leverage an existing decentralized application if possible. This is a rapidly evolving space, and further evaluation will be needed. Some of the evaluation criteria will include:
- Privacy and mutability of direct messages
- Scalability
- Network architecture and message propagation speed
- Ability to search for accounts
- Support of unique usernames
- Account recovery
- Governance model
11. Closing Remarks
Social media monopolies are far too powerful, yet far too well-entrenched under the current model to simply be dislodged by a challenger. Through the two-layer network design, we can change the rules of the game to enable many applications to exist on the same network. While they compete on one layer, they interoperate and join forces on another layer to create an ecosystem which can rival and overtake the incumbents while remaining responsive and accountable to its users.
We welcome all feedback and discussion. Feel free to contact the author at leo@ozzo.events.
Appendix
Appendix A: Unified UI
One of the value propositions to users is that they can receive all of their social media applications in a single unified UI at the platform level. Each NPO will design their own UI, and decide on how it groups different applications together, how it lays them out on the screen, and so on. The illustration below is one hypothetical, and very crude, example of what a unified UI might look like. In this version, there are four broad categories at the top (Content, Groups & Events, Messaging, and Other), and each of these categories has subcategories. In this case, the ‘Content’ category is selected, and the subcategories are shown along the left (Broadcasts, Videos, Photos, Music). ‘Broadcasts’, which is selected to the main screen, captures types of social media posts which are broadcast out to a larger audience, such as tweets, news sharing, and status updates. In the main screen, with ‘Broadcasts’ selected, the user would see an aggregation of these types of posts from all of their applications, all combined into a single stream. Even though these would come from many different applications, they could all appear very similar in one location.
Go back to Section 3: Achieving Interoperability
Appendix B: Maintaining Network Effects Across Multiple Applications
In addition to creating interoperability between multiple applications for different use cases (for example, one application for photo sharing, and another for status updates), the two-layer network design also supports multiple applications serving the same use case and still maintaining network effects.
To illustrate how, let’s consider the use case of short-form broadcasts, synonymous today with tweeting.
In the below scenario, there are three users who are ‘followers’ (Bob, Alice and Frank), each on a different platform. They all follow three users who are ‘content creators’ and have large followings (John, Sarah, and Jim). Each content creator is on a different tweeting application. For simplicity, the diagram does not show which platforms the content creators are using.
B.1 Network Effects for Followers
Even though Bob is following John, Sarah and Jim across three different applications, their tweets are aggregated by his platform such that he receives a unified view of all the tweets (see example mockup in the prior section). As a result, his experience is very similar to what it would be if all of the content creators he follows were on a single application. The network effects remain, as Bob has the opportunity to follow anyone in the Maitrī ecosystem (and the same goes for Alice and Frank).
B.2 Network Effects for Content Creators
Similarly, content creators also receive the benefits of network effects. For example, John, who is using Tweeting Application 1 to tweet, sees that Bob, Alice and Frank are all following him on that application. To John, it does not matter that these three followers are on different platforms, as they can all receive and interact with his tweets (and the same goes for Sarah and Jim).
B.3 Scaling Out
The above example only focuses on three followers and three content creators, but the model scales to any number of users. For example, John might have 10K followers on one platform, 5K on a second, and 30K on a third. He will still be able to tweet out to all 45K followers. And each of those users will still receive John’s tweets, as well as any other tweets / broadcasts from content creators on similar applications.
In addition, the model also scales to any other use case which relies on networked relationships, whether those are content creator / follower, mutual friends, professional contacts, and so on. In all cases, the network effects which bring so much value to social networks are preserved at the ecosystem level.
Go back to Section 3: Achieving Interoperability
Appendix C. Application-specific Identities
For privacy reasons, it is important that users can have different identities across applications. For example, a user may wish to have one identity for what they share with their friends and a completely different one for how they appear on a professional networking app, ensuring that there’s no crossover between those two identities.
In the two-layer network design, a user would have a single identity with their platform, and may choose to either use that same identity with any application or create a new identity specific to that application. The diagram below illustrates how this might work.
In this example, a user has the identity of ‘Bob’ with their platform (Platform 1), and has the identities of Bob, Tiger Eye, grilled_cheese, and Snapple, across four different applications. On Application 1, Bob has chosen to disclose his main platform identity by using the same name. But within Applications 2 through 4, neither the application nor any users on that application can see the identity of ‘Bob’.
Only Bob and his platform know his true identity and all of his aliases. The platform uses this information to authenticate Bob with the applications and present the application-level interactions to Bob in a unified view (see Appendix A).
Go back to Section 5: Privacy, Permissions and Censorship
Appendix D. NAP and NPO price negotiations
For a smart contract to execute, both the NAP and NPO must agree to a price. This section explores how that price might be negotiated off-chain.
While the NAP is paying for access to a user, the NPO doesn’t necessarily have the power to withhold that user from the NAP. Simply cutting off a user from an application they are familiar with would result in a bad user experience, and the backlash to the NPO would likely be worse than simply providing access to that user for free.
However, the NPO has several tools and mechanisms to incentivize the NAP to pay. For example, the NPO can make higher-paying applications more prominent within the UI, or may increase the frequency of posts and status updates in the UI stream. It could also encourage and guide users toward higher-paying applications through in-UI promotions. By employing these and other methods, an NPO can get NAPs to compete with each other on price.
Similar types of price competition exist in other industries. For example, suppliers pay for shelf space at grocery stores, advertisers pay for more prominent ad placement on websites, and sponsors pay for better real estate at tradeshows.
NAPs with more loyal user bases will have more negotiating power. Conversely, more commoditized applications are less likely to have as much pricing power, as the NPO can deprioritize them more easily without upsetting its users.
Go back to Section 4: Smart Contract
Appendix E. Implications of sharing revenue with users
In designing a model in which users to earn money while using social media, we must consider potential negative consequences on users’ experience and behavior. At the highest level, two categories of concerns come to mind:
- Given that addiction to social media is a real and widespread problem, do we really want to incentivize people to use social media more than they already do?
- If users begin to earn money in exchange for their social media activity, might that alter their perception such that it feels less enjoyable and more like work?
In considering these questions, it is helpful to estimate the earnings potential for a user. Earning $1, $20, or $1000 per month from social media will lead to very different answers both questions.
Using the US as a baseline, if we look at average revenue per user for current social media monopolies, we would expect the total ecosystem revenue per user to be $10 - $30 per month, and the amount shared with users to be in the $5 - $15 per month.
Of course, these are averages, and there would certainly be users with much higher earnings (e.g. content creators with large followings, most of whom already view social media as work). But for the majority of users, the earnings would be relatively low in terms of behavior-changing potential, especially when we consider why people use social media.
However, moving beyond behavioral economics, there is a more fundamental moral argument for the revenue share which is best illustrated by taking the opposite stance. We would have to argue that users should not get to share in the value that they help to create because we don’t trust that they can be responsible with the income stream, so the NAPs and NPOs should keep the money instead. If that sounds like a steaming pile of self-serving corporate-speak, it’s because it is. We would much rather trust people with their money and their autonomy.
That being said, if any user finds that the revenue share earnings are affecting them negatively, an option could easily be provided to redirect their tokens toward a charity of their choice.
Go back to Section 3: Achieving Interoperability