Copy of Core Prios

tags: okr core

​# Status OKR Brainstorm - 18Q4/19Q1

Core's north star is fulfilling the promise of delivering the Status Whitepaper and putting Ethereum into hands and pockets.

Changelog

  • Moved developer work back from P2P to Core (RH)
  • Reordered sections (RH)
  • Reordered Core section (RH)
  • Marked items to drop from poll (RH)
  • Edited copy for community friendliness (RH)
  • Added some links, edited others (AT)
  • Removed "Better contributor engagement" - vague and better left for Optimised for Status (pref based on whatever DApp curation mechanism we implement). Should be an aim for 19Q2. Let's focus on building it all properly first (AT)

Objectives 18Q4/19Q1

Core Teams (Chat, DApps, Wallet)

Photos of IRL notes

To be prioritized via SNT voting:

Improve chat reliability
Status must live up to its core promise of being a decentralized messenger, that works.

  • Improve delivery rates
  • Perceived reliability
  • Bandwidth, network and battery usage should be non-issues

Strengthen app security
Ensure that Status is verifiably secure so that users can build from source, that users' data is completely protected despite reliance on 3rd party services, and that response procedures are in place in case of incidents.

  • Reproducible builds
  • Incident response procedure
  • Reduce metadata leakage (Infura, Etherscan, etc).

Make Status publicly available
For true accessibility and inclusivity, it should be easy to download Status in 1 step.

  • Launch in App Store (is Windows included?)

Improve usability of app fundamentals
Improve UX of core flows and fix broken features across the application.

  • Remember password on Android; fingerprint login/signing on android and iOS.
  • Wallet functional and UX improvements
  • Support for efficient, network agnostic and truly decentralized transaction/transfer history
  • Fast Dapp loading
  • DApp functionality supported

Support popular EIPs
Keep up with community standards that other DApps and wallet/browsers are implementing. Status was the only wallet that could not be used for QR code scanning to redeem something at Devcon due to lack of EIP implementation.

  • Wallet EIPs
    • SNT first-class citizen (tx history); implement EIP-681.
  • Universal login

Educate users within the product
It should be clear how people benefit from using Status. Ethereum concepts should be simplified, and privacy controls easy to find and use.

  • Better onboarding / patient zero
    • ENS registration during onboarding?
    • Intro new identity structure (Work Package 1 profiles & privacy controls
  • Privacy settings
    • New privacy controls for joining chat - i.e. "Join as"

Decentralize DApp curation
We currently have a centralized, hard-coded list of DApps. This is burdensome on the team, not scalable, and a missed opportunity for SNT utility and community ownership.

  • DApp discovery/curation mechanism. The only current proposal is here.

Improve overall navigation
UXR has shown that Status is cumbersome for users to navigate. One sticking point is the lack of separation between DApps & chats on the home screen, as well as the number of clicks required to switch contexts.

  • Tab bar redesign
  • Improves DApp visibility + cleans up home screen

Make it easier to get crypto
White paper use case.

  • Status Teller Network
    • With Local Eth / Partner

Enable DApps to communicate with users
DApp developers would love a way to send push notifications to their users.

  • Exposing Whisper protocol to Dapps in a safe way
  • (Adam): Chat and Dapps integration ???

Manage technical debt / distill the codebase
Codebase is quite tangled. There are concrete things that could be done to improve things. It's very hard for outsiders to understand what the code does right now. More info.

  • Process adjustment to code reviews, technical decisions, etc.
  • Unit / generative testing

Maintain knowledge better
Decisions are not recorded, the codebase is difficult to understand and external documentation is still lacking.

Support developer community
Initiatives to support developers through tools like extensions require significant time commitment to continue.

  • Continue to develop extensions
  • Additions to Status JS API
  • Work with specific teams at first, like FLEX DApps, to improve extensions before looking for wider engagement.

Exclude from poll:

Increased Resilience of Master Nodes <<- overlap with P2P team, reorganize?
Current node cluster is centralized, vulnerable and a missed opportunity for SNT utility.

  • Support push notifications
  • SNT utility
  • Other (eg Dappnode)

  • Breaking Whisper

  • Improve mail server
    • Dappnode as extension?

Meet table stakes requirements <<- Already WIP
These features are both WIP.

  • Audited private group chat
  • Perfect Forward Secrecy

Support low end devices <<- Native team? Infra team?
The minimum device requirements for Status is currently prohibitive for many mariginalized groups.

Light client in production <<- Infra team?
Until the light client work is realized, Status is reliant on Infura, centralized, and not fulfilling its promise of allowing users to run a node on their phone.

  • LES functioning
  • Integration of ULC

Photos of IRL notes

Native/Desktop Team

  • Achieve feature parity for Desktop
    • DApp browser
    • Wallet
    • Private Group Chat w/ PFS
  • Sync between Mobile <-> Desktop

P2P Team

Some of these topics were identified in the priorities above.

  • Master nodes (P1)
    • resolve poor performance and huge resource usage (CPU and memory)
      • Disc V5 might be a problem
    • SNT utility
      • SNT as spam protection ???
    • spam protection (with regards to the number of messages, not their content)
      • SNT ???
      • rate limiting ???
  • Mail server (P0)
    • unreliable
    • centralized
    • request for messages provides no delivery guarantees
      • should we have more stages?
        • e.g. ack a request
      • encapsulate all steps in a single RPC method
    • single-threaded within a peer context (can't handle more than one request for messages)
    • is the current architecture valid?
      • trustful, leaking metadata
      • what about decentralized storage?
      • why built into Whisper? Unnecessary complexity of the protocol
        • storage can be a property of Whisper where storages are pluggable (local disk, IPFS, swarm)
        • delivering data can be a separate protocol
    • educate users that mail servers are trustful entities and usage of public mail servers leaks metadata
  • Peers Discovery Protocol (P1)
    • clean up the current situation
      • Disc V5 won't be worked on by devp2p devs (complete rewrite or stick to discovery v4 + ENR)
      • Should we switch back to Disc V4 + ENR ???
      • Rendezvous is implemented but unused
    • write an EIP or just a doc explaining how to achieve peers discovery on mobile
      • Why don't we work in this way? :D
  • Observability (P0)
    • node can report invalid state
      • for example: no peers for N seconds, out of bounds in terms of number of packets or excessive data flow
    • liveness/healthchecks built-in
      • Mail servers sometimes get in a state when they don't deliver any messages; they should restart themselves
        • what's causing this?
  • libp2p integration (P0/P1 ???)
    • we can have libp2p transport and with correct integration with whisper it will allow mobiles to have a confirmation that messages are sent.
    • same http transport will allow android app to sleep when it is not used. which according to Igor will improve situation with cpu consumption when app is in background.
    • we will get nat tools available for libp2p ecosystem for free. e.g. some of the desktops will be usable as relay nodes.
Select a repo