Adding in dapp principles

Signed-off-by: Mary Anthony <mary@blockstack.com>

_develop/dapp_principles.md

@@ -0,0 +1,122 @@
+---
+layout: learn
+permalink: /:collection/:path.html
+---
+# Principles of Blockstack applications
+{:.no_toc}
+
+This section explains what There are as many definitions for a decentralized app
+(DApp) as there are DApp developers.  I don't expect this one will be the
+canonical definition, but I'm writing it down anyway since it serves as my
+"north star" as I work on the Blockstack platform.
+
+* TOC
+{:toc}
+
+
+## Blockstack DApp principles
+
+An application is considered a Blockstack DApp if it adheres to the three
+principles.
+
+### Users own their data
+
+Users own their application data independent of and *outside of* the
+application. Moreover, these applications do not store or replicate user data. A
+Blockstack application is only considered decentralized if its users control
+where their data get hosted and can prove that they created it.
+
+Blockstack applications meet this principle if they use the Gaia storage system.
+Users can choose on an app-by-app basis which Gaia hub serves their application
+data. Users may sign and/or encrypt their data in Gaia end-to-end. All files in
+Gaia are addressed by a user identifier, an application's hostname, and a
+filename. Through Gaia, users can prove data ownership and restrict access.
+
+### Users own their identities
+
+Users are the sole administer of their own independent and unique identifiers.
+Within an applications, users must be distinguishable by unique identifiers. The
+DApp cannot mask or take away a user's identifier, and a user must be able
+to bind their identifier to the data they create.
+
+Blockstack applications have this property because each user can own one or more
+IDs which are owned by a private key under the user's control. The IDs are
+acquired through the Blockstack naming system. First time users that log into
+the Blockstack application get a free `.id` in the Blockstack namespace.
+
+Blockstack IDs are replicated to all peers via a blockchain, this means
+Blockstack cannot hide IDs. Blockstack IDs each have a public key assigned to
+them via the blockchain records that encode their operational history. This
+public key allows users to bind data to their Blockstack IDs through
+cryptographic signatures.
+
+### Users have free choice of clients
+
+Applications must allow users to interact with their identities and data
+independent of the application.  For example, a user that creates data in
+application 'X' must be able access that data from a different app, 'Y'.
+
+It's not enough that the user owns their identity and data -- the user needs to
+also be able to choose which programs they use to interact with them and
+administer them.  In the limit, the user needs to have the freedom to write
+their own client.  An application cannot be considered a DApp unless it
+allows users to interact with their identities and data such that the user can
+later do so via a different DApp.
+
+Blockstack's APIs and SDKs make it easy to build applications that adhere to
+this principle. Existing Blockstack applications have this property today simply
+because they don't have any irreplaceable server-side logic.  
+
+In the future, Blockstack applications must continue to meet the first two
+principles but need not meet this one.  For example, an application could
+encrypt data in-transit between the application's client and the user's chosen
+storage provider. Unless the app divulges the encryption key to the user, then
+the user does not have free choice of clients; they can only use clients that
+the app's servers choose to interact with.
+
+
+## Non-Principles
+
+You'll notice, the Blockstack principles avoid adherence to a particular network topology or
+architecture.  Many DApps have defining characteristics that are implementation-specific rather
+than expressions of overall DApp design goals. These aspects are mentioned here
+as specific non-goals of Blockstack applications.
+
+### DApps have smart contracts
+
+Decentralized apps pre-date blockchains and smart contracts, and even today
+there are popular DApps that do not need them.  Examples include pre-Microsoft
+Skype (which was peer-topeer), Mastadon, IRC, and email.  All Blockstack DApps
+do not use smart contracts at all.
+
+Another word for "smart contract" is "replicated state machine."  Some DApps
+need each peer to execute the same sequence of operations in order to fulfill
+their business needs (in which case a smart contract would be appropriate),
+but many do not.
+
+### DApps have tokens and/or non-fungible assets
+
+Similar to smart contracts, DApps pre-date tokens and non-fungible assets.
+While having a crypto token or asset can help incentivize DApp deployment and
+usage, they are not strictly necessary for their operation.
+
+### DApps use a blockchain
+
+Blockchains are a new tool for DApp developers to help coordinate peers, but
+they are just that -- a tool.  Sometimes they're the right tool for the job, and
+sometimes they are not.
+
+
+## Dapps serve users
+
+Fundamentally, DApps should serve users by preserving user autonomy.  To do so
+the Blockstack principles prevent developers from profiting from either (a)
+building abusive features into DApps like ad networks, or (b) neglecting users
+by failing to build vital safety features like <a href="https://en.wikipedia.org/wiki/Shadow_banning" target="\_blank">shadowbans</a>. Developers cannot profit from abusive features or neglectful designs.  
+
+Because Blockstack applications allow users to own their identity and data and
+has free choice of clients, the user can simply stop or avoid using bad DApps
+with near-zero switching cost. This isn't to say that DApps can't be profitable.
+DApps can still make money for their developers, such as by offering content
+subscriptions or paid-for add-ons. They can broker with third parties on behalf
+of their users to watch ads or share data in exchange for tokens.