add topics
This commit is contained in:
parent
ebcca45653
commit
0e517314b6
|
@ -1,5 +1,6 @@
|
|||
# Data
|
||||
|
||||
Data structures, data availability, persistence, and mutability in decentralized applications.
|
||||
Data portability
|
||||
|
||||
Decentralized systems do not have a single central system to coordinate updates.
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
One of the most acute problems with centralized platforms is the need to develop one-size-fits-all moderation policies for billions of users. Decentralizing social platforms places the power to determine moderation policies in the hands of users or communities.
|
||||
|
||||
## Moderation in federated platforms
|
||||
## Moderation in federated systems
|
||||
|
||||
### Matrix
|
||||
|
||||
|
|
|
@ -0,0 +1,46 @@
|
|||
# Monetization & Business Models
|
||||
|
||||
Open protocols allow any application to build on them. Open access creates competition, and makes it harder for any single application to establish a sustainable business model. Many decentralized projects run on volunteer work and donations. This funding method will not be covered. This document will explore examples of decentralized projects that have succeeded or failed to monetize, as well as emerging and experimental monetization possibilities.
|
||||
|
||||
Three layers of business models can be considered: application level, provider level, and protocol level. Application level business models for decentralized social applications are similar to current business models in centralized social applications. Providers are servers (in federated systems) or supernodes (in p2p systems) that provide capacity to the network, and may charge for their services. Protocol level monetization was not a proven business model until cryptocurrencies came into existence, and it is still at an experimental stage.
|
||||
|
||||
## Application Level
|
||||
|
||||
Protocols must be open source in order to be used and adopted. Applications built on top of open protocols do not necessarily have to be open source. Gmail is an example of a highly successful application built on top of open, federated email protocols. Every popular centralized web application is built on top of the open protocols of the web. Because of this, many of the business models for decentralized applications are already familiar.
|
||||
|
||||
Advertising
|
||||
|
||||
In-app purchases
|
||||
|
||||
- Charge for promoted tweets
|
||||
|
||||
Transaction fees on
|
||||
|
||||
- User monetization of premium content
|
||||
- User tips and donations
|
||||
|
||||
Premium experience
|
||||
|
||||
- Users can pay to not be shown ads
|
||||
|
||||
# Provider Level
|
||||
|
||||
If applications access the provider, (as in Solid, where applications access user data through pods), the provider can charge a commission of the revenues of each application.
|
||||
|
||||
If users access the provider (as in federated systems where a user signs up to a server), the provider could charge the user a fee, perhaps for premium features like extra storage. Up-front membership fees for users tend to discourage adoption of social applications, where users have come to expect free service.
|
||||
|
||||
## Protocol Level
|
||||
|
||||
Protocol level business models have been explored in recent years through cryptocurrencies.
|
||||
|
||||
One method is the creation of a token used for transactions internal to the protocol. An example is Facebook's Libra.
|
||||
|
||||
Existing cryptocurrencies can also be used for protocol-level business models.
|
||||
|
||||
Servers could function as Lightning hubs that route Bitcoin payments through the social graph using payment channels, and collect fees for doing so.
|
||||
|
||||
Sell username registrations
|
||||
|
||||
https://blog.ethereum.org/2014/04/30/decentralized-protocol-monetization-and-forks/
|
||||
|
||||
https://avc.com/2016/07/the-golden-age-of-open-protocols/
|
Loading…
Reference in New Issue