Status Beta by March (Dogfooding)

[0xc1c4da]

Preamble

Idea: DEV#26
Title: Status Beta
Status: In Progress
Created: 2017-11-20
Replaces: PROC#019

Summary

This issue is a meta-summary of some ideas, goals, and considerations around the beta release of Status. The goal is to

Swarm Participants

• Lead Contributor: Oskar
• Testing & Evaluation: Anna
• PM: Chad
• UX (if relevant): Andrei

Product Overview

The vision for Status is to drive mass-adoption of Ethereum.
As a first step, the beta will focus on shipping these core features:

• Send and receive encrypted messages, smart contracts, and payments.
• Browse, chat, and interact with decentralized applications.
• Store and control crypto-assets with the built-in Status Wallet.

Product Description

The result of the beta will create the leanest product that can validate the vision outlined above in the pursuit of exposing new users to Ethereum and driving the adoption of its technologies. The beta should do just enough to showcase each core foundation, validate our assumptions, and inform future work.

Following from the stated goals of Status, the beta should at a minimum be based on a chat form factor that facilitates interaction with messaging, payments, dapps, wallet-based crypto-assets. We intend to underpromise and overdeliver.

These goals are at a high level, and rather than listing all the required features each Swarm will find their own way to meet these goals so that a user can:

• Send and receive messages
  • With offline and push notification support
• Send and receive payments
  • Using ETH and at least SNT
• Browse and interact with dapps
  • From our curated list, or by adding a URL
• Store assets in the wallet
• Utilize a chat form factor
  • Simplify the UX and orientate users on clear actions and expectations (doc looking at simplified features and UI)
  • Remove redundancy and consolidate chats, contacts, and discover into one tab

Additionally there are core support functions, such as signup, settings, etc. These support the core features.

Also there are technical goals such as performance, security that need to be considered.

And importantly, the goal of the beta is to ship within an accelerated timeline. Done is better than perfect.

The beta is NOT about extended functionality on top of the core foundation. Instead the beta aims to enable these additional layers later, such as SNT use cases, a sticker market, DApp directory, teller network, group chat etc. All of these will rely on the chat/payment/dapp/wallet foundation established by the beta.

We should not work on something that isn’t explicitly outlined as fundamental in the Status white paper vision and goals.

To support these anti-goals some features will be (temporarily) removed from the current build as they are not explicitly enabling the core vision.

Audience

Whilst the long term vision of Status is driving mass-adoption of the app and Ethereum, the beta is not for everyone. Marketing has focused the initial target groups which are DApp developers, crypto-traders, and tech enthusiasts. These are users that will have some familiarity with blockchain, cryptocurrency, and privacy.

Requirements & Dependancies

• #1 Offline inboxing and persistent messaging
• #3 ERC20 token support
• #24 Onboarding experience
• #55 Lightning fast messaging
• #58 Use Mainnet as the default network
• #61 App structure refinement
• #64 Release swarm for continuous delivery

Minimum Viable Product

Goal Date:

Description:

Dates

Goal Date:

Description:

Testing Days required:

Success Metrics

Copyright

Copyright and related rights waived via CC0.

[oskarth]

Good stuff, thanks for this. I closed #19 as this idea to large extent replaces it with more high resolution.

@jarradh Can we please edit the requirement in section: Push Notifications & Offline Inboxing to say Offline inboxing and remove the mention of push notifications in the body. This would then reflect the specified scope of the idea. This is necessary to keep focus and scope limited for now. In the end it is very likely the resulting capability we provide turns out to have a lot of overlap (MASTERNODES!) but the specifics of the path will be delineated as we deliver a basic MVP of offline inboxing and learn more about the problem domain.

[0xc1c4da]

Thanks @oskarth I'm not familiar with the push notifications implementation but my understanding is that it should be another idea and integrate with offline inboxing? MASTERNODES!

[oskarth]

@jarradh Correct. Once end to end MVP for offline inboxing exists / is closer to being completed we are going to specify future iterations of offline inboxing. It is likely this will include at least a mention of push notifications capability, and then we can decide specifics of where this capability lies in terms of the ideas framework.

[annadanchenko]

@jarradh confirmed

[jeluard]

Great overview. Deadline is tight and scope is broad but this provide good guidance on what is essential.
In my view status-desktop, while not must have in the deliverable sense, is the main driving force behind dogfooding and will force us to have a usable product.

[0xc1c4da]

@jeluard I think if Desktop is the main driving force behind dogfooding, then we have huge problems we're ignoring.

[chadyj]

Quick update: Work on the beta is progressing with renewed areas of focus. I updated the main issue to reflect the latest thinking and prioritization.

[chadyj]

Update:

• Lots of new UX improvements happening in App structure refinement #61 including a new DApp browser UI, tab UI improvements, and a beautiful new Profile screen and QR viewer.
• Many many many bugs fixed in Release swarm for continuous delivery #64 and one step closer to better and regular releases.
• Progress toward mainnet with a security audit kicking off in Use Mainnet as the default network #58 .
• Continued performance improvements in Lightning fast messaging and cold phone #55.
• Regrouped onboarding team for Onboarding experience #24 with a new kick off happening soon.

[oskarth]

Not really a swarm, more of a meta issue. De facto not used. Work captured in existing swarms and OKRs help with goal alignments. Can always re-evaluate and easy to reverse.