DavidAJohnston / DecentralizedApplications

Decentralized Applications White Paper and Spec
MIT License
878 stars 159 forks source link

DAPP Definition #21

Open Dustin-Byington opened 9 years ago

Dustin-Byington commented 9 years ago

I reworked the DApp definition in README after thinking through whether or not Project SAFE is a DApp per the current definition.

There seems to be a bit of a contradiction between point 1 of the definition of a DApp and the project-safe Whitepaper.

From DApp Whitepaper:

'The application must be completely open-source, it must operate autonomously, with no entity controlling the majority of its tokens, and its data and records of operation must be cryptographically stored in a ---public---, decentralized ---block chain---'

However, the SAFE network doesn't use a blockchain and the transaction records can be very private.

'Additionally, as a fully decentralised network, the SAFE approach allows transactions to be made and confirmed at network speed (under a second in some cases). ---This is due to a distributed Transaction Manager as opposed to a blockchain---...This temporary receipt can be stored permanently allowing proof of the transaction to be maintained ---or destroyed immediately after the transaction is completed, leaving no trace on the network---'

One problem I foresee is that Project SAFE won't be the only one to strive to provide the users of their application with increased privacy nor will they be the only one to continue to develop new forms of decentralized databases. Per my reading of the current DApp definition this would rule out all of these projects from being considered as DApps.

What if the definition was instead focused on the governing bodies (projects/foundations/etc) operating in a public manner and leveraging a bitcoin-like decentralized database.

Disclaimer! This is in fact, in line with my long held personal world view that there should be total transparency at the core (governments or in our case projects/foundations) lots of transparency in the middle (companies or the in our case the applications) and opaqueness at the fringes (individuals or in our case the use of those applications by individuals).

Here's the updated definition along with some cosmetic changes.

A DApp has the following characteristics:

  1. Tokens must be necessary for the use of a DApp and any contributions from users should be rewarded by payment in a DApp's tokens. Tokens should be generated according to a standard algorithm or set of criteria. Some or all of a DApp's tokens may be issued at the beginning of the operation.
  2. A DApp may adapt its protocol in response to proposed improvements and market feedback but all changes must be decided by majority consensus of its users.
  3. A DApp must be completely open-source and operate autonomously, with no single entity controlling the majority of its tokens. The operations, actions, & decisions of any DApp governing bodies (such as a foundation to distribute tokens for development) must be cryptographically stored in a public, decentralized database such as a block chain.

Some explanation on my cosmetic changes:

1 - In the current definition tokens are referenced in point 1 but haven't been defined it yet. I think if we swapped 1 & 2 it would clear things up quite a bit.

2 - Leading with tokens within bullet point 1 is strong b/c tokenization is the big idea here and the subsequent points are how to issue tokens and then manage the project in a decentralized manner using them.

3 - We've got a bit of a language/branding hurdle to overcome. It would be useful to start beating 'DApp' into people's brains whenever possible - so I swapped in 'DApp' in place of 'application' and changed the lead in sentence.

Happy to discuss further and/or initiate a pull request if you like these changes!

-Dustin

DavidAJohnston commented 9 years ago

Thanks Dustin : )