mirror of
https://github.com/status-im/swarms.git
synced 2025-02-01 12:55:10 +00:00
Update 315-core-improvements.md
This commit is contained in:
parent
9a28a9a91b
commit
b072ffa7f9
@ -46,40 +46,27 @@ The work includes releasing internal "dogfood" builds as well as betas in prepar
|
||||
|
||||
# Research
|
||||
|
||||
### 0. Meta (what this team will be doing?)
|
||||
### Meta - Done
|
||||
|
||||
Completion by December, 19th (1 week)
|
||||
### Meta (what this team will be doing?)
|
||||
Backlog is created
|
||||
|
||||
Goals:
|
||||
- Figure out the list of tasks and top UX issues that needs to be fixed
|
||||
- Rank them by priority (what should we do first)
|
||||
|
||||
### 3. Improve Security using native views
|
||||
|
||||
Completion by 21/12/2018
|
||||
|
||||
Goals:
|
||||
- Figure out how we can use native code (Java/ObjC) to short-circuit sensitive text views
|
||||
to Status-Go, so attacks like [event-stream incident](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident) are impossible.
|
||||
### 3. Improve Security using native views - Done
|
||||
PoC is created for using native views
|
||||
|
||||
## Specification
|
||||
|
||||
### 2. "Save Password" on Android
|
||||
|
||||
* Timeline - January, 14th
|
||||
|
||||
The goal is to achieve feature-parity between iOS and Android in terms of
|
||||
storing the password.
|
||||
### 2. "Save Password" on Android - Done
|
||||
|
||||
Epic: https://github.com/status-im/status-react/issues/5793
|
||||
|
||||
- [ ] Threat modelling (STRIDE) + document about that.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Done
|
||||
|
||||
### 0. Meta
|
||||
* Timeline - EOQ2 2019, continuous process. Each backlog item discovered by
|
||||
research will have it's own deadline.
|
||||
|
||||
* Timeline - EOQ2 2019, continuous process. Each backlog item discovered by research will have it's own deadline.
|
||||
|
||||
Setup a regular meetings with the stakeholders to adjust the backlog.
|
||||
|
||||
@ -90,25 +77,28 @@ Projects from should be put in the correct state to see the progress, etc.
|
||||
|
||||
### 1. Message Reliability Improvements
|
||||
|
||||
* Timeline - January, 11
|
||||
* Timeline - January, 31
|
||||
|
||||
The goal of this project is:
|
||||
|
||||
* to make messaging extremely reliable;
|
||||
* to be able to prove that;
|
||||
* to be able to show that information to a user (especially it is important to
|
||||
communicate if the message isn't delivered).
|
||||
|
||||
`document progress`: see the epic https://github.com/status-im/status-react/issues/6757
|
||||
`document progress`: https://www.pivotaltracker.com/epic/show/4178343
|
||||
|
||||
### 2. "Save Password" on Android
|
||||
|
||||
* Timeline - January, 21th
|
||||
|
||||
Epic: https://github.com/status-im/status-react/issues/5793
|
||||
`document progress`: https://www.pivotaltracker.com/epic/show/4179882
|
||||
|
||||
- [ ] Implement according to the spec
|
||||
- [ ] Audit the implementation
|
||||
### 3. Slow sign-in - DONE
|
||||
|
||||
### 4. Dependency audit for reproducible builds
|
||||
|
||||
* Timeline - January, 25
|
||||
|
||||
`document progress`: https://www.pivotaltracker.com/epic/show/4182830
|
||||
|
||||
### 5. Fix critical issues with traffic consumption
|
||||
|
||||
* Timeline - January, 31
|
||||
`document progress`: https://www.pivotaltracker.com/epic/show/4182828
|
||||
|
||||
## Maintenance
|
||||
|
||||
@ -126,103 +116,8 @@ Epic: https://github.com/status-im/status-react/issues/5793
|
||||
|
||||
## Backlog
|
||||
|
||||
This backlog is organized in a prioritized way. The higher the project the more important it is.
|
||||
When promoting the project, it is also important to make it more detailed.
|
||||
See Pivotal Tracker: https://www.pivotaltracker.com/n/projects/2232205
|
||||
|
||||
### Improve secure storage of geth private keys
|
||||
|
||||
1. Get rid of `react-native-keychain` and it's dependencies.
|
||||
2. Patch `go-ethereum`, so AndroidKeyStore and iOS KeyChain (+optional Secure Enclave encryption) are used to store private keys.
|
||||
|
||||
### Split Whisper and Ethereum keys
|
||||
|
||||
|
||||
|
||||
### Improved message compatibility with other versions and other clients (using the *current* version of the protocol)
|
||||
|
||||
**Problems**
|
||||
1. It is too easy to change protocol (message format, etc) in a PR w/o necessary oversight.
|
||||
2. There are no tests to detect that message format or semantics didn't change after PR is merged.
|
||||
3. We don't have any procedures and best practices on how to introduce changes to the current protocol.
|
||||
4. We don't have any procedures and best practices on how to handle breaking changes gracefully and coordinate them between the clients.
|
||||
5. We don't have any procedures, tools and best practices to handle breaking changes in mailservers.
|
||||
|
||||
### Spam filtering & DDoS Protection
|
||||
|
||||
We lack the way of protecting our network from spam, especially on the network
|
||||
layer where a bot can relatively easily spam channels or at least waste users'
|
||||
traffic.
|
||||
|
||||
### Reproducible builds
|
||||
|
||||
**Problems**
|
||||
1. Right now it's hard to tell exactly which commit of any dependency was used to build a particular release
|
||||
2. Users don't have guarantees that the release they downloaded matches the official release (i.e. hasn't been tampered with).
|
||||
3. A user should be able to build the sources on his own machine and obtain exactly the same binaries.
|
||||
|
||||
|
||||
### Reduce unnecessary bandwidth usage
|
||||
|
||||
https://github.com/status-im/status-go/issues/1266
|
||||
|
||||
Make sure that we identify and fix all the unnecessary bandwidth usage cases. We need to be able to test the usage regressions in the future, so these issues don't happen anymore.
|
||||
|
||||
Currently, it looks like our application uses too much bandwidth.
|
||||
|
||||
**Why?**
|
||||
|
||||
1. We don't have bandwidth tests in place.
|
||||
2. Mailserver requests seems to be very expensive in bandwidth and we probably receive a lot of duplicate messages.
|
||||
3. We don't know all the places where networking is used, so we can't measure bandwidth client-side (we have to only rely on iOS/Android settings to check that).
|
||||
|
||||
### Improve mechanisms of storing/using sensitive information on mobile
|
||||
|
||||
**Problems in this area**
|
||||
|
||||
1. It is possible (and it happened before) to leak sensitive data through logs and debugging information.
|
||||
2. Unsafe defaults in some publicly available builds in the application.
|
||||
3. Sensitive information is used directly (accessible to most of the app components), whereas the best practices is to provide minimal APIs to do whatever needs to be done w/o exposing data (see Secure Enclave data signing)
|
||||
4. (potentially) Storing sensitive information which we don't have to store.
|
||||
|
||||
|
||||
### Support LES and ULC
|
||||
|
||||
Add an option to use LES and ULC in our application. It should work on Ropsten and Mainnet with working discovery.
|
||||
|
||||
Status can host clusters for LES and ULC, for both testing and reliability purposes, but the usage of LES/ULC shouldn't be limited to that.
|
||||
|
||||
See more and up-to-date info in the Epic: https://github.com/status-im/status-react/issues/6905
|
||||
|
||||
### Reduce metadata leakage
|
||||
|
||||
### Audited private group chat and PFS
|
||||
|
||||
### Integrate with `libp2p`
|
||||
|
||||
### Better discovery
|
||||
|
||||
1. Support/integrate geth initiatives
|
||||
|
||||
### Be able to update bootnodes list if they are blocked
|
||||
|
||||
1. Being able to update bootnodes list if they are blocked
|
||||
|
||||
### Push Notifications v2
|
||||
|
||||
https://ideas.status.im/ideas/086-push-notif-v2/README
|
||||
|
||||
### LES/ULC: Economic incentives
|
||||
|
||||
> [dmitry] is it about proposal from Jacek?
|
||||
> [igorm] probably, I'm not sure. it isn't the priority unless LES/ULC is just functional.
|
||||
|
||||
### VipNode support
|
||||
|
||||
|
||||
### Implement EIP-681
|
||||
https://eips.ethereum.org/EIPS/eip-681
|
||||
|
||||
> A standard way of representing various transactions, especially payment requests in Ethers and ERC #20 tokens as URLs.
|
||||
|
||||
## Copyright
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user