Status is all about allowing end users to access decentralized ethereum world (Web3). Ethereum ecosystem is in its infancy and most of the tools it provides are still evolving.
One of the existing way to build decentralized application is the DApps stack.
It is essentially the old web2 stack (HTML/JS) with some JS API (web3.js) access to ethereum.
This stack is the one commonly used today and status supports it.
As DApps are an de-facto established standard they run on other browsers: mist, toshi, cipher, ..
Status offers another tool for 3rd party developers: an API. Using it developers can develop bot commands that can have native UI. Those commands live within status and have privileges to interact with its internals.
Make Status awesome for users who just want to find all the coolest DApps out there and use them easily
Status has first class DApps support. Just enter the URL and there you go!
It also offers a curated list of known working DApps. This initiative is being pushed via idea #88 (dapp catalog draft).
DApps on status currently suffer some shortcomings:
- DApps support is not complete and some existing DApps don't work correctly
- most DApps are not mobile optimised
- DApps cannot access status features (contacts, wallet, chats, ...)
Also note DApps are still pretty uncommon and there is a very limited number of interesting DApps.
Make Status awesome for 3rd party devs who want to extend their work and make it mobile compatible easily with Status?
Adapting a DApp for mobile and ensuring it runs fine on status is not currently an easy task.
There is also another way to open up status to external developers: by allowing status to be growable.
2 ideas are currently focusing on this:
- idea #131 (
Status-go SDK) wraps status chat protocol in go (allowing text chatbots) - idea #101 (
extensions) allows 3rd party developers to extend status
The first one allows external processes to interact with status chats. This allows development of textual chatbots (as most other platforms offer). Note How much of the protocol should be reimplemented from status-react?
The second one is deeper and allows to alter/grow status from itself. More flexible it opens the door to new ideas from 3rd party developers. It can be seen as a generalisation of the current API.
идея № 131 (Status-go SDK)