Prioritizing v1 leftovers


#1

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:


#2

From a security perspective, if not included, I can guarantee this will raise flags during the V1 audit and will be a line item in the report. Once implemented, it will need looked at from an outside source. It is currently unclear whether or not the current retainer will suffice but I lean toward that being enough and not required a full audit.

I consider similar items that stem from this to be all packaged into this and follow the same logic.


#3

Just taking a stab at the effort, using t-shirt sizing, I have only a partial understanding of each feature as I haven’t seen designs and likely missing some context. P0 priorities look good to me.

I. ENS + identity

I.I. ENS resolution fixes

Effort: Medium

I.II. Nickname feature

Effort: Medium/Large

I.III. Remove ENS name

Effort: Small

II. Multi-account support

II.I. Account settings

Effort: Medium

II.II. Set custom default wallet

Effort: Small

II.III. Proof of account ownership for /send command

Effort: Medium/Large due to unknowns

II.IV. Export an account

Effort: Small

II.V. Select account during Tx

Effort: Large

II.VI. Add account via private key

Effort: Medium

III. Onboarding + login

III.I. Encrypt keys with key and maintain in secure storage

Effort: Medium/Large

III.II. 6 digit passcode

Effort: Medium/Large
Thoughts This is likely to have impact on rest of the codebase as we use user password to encrypt the database

V. Realm removal

Status Work for critical components already started (effort would be Large)
Effort: Medium for the remaining parts


#4

Hey, thanks for bringing this to attention Rachel. Looks ok, I’m a bit surprised seeing nicknames that high though. they’re cute and all but only really useful once we run into a problem of having say multiple Rachel’s in a single chat and people confusing them. I’d love to have that problem but we’re not there yet in terms of adoption. While i don’t have the data to back it up, I doubt users will be motivated enough to setup nicknames unless it becomes a pain point.
So if you make the same case for TtT not getting the attention because it’s too early, I feel the same for nicknames and of those two at least TtT is unique to us, already started and interesting.
Speaking of interesting, can’t we estimate efforts for things like image sharing in chat, or getting mark as read working? You know, giving chat some love :slight_smile: Designs are ready for both.


#5

Great point about chat items @maciej - I should have clarified: this isn’t an exhaustive list of our work post v1. I just want to make sure any items we cut from the initial scope are considered now, so we capture anything required for v1 release.

In Istanbul (or once the v1 release scope is settled) we should determine where addtl items fall in our Q4/Q1 roadmap.

To that end, I also want to hear other opinions and don’t intend to assert my opinions as the final say.

On nicknames - you could be right. They might not be P0. But I see nicknames as being more useful to more people than TtT, and presumably more straightforward to build. TtT is started but has too much complexity to resolve for it to be included in v1. The underpinnings must be reworked.

I’m not worried about navigating multiple rachel.domain.eth in a chat—nicknames pre-empt the fact that most users who onboard won’t have SNT, and thus presumably won’t be quick to register usernames. I’d like to wrong about that, but it’s a hurdle that I assume will lead to seeing mostly random names in chat, unless we have a free alternative like nicknames.

Thinking ahead to other chat features like sending images in chat & fixing mark all as read…those are more than interesting! Interesting does not warrant prioritizing in my book, not at this moment in time. But tablestakes features that greatly enhance utility certainly do. :slightly_smiling_face:


#6

Really looking forward to Istanbul and going over these addtl items!

On nicknames: it’s also a security measure against impersonation. (My motivation for having it as P0)


#7

re: nicknames: agreed.


#8

Here’s keycard backlog.

This is for V1 and beyond, and the current view of the keycard team of what’s next for us to work on. The list is subject to a finer grained prioritization of course.

I’ve separated features that are:

  • part of Status app itself (the majority are) - and which are thus to be tightly kept in sync with core/core ui developments
  • from others (e.g. javacard improvements, sdks, smart contracts developments)

#9

Is Recover to Keycard still included? And if so is that V1 code freeze or V1 release?

With Recover to Keycard I mean:

  • Access Key
  • Recover seephrase
  • Select Storage location > Keycard

Can’t wait to see Keycard Pay to take shape :heart_eyes:


#10

Yes, recovery to Keycard is part of v1 code freeze.
I completed the file, thanks !