Status Alpha Release
tldr; for the first time, you can browse DApps on Android & iOS and have a mobile Ethereum node in your pocket. It’s buggy and for testnet only. If you want stability, sit this one out and we’ll notify you for the beta!
“If you are not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman
Today I feel relieved, excited and a little bit anxious! It’s one challenge to take an idea and will it into existence, and quite another putting it out into the real world — where our software meets the public, where bugs and suggestions will be found, where Status leaves the nest, spreads its wings, starts flying on its own and then to realise, this is just the first step in a long journey ahead.
This journey wouldn’t be possible without our excellent team, of those who I am so incredibly lucky to work with and without their efforts Status wouldn’t be where it is today.
With this release we hope to test Whisper at a larger scale than in-house and find bugs lurking in the basic functionality of Status, which in itself is in a very unstable state.
In this post I would love to show you what we have, set expectations, talk about whats coming next, how you can help us find bugs & contribute (after all, we are entirely open source!)
Please note while we setup Android nightlies (only available in our Slack), the main Android & iOS binaries are available in Google Play & Testflight for those who signed up for early access, of course, if you are so inclined, you can build it yourself by following our Developer Guideline.
The Ultimate Goal
So what is Status and where are we taking this? It is our belief that messenger apps are on the path to becoming gateways to our economies and social lives, they have the highest retention rates on user acquisition and more time is spent in messenger apps than any others. This, combined with a strategy for mass adoption we believe solves a real problem in the on-boarding of people onto the Blockchain — our favourite being Ethereum.
With this in mind, Status aims to be a visual expression of what we believe Ethereum represents, it is a mobile Operating System for the Ethereum Virtual Machine — more concretely Status is hybrid between a decentralised, encrypted instant messenger and a Web 3.0 browser — a gateway to the decentralised application ecosystem. Status runs on Android & iOS.
In short, Status is a decentralised WeChat-style omnibus app, built entirely on Ethereum technologies — and it’s completely open source.
If this is new to you, check out our Introductory post or our DEVCON2 presentation.
Expectations
In this alpha, Status is stripped down, and runs ONLY on the ROPSTEN TESTNET. It certainly has its rough edges and there is no developer tooling. The technologies that make Status possible are just as fresh as Status — we depend on:
- The fantastic light client protocol (LES) by Zsolt Felföldi — which while is jaw dropping to use on your smartphone, and is alpha quality itself.
- For messaging, we depend on Ethereum’s little-known Whisper protocol (SHH) which is just now seeing new activity with a v5 spec and Vlad( gluk256) working on its implementation and we will also contribute to its success. To know more I highly recommend watching Gavins DEVCON1 talk Shh! Whisper.
We hope this alpha shows the beginnings of a friendly, intuitive experience for Ethereum and what will be hopefully the start of a fantastic client for the Ethereum network.
What’s in Status?
When you first run Status you will be greeted by your first autonomous entity, Console!
Console
Console is a built-in DApp that helps you setup your account, optionally synchronise your phone contacts, and execute javascript similar to geth console, Console allows you to execute custom javascript & get ETH easily using the !faucet
command.
Any non-command sent to Console is evaluated as Javascript, it provides suggestions and minor documentation for the web3.js
object. Tapping on the suggestion will autocomplete in the chat input. Eval'd output is in the form of a message from Console. We haven’t yet solved the halting problem here, so yes it is possible to cause a crash.
Hierarchal Deterministic Keys
We’ve implemented HD Keys (BIP32, BIP39, BIP42) in Go, you can find the code for this in status-go. This allows us to provide keypair recovery via passphrase + password, as well as have a recoverable identity in Whisper that you can also transact with. Of course this also allows us to generate sub-accounts which will appear in future versions.
Contact Synchronisation
How we currently do contact syncing by phone in the alpha isn’t ideal, our method is not dissimilar to how most messenger apps do it, we verify your phone number, hash your contacts and they are shared with our server, which does the matching and returns the results.
We plan to make this better by hashing pairs of numbers (yours and contact) then truncating this so collisions are possible. This of course will require verification of contacts out-of-band but allows for some benefits such as:
- Making Rainbow Table attacks Impractical
- Gives plausible deniability on contacts
- Can decentralise the information load
For more details you can see our draft notes on this here.
Once you’ve setup your HD account and optionally synced your contacts, you will be able to access the rest of the application, pressing the back button will take you to the chat list in Status, you will see our first DApp — Wallet and Jarrad (me).
Wallet
Wallet is pretty self explanatory — you can currently use it to manage your transactions, see your current balance, send ETH to and from addresses, and contacts within Status.
At the moment it is fairly limited and will go under a visual redesign before the beta is out. Wallet will have advanced ERC20 support (the token registry found in Parity as well as custom add/remove for tokens) as well as allowing you to create more addresses under your logged in account.
Wallet also exposes two commands !send
& !request
to be used in chat for doing transactions within the chat context. From within the wallet you can use QR to transact or send/receive directly to a contact. In chat, you access them from the command list icon or just type them in.
Jarrad
Yep that’s me, I’ll be your first human contact, feel free to chat if I’m online!
The Chat Context
Right now Status supports One-to-One and Group chat, One-to-One is straightforward using ssh.post
, our application protocol makes up for the lack of inboxing in Whisper — that is when you send a message it is not stored anywhere, instead, your message bounces around the network node-to-node until its TTL expires. We solve this lack of inboxing by using a logic clock for stable chat history and message acknowledgment and message re-transmission.
Group Chat however is not implemented in the current versions of Whisper, our current application protocol allows for the group creator to add/remove users — the group conversation is encrypted and sent over a topic, the group owner sends a new keypair to each participant in the group every time a new person is removed. This is by no means finalised and with research, will develop over time.
The chat context supports custom message types, which are created using a subset of react native. You can see an example of this with the !send
command, which has some mild formatting of the text.
Each chat context has a command !browse
- allowing users to access a webview. With !browse
you can loosely imagine a chat context as being like a browser tab (albeit not a very good one atm). As well as Otto VM jails for DApps running within the context.
Limitations
There are some known issues that we may face in the alpha. I’ll address these issues and propose plans for solutions.
The first is peer discovery — in go-ethereum, peer discovery happens over UDP, this is a problem for some mobile carriers as UDP can be firewalled on 3g/4g connections — the reason for this is rumoured to be an anticompetitive move against VOIP solutions running over a data connection. It looks like in a future version of go-ethereum there will be an implementation of TCP peer discovery as a fallback.
Most of the Ethereum network does not support Whisper, the SHH protocol is not enabled by default. Furthermore WhisperV5 has made it into go-ethereum 1.5 — however at the time of writing it is unstable so we are using WhisperV2 (the latest from last week). This means if you want to contribute to the network you will have to run our custom version of geth that has 1.5 and the whisper rollback.
To alleviate these main issues for the alpha, we are running 5 testnet LES servers with shh v2 enabled and Status is aware of these nodes. However if they become saturated with connections and your mobile carrier blocks UDP you will have to resort to a Wifi connection to discover more peers.
Another issue is one of convenience and a requirement for mass adoption — Notifications. Because of Whisper’s ‘DHT-UDP’-like nature, receiving notifications when you don’t have Status open is abit of a hurdle, this is not easily solved because:
- The inherent way p2p technologies work
- Battery consumption management on mobile devices
In order for you to be aware of an incoming message, or to be notified by a log message, you have to be connected to the network and have Ethereum running in the background. On Android we partially solve this by running go-ethereum within a service, however the service can be killed at anytime by the Android Operating System should resources be required for something else or even when the device is idle. On iOS it is not possible to run a service and pass App Store review.
Push notifications on mobile devices are usually done via either a long open connection on Android or by using a service like GCM and Apple Push Notification Service. This is largely due to battery consumption, although the net result has the client->server mentality baked into it. Another issue with this is that GCM is blocked in China.
The short term solution slated for Beta will be to send the whisper encrypted payload through our intermediary server (should you wish), which will pass it on to the receiver (should they be subscribed) via one of the above mentioned routes. This will feel more like a messenger and be more convenient — the tradeoff is optional use of centralisation, which would put us on par with how all other messengers work (in which centralisation is mandatory). The longer term solution will be an implementation of private Whisper servers, as mentioned in the Whisper v5 spec.
Discover
Discover let’s you find people & DApps by hashtags, it is our hope that this will help increase market liquidity and token utility by making it easier to find interesting things in the Ethereum network.
Here’s how it currently works;
- When a user (let’s call him Vitalik) updates his status to include #hashtags, he sends a discovery message, this message is sent individually to each of his contacts. There is probably a better way of doing it, but this way of dealing with messages allows us to use our application protocol to control the delivery flow and resend messages to specific recipients if needed.
- When Jeff (who is a contact of Vitalik) receives a discovery message, his client saves it to the internal database.
- There is also Gavin (who is a contact of Jeff, but knows nothing about Vitalik). Gavin periodically (on login and every 10 minutes) requests messages from his contacts by sending messages with type :discoveries-request. Of course, we don’t request new messages when we don’t have any response for a long time.
- When Jeff receives :discoveries-request message, his client loads the weighted messages from the database and sends to Gavin several response messages (with type :discoveries-response). Each of these messages contains no more than 10 discovery messages from the other users.
- When Gavin receives :discoveries-response messages, they simply save these messages to database and displays them in Discover.
All the steps above allow Gavin to receive discovery messages from Vitalik although they are not directly connected. Of course, the same combination of steps also allows Vitalik to receive discovery messages from Gavin.
And, of course, there are some improvements we can make, but for now everything works ‘fine’, fast enough, and without any redundant complications. Whisper should also provide us with spam protection — but if not, we will implement this too.
To generate the list of weighted messages we dynamically calculate the extra field called priority and sort all our messages by priority. There are several things we include in this calculation:
- Message is newer => priority is higher;
- Author of the message exists in your contacts list => priority is higher;
- There is a chat with this user => priority is higher;
- The user was online recently => priority is higher.
This provides hurdles for bad actors to jump if they are to penetrate the network while rewarding those who provide real value that the community socially values.
The function calculate-priority
can be found in status-react/discovery/subs.cljs.
There is a known issue with discover messages in that they are not signed, so they can be tampered with on redelivery. This will be solved with ecrecover.
Languages
Status is also multi-lingual! 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!
In-house we only speak Russian, Ukrainian and English so if you see something weird in the translations, please let us know!
Whats next?
A lot of work has gone into Status so far, but really it is just the foundation for what’s to come. We want to work with DApp developers to provide them tooling and start implementing more Smart Contract & DApp examples.
For Beta we’re looking to implement the following:
Importing of Wallets
Right now there is no GUI to import wallets. We’ll be adding a feature to import existing wallets and attach them to your account.
Solidity Support
Currently it is not possible to compile Solidity code on the device, but we’re working on it!
Developer tooling & expose Chat API
This is one of our biggest features and promises — to make it easy for DApp developers to get users and integrate into the chat context (as well as run any html/js DApp) — we use our own API internally. You can see examples of this in status-react/resources/*.js. But currently there is no way for 3rd parties to attach DApps to accounts. This is our biggest priority on the development side.
Contact & Chat management
Simple chat & contact management along with managing groups of contacts — it’s a basic feature and trivial to implement, we recognise we dropped the ball here.
Swarm
Swarm is now in go-ethereum master, we need to see how to run the swarm daemon & adapt our webview client to make bzz URIs available— we’re super excited to see this happen as this will enable us to implement audio messages and image sharing and really make Status a fully decentralised client.
There is more on our roadmap for next year, but I will leave them for future blog posts.
Permissions
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!
- Contacts, SMS, Telephone — these are for an optional step of phone contact synchronisation. We don’t use them unless you tap on the phone sync request message.
- Location — Currently used for our toy
!location
command. Our aim is to provide this to DApps For things like sharing location with friends, ordering food, or self-driving cars. - Microphone — In this version, we don’t need it, it’s there because we intended to send audio messages over Whisper, in practice this was a bad idea. We still intend to offer Audio messages in Beta so it’s going to stay. It is also used in Instabug which we use to collect feedback.
- Storage — We need a place to put the blockchain data.
- Camera — We use this for setting your profile picture and for reading QR codes.
Where to get it
Currently it is only available to early adopters, but this blog post will be updated at a future date. You can sign up from our home page to be part of our next round of invites.
If you want bleeding edge, Android Nightlies are posted in our Slack.
Bug reporting
To report a bug shake your phone! We’re using Instabug to collect feedback and crashes. You can take screenshots & video and send them to us.
Contribute
Finally, if you like what we’re doing and want to help us out. Check out our https://wiki.status.im
Hopefully this alpha demonstrates where we’re at and ignites your imagination as to what Status will look like in the near future, we hope you will share our vision & join us on this journey.
Still have more questions? Please read our FAQ or come ask in the Slack.
Thanks,
Jarrad, Carl & the Status team