Prioritizing v1 leftovers
Context
As an outcome of the v1 scope call on 11/7/19, the following table of items was bumped to post-code freeze.
Let’s take a look at the value & status of each item to determine where it should fall in the coming months.
Proposal: P0 items should be addressed before the v1 release candidate is cut. All other items can be prioritised again in Istanbul.
| Section | Feature | Priority post code freeze |
|---|---|---|
| I | Nickname feature | |
| I | ENS resolution fixes | |
| I | Remove ENS name | |
| II | Account settings (multi-account) | |
| II | Set custom default wallet | |
| II | Select account during Tx | |
| II | Add account via custom derivation | |
| II | Add account via seed phrase | |
| II | Export an account | |
| II | Proof of account ownership in whisper messsage (/send command) | |
| III | 6 digit pin code | |
| III | Biometric login | |
| III | Encrypt keys with key and maintain in secure storage | |
| IV | Tribute to Talk | |
| V | Realm —> Go: extensions | |
| V | Realm → Go: bootnode | |
| V | Realm → Go: network | |
| V | Realm → Go: mailserver-requests-gap | |
| V | Remove from realm: contact-recovery | |
| V | Realm → Go: mailserver-topic | |
| V | Realm → Go: mailserver | |
| V | Realm → Go: transport | |
| V | Realm → Go: chat-requests-range |
When sharing thoughts on priority, effort, etc., it would be great if you could format your comment to match the post:
I.II. Nickname feature
Status: lorem ipsum
Effort: lorem ipsum
Thoughts: Priority level. lorem ipsun (name)
Pinging @yenda @andrey and @cammellos as you guys are probably best equipped to offer input on effort required for each of these items.
Evaluation
I. ENS + identity
I.I. ENS resolution fixes
Story: As a beta user with an ENS name, I want to use the name I own as my display in Status chat.
Status: Design ready, partially implemented. ENS resolution was done by Julien, but in order to allow previously registered names in v1, we have to do some work to verify that the user owns the address.
We also need name verification in status-go.
Additionally, some UI cleanup is required.
Effort:
Thoughts:
P0. Usernames are important for user friendliness and SNT utility, as well as to help users build a profile and identity within Status (for features like TtT). We’ve come this far; I think this should be prioritised. (Rachel)
I.II. Nickname feature
Story: As a user, I want to set custom nicknames for others in Status chat (similar to a phone address book), so that I can remember them more easily.
Status: Design ready. Not started.
Effort:
Thoughts:
P0. In v1 we are removing the custom display name. For a user to control their own name they must use ENS. I like this feature as a complement, to prevent the app from feeling totally anonymous. (Rachel)
This feature also provides a mitigation against impersonation when users create highly similar ENS names. (Hester)
I.III. Remove ENS name
Story: As an ENS user, I want the option to remove my chat ID from my ENS address.
Status: Design ready. Not started.
Effort:
Thoughts:
P2. The reason this is valuable is so that users can re-register their ENS name to a new chat ID, or simply separate the two. If you’re concerned about the exposure of your chat ID via ENS, you have a work-around. Create a new, distinct chat ID. You continue to sacrifice privacy by having an ENS-wallet link. (Rachel)
II. Multi-account support
II.I. Account settings
Story: As a user with multiple accounts, I would like to see details about each account type and customize its display name + color for differentiation in my wallet.
Status: Design ready. Not started.
Effort:
Thoughts:
P0. This is the only access point for a user to view their full wallet address and should be simple to implement. (Rachel)
II.II. Set custom default wallet
Story: As a user with multiple accounts, I’d like to control which is my default—as that one will be used when I interact with a DApp or send a chat transaction.
Status: No designs. Not started.
Effort:
Thoughts:
P0. If we don’t offer this, users have no choice but to transact with DApps using their default account (the one generated by Status or imported during onboarding). That feels counterintuitive to multi-account. (Rachel)
II.III. Proof of account ownership for /send command
Story: As a user, I want to be able to send and receive crypto in Status chat.
Status: Design needs TBD. Not started.
Effort: ???
Thoughts:
P1. There is some desire to rethink this interaction by UX (Maciej) but moreover, I don’t see it as urgent for the release; a nice-to-have, given wallet is available. (Rachel)
I do recall that the GUI version of transaction in 1:1 chat was used by 6 out of 6 users in UX testing over navigating to Wallet. (Hester)
II.IV. Export an account
Story: As a user, I want to export my Status account so that I can use it in another wallet.
Status: Design ready. Not started.
Effort: ???
Thoughts:
P1. This is easy enough to implement and a really nice basic feature, but not urgent. (Rachel)
II.V. Select account during Tx
Story: As a user with multiple accounts, I would like the option to select the account I want to pay with during each Tx.
Status: No designs. Not started.
Effort: Caution for complexity/feasibility.
Thoughts:
P2 or beyond. This is a more sophisticated way of allowing users to transact with their preferred wallet in any situation, but iirc there are major complexities involved. (Rachel)
II.VI. Add account via private key
Story: As a user I want to manage any ethereum keypair from my wallet. I thus want to be able to import a private key within Status and add it as an account.
Status: Design ready. Not started.
Effort:
Thoughts:
P1. This is a quite generic feature that would provide users lots of control and ownership on which account they can control within Status. (GL)
Some conflicting info on this: (Hester)
- In V1 scope call decisions it says :“Importing private keys ← likely should be prioritized for release scope”.
- In a multi account call: Out of V1 until we have a way to copy paste on mobile safely
(GL) for the scope call notes-> P0 or P1 yes. It’s a feature we removed at the last minute during the scope call to really cut things as much as possible. with a logic last out, first in, we should get it back, but still it really depends what else is on the list.
for the safety-> if we stick to importing a encrypted file (JSON/Keystore) I guess we’re fine, the copy paste data will only include encrypting data. What we should not do is allow to copy the private key directly not encrypted.
II.VII. Add account via seedphrase + derivation path
Story: As an advanced user, I want to be able to add an account in my wallet which uses any seed phrase and any derivation path. I want to be able to use my wallet seed or another one. I also want to be able to get some help to discover which derivation path on my BIP32 hold some assets.
Status: Design ready. Not started.
Effort:
Thoughts:
P2. This feature is for advanced users who used before Status some wallets that don’t use BIP44 standard ethereum paths. (GL)
III. Onboarding + login
III.I. Encrypt keys with key and maintain in secure storage
Story: As a user I want to know my keys are secure while at the same time sign transactions and login with little effort.
Status: Work started for Android. On hold due to lack of resources.
Effort:
Thoughts:
P0. Support for 6-digit passcode was two-fold. UX improvement and Security improvement. Currently keys are encrypted with password; Easy to brute force when weak passwords are used. They are. 6-digit passcode would force a change to encrypt keys with a key. Passcode or password would only grant access to secure storage. See also background here. (Hester)
P1. Need to do further research, but it sounds like this is the layer beneath 6 digit passcode that requires auditing. Because this item is not prioritized for the initial code freeze, timing doesn’t make sense to target it for the release candidate, so I’d prioritize it as P1. (Rachel)
III.II. 6 digit passcode
Story: As a user I want to know my keys are secure while at the same time sign transactions and login with little effort.
Status: Work started for Android; iOS specialist required. Resource-blocked.
Effort:
Thoughts:
P1. Improves UX (lower effort) for repeated transactions and login. (Hester)
III.III. Biometric login
Story: As a user I want to know my keys are secure while at the same time sign transactions and login with little effort.
Status:
Effort:
Thoughts:
P1. Improves UX (lower effort) for repeated transactions. (Hester)
P1. This was requested by users quite often when we had Instabug, iirc. (Rachel)
IV. Tribute to Talk
Story: As an in-demand user, I’d like to set a minimum required tribute to speak to me in Status.
Status: We stopped development of TtT in April. The MVP allowed a user to set a tribute in SNT, and for another user to pay that amount by sending a chat transaction directly to the other user’s wallet. Because the wallet key will no longer be exposed in chat, the underpinnings of the feature need to be re-engineered.
Effort:
Thoughts:
P2/do not prioritise. TtT won’t be useful until we have a critical mass of users interacting in chat. The main goal of developing this feature in Q1 2019 was to deliver on our SNT utility promises. We’ve done that with ENS, stickers, Teller, and very nearly with https://dap.ps, so I would propose that we de-prioritise this in favor of making our baseline chat features more performant and enjoyable to use.
V. Realm removal
Story: As a user, I’d like to have a more performant app. As a developer, I’d like to carry forward less technical weight + circumvent future migration needs given a more performant option is within reach.
Status: Not started. (?) These are the Realm removal items that were marked as non-essential. (Rachel)
Effort:
Thoughts:
Designs are ready for both.
