What's next for Status

Archive
21

@yenda cool. Let’s also do a 1:1 this week to discuss some of this. Do you agree that these are issues? And do you have anything else to add?

Edit: I might just set up a 1:1 with each team member to get their perspective.

To those I haven’t asked, are you open to that? @andrey @adam @pedro @volodymyr.kozieiev @vitaliy @gravityblast

1 Like
22

I am very much in line with Hester’s problem statement and Rachel’s list of needs

To bring a concrete example on the table, thinking about how the multi-account phases played out (specification-design-implementation), I guess that during specification & design phases (april-may) we mostly focused on:
- how we will bring to the user several accounts in his UX (with an explorer, with an account view),
- how the user will be able to add accounts (which type of accounts etc.)
- had outlined a react-go separation of work

And only when we started to get into implementation (june-july, when v1 pressure got burning), bumped into some consequences that needed mitigation taking into account principles (privacy, inclusiveness for migration e.g), security, effort evaluation & product strategy. Here’s a tentative list by chronologic order:

  • ENS registration: do we do it with whisper or wallet address ?
  • Sending funds in chat: same question
  • TTT: impact of whisper/wallet decoupling (well it kills it:) , for now)
  • envisioned and then discarded for v1, notion of “inbox keys” to manage several whisper keypairs per user
  • Migration from beta to v1 for chat continuity (old whisper id-new whisper id)
  • Choosing account in tx transaction confirmation screen*
  • Choosing account in dapps browser*
  • Need proof of ownership for the “/Send” command in chat
  • Remove of Realm → multiaccounts management to be moved to go

Interestingly most of those aspects (all except those with a *) are solely linked with the decoupling of whisper and wallet keys, which is known for a long time.

One obvious thing we could have done better is to identify these aspects at specification phase (or even before!), which would have helped to plan the effort, and reduce confusion while in implementation phase.

A technical lead/architect could probably have helped with that, as well as better cross-team communications would have too.

5 Likes
23

On a different note, I think we need to find

  1. ways to prevent bad things(e.g. scams, conspiring a terror, and black market trading) from happening in Status chats. Some bad people could abuse the anonymous and censorship-resistant features of Status. The opposite side of the super private protocol could be dangerous for us(received this question a lot personally).

  2. ways to secure the sustainability of the project in the long term. All the entities need proper revenue sources to develop and maintain what they have built.

5 Likes
24

Bad people are everywhere. How it will be possible to control chats, if the principles Status are initially defined as super private. There may be a chat lock on a SNT contract?

1 Like
25

DAPPS as DAICOs genius idea!

26

i think status and contributors should provide some usecases or campaigns about specific or economic benefits from protecting their(eg. non-tech people, ordinary people who do not know the importance of privacy) privacy.

1 Like