Public Launch Scope

Status Mobile
1

Congratulations to everyone for hitting the beta milestone and delivering a major Q2 objective! Beta on mainnet has been no small feat.

As the dust settles from the beta launch we can all turn our focus to the next major milestone, launching publicly on the iOS App Store and Android Play Store! But that raises the question, what are our must-haves and hard blockers? And do we have any time constraints?

Just as we had a security audit as a hard blocker for beta, Status will again undergo a security audit for the public launch. The audit is expected to run from September 15-30 with a feature freeze before that. After the audit concludes there will be time to implement fixes, as well as undergo a few weeks of final testing before launch.

The audit and feature freeze gives us a deadline to prioritize what will provide Status the best foundation for launch. Any major new features will need to be included before the feature freeze if we want to launch with a fully audited app.

As for must-have features, that decision is in the hands of the community and teams. Please comment here with what Status needs for the public launch to be both a quality launch and also embody our values. Or alternatively we may have everything we need ready to go?

So far I’ve heard some of these suggestions:

  • Seamless upgrades
  • Solid chat encryption (eg forward secrecy, double ratchet)
  • ENS support
  • LES protocol as an option, as well as user defined RPC
  • Better chat moderation and spam prevention
  • Replacing Mixpanel
  • More SNT utility
  • Responding to bugs/features/issues/requests surfaced in the beta by users
  • Multiple languages
  • We don’t need anything else. Let’s harden the beta and get it audited and ship!

Do these need to be in the public launch? Anything else? Or are we already set with the beta scope? Please let us know!

(And ideally please make an argument about why it is essential to the public launch. Do we absolutely need to have it? Should the launch be blocked for feature X? Or can it wait a future version? The public launch is just the beginning and we have years ahead of us to keep building on our foundation so we have to be diligent and mindful about what is essential and what can wait.)

One major concern is that new work or features that weren’t in the audit scope may mean that we will either ship features that haven’t been audited, or will require a third audit, or some other solution. We should gauge our comfort level around these constraints.

Once the issues are discussed and finalized we can continue with a launch milestone on Github with blockers and must-haves to give org-level visibility.

edit: changed “1.0” to “public launch”

3 Likes
2

Quick follow up: I got a great question on how this relates to OKR’s. We are still discussing OKR’s and voting which will inform our thinking, but one proposed OKR is dedicated to launching 1.0 publicly.

Leading votes for launching would be a good community signal to keep 1.0 focused on the current scope.

1 Like
3

Following the Wallet team discussion, we have agreed there are no notable blockers or must haves. Just a steady stream of:

a) bug fixes,
b) refactors and improvements,
c) responding to user needs/bugs/reports surfaced in the beta

As far as Wallet is concerned, feature-wise we’re ready to launch 1.0

Let’s harden the beta and get it audited and ship!

3 Likes
4

I would include this:

Integrate native navigation transitions

Among bug fixes and other complex problems that everybody is solving It looks insignificant.
But it will add a native feeling to the app that users are used to having in others apps.

3 Likes
5

This needs to be discussed on the DApp team’s next sync, but I think there are just 2 must-haves for us:

  1. Address security issues
  • 3rd party dependencies for collectibles
  • Injection of web3 object by our browser
  • HTTPS calls - lack of proper security validation
  • Sanitizing URLs and strings
  1. Better DApp curation method

    We need a more sustainable and scalable way of keeping the DApp list…
  • Fresh, interesting, conducive to discovery
  • Compliant with app store policies
  • Responsive to integration requests
  • Forward-looking (TCR)
1 Like
6

Got some more feedback:

There is some hesitation about launching until we get everything right, such as completing our mission, fulfilling our promises, and being 100% decentralized and completely secure. These are fair and important points.

So it will be important to communicate that Status isn’t complete, and is instead on the long road to fulfilling our mission one step (and release) at a time. And we can do this openly and transparently in the public domain rather than behind the closed Testflight.

1.0 isn’t the end, but the beginning of our journey.

2 Likes
7

Marketing should never drive product timelines…we are here to support you all. However, it is worth noting that there are opportunities in Q3/Q4 for significant growth and to move our marketing efforts past awareness and into acquisition. Also, the marketing team has held numerous community calls over past few weeks and some common question are “When can I download in the app store?” and “When will I be able to actually use Status?”. There is a common misconception amongst many people that Status is not “ready for actual use” because we are still in Beta. The product has come so far and it is totally usable now.

There are some very interesting plans which can drive immediate installs and usage in Q3/Q4 such as:

  1. Integration of Status into key events for things such as payments, registration, public chats

  2. Partnership with DApps available within Status

These plans are really exciting but we currently still run into obstacles and hoops of requiring users to request access and go through the test flight process. The sign up flow is a massive barrier to entry for people and makes acquisition marketing and use at such events significantly more troublesome. To miss out on these opportunities would be a fairly large miss.

As mentioned, marketing will never drive product timelines, but people is asking for 1.0. I am also aware that security and decentralization is of utmost importance and we should not sacrifice those core values.

1 Like
8

Currently the in-product content is being improved for clarity / accuracy. This is good for testing mode, but I think 1.0 would be the right milestone to rollout a more cohesive product content strategy, to include

  • Injection of brand voice & consistent style across UI
  • Creation / strategic linking of support content in UI

These may not be hard blockers, but I think it’s important to begin the journey with the right tone level of helpfulness.

2 Likes
9

I think it’s important to begin the journey with the right tone level of helpfulness.

Thanks @Obi2020, great point. I’ll follow up about this with you and see what we can do.

10

Got some more great feedback. Thanks for those sending it through!

In this thread I connected our public launch (iOS App Store, etc) with a version number (1.0). But I’ve heard that “1.0” implies something complete, when I think we all agree that we are starting our mission, not finalizing it.

The reason I gave the public launch a “1.0” version number was due to Apple’s App Store guidelines, particularly sections 2.1 and 2.1 that state app’s must be final. Beta apps must use Testflight. However it may be possible to ship an app with a 0.10.0 version number and reframe this discussion from a “1.0” scope to a “public launch” scope.

Would people be more comfortable soft-launching the app publicly with a version like 0.10.0 and not proclaiming a “complete 1.0” version? We can still continue developing Status in the open, but now the app distribution will be open as well.

1 Like
11

Makes a lot of sense to have the app public. We need all the users feedback we can get!

Fixing security issues is definitely a strong one, especially considering we will have another security audit round.

Once public we will continue to ship every 2 weeks, as usual.

1 Like
12

I think it’s definitely worth checking if it would be feasible to launch with a 0.10.0 version number. I have the feeling that time spent investigating that will probably be time saved many times over not explaining to users why 1.0 doesn’t include certain things they might implicitly expect (e.g PFS, not relying on centralized services like infura.io, etherscan.io, etc).

1 Like
13

Looks like we can. In App Store Connect the version was set to 1.0, but I was able to change it to 0.10.0 as well as confirm that a 0.9.x build could be submitted.

I’ll replace “1.0” with “public” in this thread to better reflect the current state.

1 Like
14

The product has come so far and it is totally usable now.

yes it’s usable, but I still I disagree, on the communications front we have been saying secure messenger, but we don’t include perfect forward secrecy. This is akin to outright lying.

To deploy Status onto the public we are not only being disingenuous but it could be potentially outright abusive. Messages people think are private may be somehow leaked, until now we haven’t done a proper threat analysis to really know. We should only do so with a clear conscience that we did everything in our power to ensure we are delivering our promises to people.

There’s a handful of critical items that must be cleared up in our Wall of Shame before we think about a public release. Not doing so is disrespectful of our users and the technology.

Also I am still not convinced that the lagging issues I’ve noticed on Android is a regression, and we need alot more effort and concurrent user simulations to really know for sure.

We also must have deterministic builds and multi-signed binaries before we can make a public release, to at least ensure that the flaws that may reside in Status are contained within our codebase and not maliciously introduced on the build pipeline.

Let’s do our best to not repeat mistakes of the past, there is a very real consequence of losing $100’s of millions. There is no cure for this injustice, only prevention.

https://medium.com/swlh/the-story-of-the-dao-its-history-and-consequences-71e6a8a551ee
https://cointelegraph.com/news/parity-hack-white-hat-group-drains-85-mln-as-company-fills-holes
https://cointelegraph.com/news/ethereum-proposal-to-resurrect-disabled-360-mln-parity-contract-shut-down

2 Likes
15

Thanks Jarrad for the reminder that we need ludicrous levels of scrutiny and diligence to avoid severe potential consequences.

In addition to the above I wanted to give an update:

  • The chat team has actioned Basel recommendations and has started implementing double ratchet, X3DH key exchange, and moving the chat protocol implementation to Go. The team is also reviewing the Basel list and will be creating more issues
  • Created an issue to remove Mixpanel and prioritized this for the mobile team
  • Continuing to look at performance issues
  • All teams are discussing Basel suggestions and are continuing to create issues for priorities

Let’s continue this discussion and aim to prioritize and publicize our top issues for the launch milestone. This will be an evolving process but it will help to keep us aligned on the important issues.

1 Like