Frequently Asked Questions

From Status Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search
This article seems to be up-to-date on 08 June 2018 (may need review)

General FAQs

Why a Messenger?

When looking at how to achieve mass adoption for a client, we looked at how people interact with their devices. For instance, as of 2014 more time is spent on mobile devices compared with desktop PCs. Moreover, a third of that total time is spent within instant messaging applications. Amongst mobile apps, instant messengers have the highest retention rates. Once installed they become sticky and typically users won't uninstall immediately. Therefore, for mass adoption an instant messenger simply makes senses. Once network effects come into play and user's friends also begin to utilise the app the average user lifetime skyrockets. When you start thinking about this as a user base and how to connect that with Ethereum, things like payments and applications built atop of Ethereum and integrated into a conversational interface begin to seem like a clear path forward.

Ultimately what we're building is a hybrid browser and messenger, this allows us to have the best chance at casting the widest net which permits us to focus on user acquisition, staying agnostic and as close as possible to the principles that Ethereum embodies.

Does Status support DApps that have their own web page ?

Yes, we absolutely support DApps on their own webpage and are striving for SWARM support also. Chances are, if a DApp works in Mist or MetaMask it is likely to work in Status!

If your web-based DApp renders on mobile, use the big "+" button on the homepage, navigate to the DApps page type in the web URL where your DApp is being hosted. You can also debug any issues by using Chrome dev tools very easily.

Where are my messages in the app stored? Are they on chain?

Messages in the Status app are stored on your phone and an offline inbox server but all messages are fully encrypted. Messages go over Whisper (shh) which is a dark routed gossip protocol that is a part of the Ethereum stack. This means the messages are being passed over devp2p (the transport layer for the whole of Ethereum), but are not going through the EVM, i.e. they are not "on the blockchain" and don't cost anything to send.

Do I have to run go-ethereum myself or on server?

Status includes go-ethereum and connects directly to the Ethereum network. All you need to do is run the Status app!

We are working on both the Light Ethereum Service (LES) and a new branch called the Ultra Light Client (ULC). You can find this work in our Codebase and we are absolutely committed to getting light nodes working on resource restricted devices.

When did you start coding and how you are funded?

Status is largely self-funded. We've been working on it since prior to Devcon1 in 2015, and we were awarded a Devgrant to port EthereumJ to Android prior to that.

EthereumJ has different goals, its developers intended for server use and had no interest in supporting the light client protocol, another large factor is we wanted largely a single codebase for multiple platforms, we had Java running on iOS and Android, we want unify the GUI but the means to do that (JavaFX) is really not suited to mobile devices.

Our current approach allows us to get bleeding edge tech and stability of geth whilst maintaining a single codebase.

I am new to Ethereum & Blockchain. I would like to contribute to the project, where would you suggest I start?

To get up to speed with Ethereum, here are a few resources to get you started: EthDocs , , Ethereum Stack Exchange , Ethereum on YouTube , Ethereum from scratch

For contributing to Status directly you will want to check out our Developer Documentation

I have a DApp that runs on Mist how can I test it in Status?

If your web-based DApp renders on mobile, use the big "+" button on the homepage, navigate to the DApps page type in the web URL where your DApp is being hosted. You can also debug any issues by using Chrome dev tools very easily.

What is the "jail" in your status-react code?

Allowing users to browse any DApp means we need to protect them properly from potentially malicious code. Therefore, all the DApps javascript code is executed in Otto VM jail that is the same javascript engine go-ethereum uses. That way your code is executed in a "jail" and shouldn't interfere with the rest of Status.

For web DApps, we rely on the webview to correctly jail javascript.

Is it going to be for Android only?

No, we currently support both iOS and Android and have a dedicated team working on desktop integration.

Is it possible to install Status & how can I test?

We are working through getting more TestFlight invites out for iOS, so make sure to sign up on the homepage. For Android users you can navigate to here and download an APK for yourself. Alternatively, we have a section on how to </nowiki>build it yourself.

What languages do you support?

We’re currently supporting 30 languages — this includes; English, 官話, 官话, 廣東話, 上海话, Nederlands, Français, Deutsch, हिन्दी, Magyar, Italiano, 日本語, 한국어, Polski, Português brasileiro, Português europeu, Română, Slovenski, Español, Español (Latin-America), Swahili, Svenska, Suisse française, Schweizerdeutsch, Svizzera Italiana, ภาษาไทย, Türkçe, русский, українська, اُردُو & Tiếng Việt!

If you see a typo, mistranslation or something missing, don't hesitate to let us know via the Status Riot, or fix it yourself using our Translation Guide! <Needs link

What about all these permissions in the app?

Permissions are always a hot topic for apps, we hate the way we’re doing them too. The good news is it’s only like this for alpha and in production we’ll make permission usage on-demand. At the moment there’s many moving parts and a bunch of react-native dependencies (and Instabug) which don’t have code to ask on-demand. Thanks for understanding!

  • Camera — We use this for setting your profile picture and for reading QR codes and only ask when it is absolutely necessary to, not before.

How can I install a nightly for android?

Here you go!

Is there a rationale for using simple optimizations only for prod builds?

The difference in size is about 300KB, anyway RN packager makes some magic with js after cljs compiler. The difference in error output is that with :simple we have much more useful info if error happens, not just a.b.adsfas is undefined.

The only reason why we added `:advanced` was that when resulting cjs was small RN packager ran much faster. And we didn’t meet that non-configurable 300s timeout for packager

Is that intentional? Alice has account Sneaky White Koala. Bob has account Cool Damp Bear

When Alice adds Bob's account, she will see him as e.g. Breezy Tall Elephant Until Bob repays the honors.

the names are not currently deterministic so the best option at the time, was to randomly generate one well, we intentionally did that behavior but it's not desirable in this revision

Is there no way to skip new account creation wizard after a fresh install? If e.g. I just installed Status on a new device, but only with intention to recover my existing account there?

We'll be redesigning the onboarding but currently, no, the reason was back in the day 90% of people would be making a new account

Saved username, image, etc are only stored in the device's local storage, right? Not supposed to be restored ?

That's correct, we have no servers to store that on (as we are a p2p application), when we have Light Swarm Clients we can have some kind of persistent state, photo/audio messaging, encrypted app-db and uploaded to swarm for retrieval

Why do we use async JS calls in RN but sometimes sync calls for bots?

Different JS environments have different capabilities. In general we want to use async.

React Native

  • RN doesn’t support sync http calls (that’s why we didn’t use sync calls with web3 when we used http provider)
  • RN doesn’t allow to make sync calls to native modules, currently we are calling CallRPC through native modules, that’s why calls can be only async


Dapps are running in webview env which supports sync calls in some cases (only android), but we don’t support sync calls for iOS, that will not work. Mostly any call to web3 causes http request, so using sync call is a bad idea in one threaded env, in any case. So i wouldn’t use it in dapps.


  • Both sync and async calls are available in otto
  • Only async in rn
  • Only async in iOS webview
  • Both async/sync in Android webview

FAQ about Beta

Details here