Status V1 scope call today noon CEST

UPDATE: Please see for agenda, context and proposals

tldr: v1 scope call on Thursday CEST noon, prepare beforehand.


We are trying to release a usable V1 as soon as possible. It is currently past our initial deadline (Q2), and we are suffering from severe scope creep and uncertainty.

Here’s a basic illustration of the fundamentals of Shipping Stuff.

Also see:


Have a V1 cut scope call on Thursday noon CEST. The goal is to:

  1. Cut scope
  2. Reduce uncertainty


Given that:

  • both Core and Core UI have recently seen fewer active participants
  • Igor left as technical Core lead
  • a lot of the responsibilities between Core and Core UI have recently become muddled due to resource constraints
  • total number of active engineers in Core and Core UI are <~10 people

Core and Core UI are encouraged to participant. Additionally, cross-FN and anyone else with interest is welcome to participants. I’ve made an invite where I invited a few people with vocal opinions on these things. If you weren’t invited but want to participate feel free to change event, or ping me or anyone else in the call.

It is also recommended that we merge Core and Core UI standups until V1 is shipped in order to reduce communication overhead.

Expected preparation

It is expected that people prepare specific proposals, with trade-offs, of ways we can reduce scope or uncertainty for V1 launch.

One idea of what this might look like is using something like ARD format (, but this is up to you.

Please post specific proposals in Status V1 Cut scope call - CodiMD and/or in this topic. In order to make these proposal high quality and give people the time to think about things, please post draft proposals by tomorrow CEST lunch time. Post each proposal under a separate bullet point so we can reason about them in isolation.

Aggressiveness in cutting scope is encouraged. Note that this doesn’t mean being naive or overly optimistic. There’s a premium on proposals that include minimal changes.

In terms of people I would expect to come with proposals, this is a (non-exhaustive) list: @adam @andrey @cammellos @gravityblast @guylouis @hester @naghdy @pedro @rachel @yenda. If you aren’t able to make it, please add async and ping me. If you aren’t clear on what is expected of you, please ping me. If you are not in this list but have strong opinions, please add your proposals.

Feel free to ping me if you aren’t clear on what this means.


  1. Intro (2m)
    • clarify expectations and goals, any changes needed
  2. Reading time (25-30m)
    • feel free to add notes to each point
    • better skim through whole than getting stuck in beginning
  3. Go through each proposal (2-10m max timebox, total ~1h)
    • document specific decisions for each 6 (or more) proposals
    • if no consensus, document decision point clearly and next action
      • include if someone’s work is blocked or not
      • Monday follow up
  4. Break and finish up (5m)
    • assuming people think needed and productive to continue…
      (5. Buffer / assuming time left, revisit controversial ones (~ tbd timebox))
      (6. Finishing up (5m))

Expected Outcomes & V1 Decisions


  • 2.1. Do not include the following features/flows? (Rachel / Pedro)
  • 2.2. Remove Realm.js? ( Eric / Rachel / Core UI)
  • 2.3. Start all accounts fresh from v1? (Rachel)
  • 2.4. Only support minimum requirements for Keycard in Status? (GL)
  • 2.5. Change encoding of the protocol to protobuf? (Eric)
  • 2.6. Enable PFS for 1-to-1 chats and break backwards chat compatibility? (Eric/Jakub?)

Scope & Features

[OT] Unclear if we’ll have time for anything more than above decisions, plus a lot of these are already captured in above. If someone has a clear idea of how to make decisions on these in the time we have, feel free to edit this.

  • Feature A?
  • Feature B?
  • Feature C?

To give some direction to the proposals needed based on topics of conversations that have come up when talking about: use of multiaccount on existing features, compatibility between Beta and V1, migration to V1.

Proposals can include variations and must include some sort of effort estimate.


  • Go implementation of account table
  • Interface spec of Go implementation for react
  • Specify migration path to transition users to multiple keys
  • React implementation of migration UI

Core UI

  • Specify impact and required updates to TTT
  • Specify use of multiple keys in DApp transactions
  • Specify use of multiple keys in Chat transactions
  • Specify use of multiple keys in native contract transactions (e.g. ENS migration)


  • Specify and implement handling of multiple accounts in 1:1 chat transactions (proof of ownership address)
  • Proposal to remove realm and implement storage solution of anything required next to account table
  • Specification of tasks and effort to move current protocol to Status Go


  • Specify options for backwards compatibility of PFS for 1:1 chats and group chats when users have a new Whisper ID and multiple accounts
  • Specification of tasks and effort to integrate MVDS in Status Go

Or, considering:

  • all the time already wasted talking about migrations and
  • the fact that backward compatibility is not a principle Status Principles, that
  • we have spent a year and a half practicing it for the future nevertheless, and that
  • there hasn’t been any frank opposition to ,

based on the rough consensus that now is the last time we can break things,

we could acknowledge now that v1 is breaking compatibility both at protocol and application level and get to work, which opens an opportunity for:

  • getting rid of realm at once. If we don’t do it when we can drop db, we will have to do migration, which is more work, more money, and also keeping realm longer because it can’t be removed right away if we want migrations. Keeping realm is also keeping 1000 lines of js dependencies, compromising on III security. It is also potentially facing more issues with it in the future as we have in the past when upgrading (for security or compatibility with react-native updates), compromising on resourcefulness. Details here: Removing realm - CodiMD

  • changing the encoding of the protocol on the wire and removing all legacy support, breaking compatibility, but since every one moving to v1 will have a new account, this won’t be noticeable. For third parties it will make it easier to implement our protocol, more open as in VI Openness.

And therefore focus the discussion on these two points.

There is two deadline:

  • code freeze for audit (Release Candidate)
  • actual release (V1)

The strategy would be to evaluate all the parts that don’t need to be audited with @petty to produce RC as soon as possible. The rest can then be done while RC is being audited which buys us some time.

It will be much easier to plan and make estimates once we know exactly what goes into RC.

There is no cutting scope when it comes to porting all of realm tables to status-go, but we can go rough and refine after v1. It’s either removed completely or a weight to carry in the future.

Right now the biggest issue is the uncertainty that is casted on migrations. What is going on? It seems like most people are still expected some kind of veto against breaking changes.


I think this needs more clarification. It’s too easy to have a meeting and then just end it with “we’ll talk more about this next time”. I think we should have clear points to discuss and make some kind of decision on them.

Something like:

Expected Outcomes & V1 Decissions

  • Decissions
    • Drop old accounts to make way for multi-accounts?
    • Drop database migrations and Realm.js?
    • Enable PFS for 1-to-1 chats and break backwards chat compatibility?
    • Create account migration process or just give users manual instructions?
  • Scope & Features
    • Feature A?
    • Feature B?
    • Feature C?

This way we can at least end up with something concrete at the end of the meeting.


I’m a lot clearer on @yenda’s case for breaking backward compatibility in v1 after our core UI sync just now.

@jakubgs recapped it well over in that topic:

Erics proposal is very simple:

  • Drop the DB, which allows us to drop Realm.js and a shitload of old DB migrations
  • Avoid having to design, develop, and test a migration process for accounts
  • Give people new accounts, which gives us a clean break for introducing multi-account
  • Allows us to change the protocol to use JSON/Protobuf for easier usage by 3rd parties

This is the only time we can do this. If we wont, we will make future changes even harder to make backwards compatible and make development slower.

The major reason that we want to start fresh with v1—e.g. do not support legacy accounts–is because it offers us the opportunity to drop the weight of Realm.js, and we will not have the chance to do this as painlessly in the future. It’s not about the relatively minor effort required to build the extra UI for ‘upgrading’ to multiaccount, although scrapping that helps too.

My understanding is that Realm.js carries thousands of lines of dependencies, which are no longer required now that the chat protocol lives in status-go. We would carry this weight forward only to support legacy accounts from beta.

We have wide consensus among both CCs and the community that beta accounts are not important to maintain, so it sounds like a no brainer to go with Eric’s proposal.

@oskarth also suggests that we be more aggressive in cutting nice-to-have features and UX, focusing only the bare minimum required to enable keycard. I’ll put some thoughts toward which features & flows are non-essential in that worldview (just as GL has put together what is essential for keycard). I believe this should be done in addition to dropping Realm & legacy account support.

Lastly, I agree with Jakub that we should be very precise in the outcome of the call. We need an outcome on Thursday that the team can move forward with.


I agree that removing Realm would be better.

I don’t agree it’s needed to enable Keycard or needed for V1, and I think we still don’t know how many things we need to change in status-go.

I also think we should design and develop this carefully from a security prospective, we are moving a lot of sensitive data just before releasing V1.
I agree we should do it but I don’t want to do it quickly only because we want to drop a depencency.


I agree with @gravityblast, while is true that removing realm has definitely some benefits and that this is the last chance if we want to do that and keep backward compatibility, we are simply talking about swapping one db for another, of which performance we haven’t really measured, so I feel we should at least investigate that and better quantify the benefits. To me while is a nice to have, is not necessarily a blocker for v1. Having said that, judging from the amount of work we still have to do in other areas, and how we can parallelize things, it might be worth doing as might not be what delays v1, but that’s just a feel.

In terms of security I believe we sqlite + sqlcipher is more battle tested than realm, although it’s good to be cautious


@gravityblast @cammellos it’s super helpful to hear counterpoints and cautions to removing Realm. @yenda has started on a doc about it, which @andrey and I are helping to bring some critical thought to today. Would be excellent to get your feedback.

If it’s a significant risk and workload to remove before v1, it will be even more so after, right?

1 Like

Removing it after unfortunately is not possible without a break in compatibility of installed versions.

Removing it bit by bit would be a better strategy, essentially migrating each piece of data bit by bit (of course no migrations is better, so a clean break is easier).
But eventually to get all the benefits you would have to actually remove Realm, and that means that users that go from a version with Realm say v1, to a version without , say v1.5, will lose their data (they could probably keep their data by installing v1.4 first, and then v1.5, so there’s an upgrade path, but it’s not the smoothest).


So I worked on a marketing campain for our cause of dropping realm wdyt?



Thanks for all the discussion and memes so far. I thought I’d capture some snippets in #status-core, because I think it re-iterates what to me is the absolute key point when it comes to shipping v1, and one we have failed miserable at so far. It bears repeating as many times as it takes to drive the point home.

The absolutely quickest way to release is to take develop and harden it with bug fixes (Oskar)
Our challenge is figuring out the minimal set of necessary changes that we absolutely need to get in v1 (Oskar)
I agree with that, v1 is supposed to be stable, and we are chumming out risky features like an army of code monkeys, but how did we reach this point (genuinely asking)? seems like we are doing U-turns on top of U-turns (Andrea)

1 Like

Write to both, have flag for reading only from Go instead of Realm, and then we can deprecate Realm once we have confidence it is working.

Not today.

1 Like

One point that needs to be agreed for code freeze scope:

  • /send in chat
    We’ve identified that to allow this feature we need the whisper exchange between A and B (A sends funds to B) to include a proof of ownership of A account. This need is coming from the fact that whisper and account keypairs are now different, and is valid even if we don’t have several account to chose for A when sending funds to B. The issue is about B seeing a message coming in whisper that funds are coming from A. If we don’t do proof of ownership, there is a risk of impersonification from A.
    Eric proposal discussed here on 4/7 is for code freeze: deactivate /send command in chat, leave send from profile activated. And for post code freeze: add proof of ownership and reactivate /send funds

Core-UI proposal

There are two deadlines:

  • code freeze for audit (Release Candidate)
  • actual release (V1)

For this reason we propose to evaluate with Corey which part of the code have to be frozen for RC, and which can be worked on until V1, so that we can optimize planning. RC should include:

  • anything to do with the way we manage keys
  • underlying chat protocol
  • the way the final binaries gets created

We consider that we are:

  • breaking protocol compatibility between beta and v1
  • dropping data between beta and v1
  • moving communication protocol to status-go

The main changes proposed by Core UI team are:

  • removing realm in status-react and using status-go as backend
  • changing protocol encoding on the wire

The above implies that we are cutting scope by not:

  • working out UX for migration/support of legacy accounts, then implementing it
  • working out application issues between legacy and new accounts
  • migrating data from status-react to status-go
  • testing compatibility between beta and v1

We will break develop branch
We will iterate on release candidates and consider v1 ready once two RCs tagged from develop are tested compatible and feature full.

FAQ, unknowns and risks

Why remove realm?

(some arguments are repeated a few times in this document)

  • 1000 lines of dependencies removed from the yarn.lock file, a bazillion line of unauditable code
  • smaller memory footprint of the app (one less db server to run)
  • performance improvements:
    • less work on the js thread
    • less back and forth between status-react and status-go at startup
  • opens the door to further performance improvements in the future:
    • by getting results from status-go in transit, which is the fastest encoding format for clojurescript
    • potentially even clojurescript datastructures directly without using the bridge if we mimic the way realm was behaving
  • get rid of ubuntu-server for desktop which was blocked by realm so far
  • realm was a bottleneck at some point and writes were moved to an async queue that was managed by cljs, now
  • development of alternative UIs/client is much easier

Unknown regarding performances of status-go vs realm

Besides bemchmarking of performances between the 2 databases (sqlite on go side, realm on react side) which will be addressed as a first step, the performance is influenced by different factors:

  • realm was synchronous and status-go communications are aynschronous:
    • previously we had to move realm writes to an asynchronous queue to avoid blocking the js thread when writing a lot of data (but still on the unique UI thread). This is not necessary anymore in status-go because the writes are asynchronous. Error handling won’t be worst than with realm where we can’t do much more than logging if writes fail (for a while it just crashed the writing loop and stopped writing anything to the db until app was restarted). We will have to make sure write errors on status-go side don’t have a similar effect, though error handling is go is suppose to be pretty solid.
    • some queries are passed to the code and made in-line. Because status-go is asynchronous this is not possible and the follow up code will have to be done in a callback. However this is mitigated by the fact that these kind of queries are mostly used in messaging code which is moved to status-go anyway. Further work in the PR removing realm for status-react should uncover the potentially remaining use cases, but there performance impact is expected to be minimal.
  • the login phase will be simplified:
    • currently it requires starting a node as well as a bunch of back and forth between go, realm and js thread. This is due to the fact that js thread needs to start the node, decrypt the realm db to get the list of accounts, try do decrypt the account db, login in status-go, restart the node with the right account config.
    • once accounts data is moved to status-go, getting the accounts list and login only consists of a native binding call to status-go to login. This reduce the load on js thread as well as the back and forth required to login.
  • moving the messaging is already part of v1 scope but it is good to remind that messaging is one of the few remaining bottlenecks of the app even on high end devices
  • the data could be exchanged with status-go in transit format to make the conversion an order of magnitude faster and save cycles on the UI thread.

Security issues with moving data from realm to status-go

  • the security risk has already been taken as some part of the app like installations was already moved to status-go
  • status-go already handles the keys and there is no more sensible data it could possibly work with
  • sqlite + sqlcipher is more battle tested than realm and is a SQL database
  • realm is 1000 lines of dependencies (in yarn.lock file, not LoC which is much higher!), removing that is a security benefit not issue
  • realm is blocking removal of the ubuntu-server in status-desktop which is a security risk we have been looking forward to remove for a while

We could remove realm later, or bit by bit

Removing it after unfortunately is not possible without a break in compatibility of installed versions.

Removing it bit by bit would be a better strategy, essentially migrating each piece of data bit by bit (of course no migrations is better, so a clean break is easier).
But eventually to get all the benefits you would have to actually remove Realm, and that means that users that go from a version with Realm say v1, to a version without , say v1.5, will lose their data (they could probably keep their data by installing v1.4 first, and then v1.5, so there’s an upgrade path, but it’s not the smoothest).

So it only makes sense to remove it now before V1, considering there is a consensus on the fact that the time for a breaking change is now or never.

We could move as much as possible before v1 and then consider it acceptable for users to lose things like extensions and browser data:

That is not worth the trouble because moving extensions and browser data is by far the simplest thing in this proposal, it is at most a week of work for the two of them together.

How do we decide what information should be persisted in status-go? For instance what about UI related data like opened window?

If opened window is an information that has to be persisted, then the persistence is done in status-go. status-go will replace realm, no exception.
An absolute rule is that no migration should cross the status-go/status-react api boundaries to avoid any issue with migrations in the future. This means that no migration of persisted data should involve status-react.

status-go is now responsible for managing persisted data, and it is exposed to status-react via services APIs.

As a consequence this means that it is also harder for status-react to make changes to the persistence layer, since go has now to be involved. However that also means that such changes will be discussed more carefully in the future in the form of API updates.

We still don’t know how many things we need to change in status-go

That is the purpose of this document. Besides messaging which was planned for v1 anyway, there isn’t much left to do, and if we follow this plan, we should know much more by the end of next week.

The plan

STEP 1: Addressing lack of benchmark for raw performance of using status-go vs realm


  • Create a browser table in status-go and an API that offers the same capabilities as its realm counterpart
  • Schema of browser table in realm js is as follow:
{:name       :browser
         :primaryKey :browser-id
         :properties {:browser-id    :string
                      :name          :string
                      :timestamp     :int
                      :dapp?         {:type    :bool
                                      :default false}
                      :history-index {:type     :int
                                      :optional true}
                      :history       {:type     "string[]"
                                      :optional true}}}

Array of string can be replaced by string if there is no equivalent in sqlite, but status-go has deliver it as a json array of string to status-react

  • The API for the benchmark should include get-all-browsers which will return an array of browser, and add-browser which will add the browser passed as argument to the table
  • Optionaly status-go can take and return transit data

STEP 2: Removing realm and identifying potential painpoints

  • Estimation: 1 day
  • Proposed participants: @yenda



  • no persistence until status-go persistence is added

STEP 3: POC of status-go accounts database and simplified login


  • create a database on status-go side to manage accounts
  • add native bindings to get accounts and login/logout from an account
  • login should: start a node with the user config

Next steps


  • Step 1 is demonstrating no big raw performance differences between status-go and realm,The plan
  • Step 2 didn’t identify blockers for moving from an asynchronous to a synchronous db
  • Step 3 made reasonnable progresses (possibly completed and went beyond expectations)

Then we’ll fully focus on removing realm and breaking migrations and protocol backward compatibility for V1.
See ## References for the list of endpoints that will have to be implemented.

There is a few places where we already know we can make shortcuts for instance:

  • when importing a key, status-go will already have access to all the default and user added tokens from it’s multiaccounts database, so it can directly check the balance of all the path and return the ones with a balance to status-react, as opposed to status-react having to trigger that
  • multiaccounts is not yet persisted in status-react, so if we know we are moving away from realm, we won’t double the work and hence reduce the scope


Current API for realm queries/writes, that we will have to implement in status-go.
Will be refined after step 2
[NEW] means it doesn’t exist yet in status-react either

Multiaccounts [NEW partly step 2][required]

Estimated 2 weeks

  • previously status-react was doing login using the address of the account

  • with multiaccount status-go should use a unique account identifier and pass that identifier in the account list to status-react

  • this would be an unsolved problem in status-react in the future when we start having multiple chat accounts

  • Read

    • get-all-multiaccounts
  • Write

    • save-multiaccount
    • delete-multiaccount
    • save-account-settings
  • a new database to list all accounts is needed

  • will contain the basic information required to show a list of accounts and each account settings.

  • will be encrypted by the app

  • individual multiaccount settings could later on be encrypted per multiaccount, but currently status-react doesn’t do it either. If that doesn’t require much more work on status-go side, I would strongly suggest to do it already.

New login [NEW partly step 2][required]

Estimated part of ### Multiaccounts

With multiaccounts the login would work slightly differently. status-react will provide the multiaccount id and status-go will have to do the following things:

  • signal an error if the password is wrong or something went wrong or
  • start the node based on the multiaccount configuration and
  • load the chat accounts and start listening for new messages and
  • load the wallet accounts and start watching for new transactions

Browsers [required partly step 1]

Estimated 2 days

  • Read
    • get-all-browsers
  • Write
    • save-browser
    • remove-browser

Dapp permissions [required]

Estimated 2 days

  • Read
    • get-all-dapp-permissions
  • Write
    • save-dapp-permissions
    • remove-dapp-permissions

Part of moving messages to status-go:


Putting this one first because it is a bit special, technically not needed for messages and chats though required for features like block user to work smoothly

  • Read
    • get-all-contacts
  • Write
    • save-contact
    • save-contacts
    • delete-contact
    • block-user

Contact recovery


  • already in status-go
  • remove from status-react completely?


  • this should be mostly removed from status-react

  • gaps would be sent along with chats

  • mailservers should be provided along with account as a setting

  • mailserver-topics should be completely handled on go side

  • Read

    • get-all-chat-requests-ranges handled by status-go
    • get-all-gaps becomes part of get-all-chats
    • get-all-mailservers becomes part of account settings
    • get-all-mailserver-topics handled by status-go
  • Write

    • save-mailserver
    • delete-mailserver
    • save-mailserver-topic
    • delete-mailserver-topic
    • save-chat-requests-range
    • save-mailserver-requests-gap
    • delete-mailserver-requests-gaps


  • should be part of status-console-client already

  • only mentionning methods that are needed and might not already be part of console-client yet

  • signal for changing outgoing message status

  • Write

    • mark-message-seen


  • should be part of status-console-client integration already
  • only mentionning methods that are needed and might not already be part of console-client yet


@cammellos currently working on that

  • Read
    • get-all-chats
  • Write
    • save-chat
    • clear-chat-history
    • deactivate-chat
    • add-chat-contacts
    • remove-chat-contacts
1 Like

Regarding Realm, I think the questions we need to answer in tomorrow’s meeting are:

  1. Will getting rid of Realm before V1 get us to the launch date sooner than if we launch with Realm (regardless of how much better the codebase would be without Realm)?
  2. If not, are we willing to delay V1 in order to not bear the opportunity cost of having left Realm in the app?

We asked the community if they were willing to bear with the consequences of throwing away Realm (i.e. losing chats and contacts), but we failed to mention how that would affect the release schedule, and that is part of the equation too.


I updated the document with agenda, context, all proposals so far and expected outcomes so far. Please provide all further changes in this document: Status V1 Cut scope call - CodiMD Additional proposals and async notes beforehand are encouraged.

See you in a few hours!

4. OUTCOME OF CALL: Decision/action points

Summary of decisions and outcomes:

2.1 Do not include the following feature/flows

The whole list is greenlighted (see table in 2.1)
To clarify, Proof of account ownership in whisper messsage /send command means that /send command would be disabled for audit release, then worked on after.
    Contingent upon ToB signing off on that being ok
Additional items were cut from v1 code freeze later in the call:
    Multi-account Add account flows except for bit 44 & watch-only

2.2 Remove Realm.js?

Rachel scheduling meeting to discuss:
    What is critical to move to status-go before v1 (anything security-related)
    How to remove realm
        bit by bit
        all at once in a single branch, then merge
    Associated resources

2.3 Start all accounts fresh from v1?

Green light to break old code
Rachel to revise onboarding & recovery user stories with dev & design
Rachel to help plan communication of changes (should happen in app, not only via comms channels)
Rachel to look into contingency plans for users who lose seed phrase and are forced to recover by v1

2.4 Change encoding of protocol to protobuf?

Deferred. Not for v1.

2.5 Enable PFS for 1-to-1 chats

Green light.
Status team should enable PFS and test internally.

2.6 Stop listening for single discovery topic

Green light.
Messaging won’t be compatible with previous versions
    OK as we are breaking compatiblity anyway
No strong opinions against it
Number of topics goes to later
    Tradeoff between darkness and bandwidth

2.7 Keycard in Status

Multi-account work and keycard work have been conflated.
Non-essential multi-account work is being chopped, per previous section:
    Export a private key
    Add account by
        Importing private keys <-- likely should be prioritized for release scope
        Typing in a seed and path
    Account explorer
    Add account
        Watch only
        BIP 44

See Status V1 Cut scope call - CodiMD for full meeting notes

Regarding 2.2 Remove Realm.js

The proposal for v1 by @cammellos is as follows:

Essential for security:

  • chat
  • contact
  • message
  • membership-update
  • installation (moved already)
  • contact-device-info
  • account

Non essential

  • chat-requests-range
  • transport
  • mailserver
  • mailserver-topic
  • contact-recovery (in status-go already, not removed from status-react)
  • mailserver-requests-gap
  • network
  • bootnode
  • extensions

Don’t know:

  • browser ← already done regardless
  • dapp-permissions

@petty so, I haven’t heard any dissent from the above proposal for Realm v1 essentials. Do you have any feedback? Should we consider these essentials locked in as our v1 requirements and run by ToB?

Essential for security:

  • chat
  • contact
  • message
  • membership-update
  • installation (moved already)
  • contact-device-info
  • accoun
1 Like

yes, this looks good to me.

1 Like