From b159f73a15e3d03badcd2333ca16eb0d0e59b901 Mon Sep 17 00:00:00 2001 From: Mary Anthony Date: Thu, 25 Oct 2018 12:46:35 -0700 Subject: [PATCH] Adding in dapp principles Signed-off-by: Mary Anthony --- _develop/dapp_principles.md | 122 ++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 _develop/dapp_principles.md diff --git a/_develop/dapp_principles.md b/_develop/dapp_principles.md new file mode 100644 index 00000000..3b540d7f --- /dev/null +++ b/_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 shadowbans. 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.