status-im / swarms Goto Github PK
View Code? Open in Web Editor NEWSwarm Home. New, completed and in-progress features for Status
Swarm Home. New, completed and in-progress features for Status
Idea: DEV#0022
Title: Practices for performance control
Status: Draft
Created: 2017-11-17
A set of practices (tools, documents, methods) to help diagnose and prevent performance regressions
User experience is paramount for user retention, especially in mobile environment.
Performance issues are hard to pinpoint without special tooling and trivial changes might introduce subtil performance regression.
We want to ensure we own performance profile of our products.
Provide a list of tools with associated documentation to quickly identify sources of performance issues.
Specifically those performance issues might lie:
NOTE Fixing those issues is not part of the scope
Simple change might introduce performance regressions. Automatizing the discovery of those regressions reduces the probability that they will be shipped.
Even when everything is optimized there can still be some inherent slowness, especially on older mobile.
Some UX technics can help improving the perceived performance, like:
jank-free
scrollingWhen it comes to performance optimizations, gut feeling is generally wrong.
Define procedures (tools and documentations) allowing to discover the root cause of performance issues.
Goal Date: To be defined
Description: a set of rules allowing to pinpoint performance issues
Automatize performance regression. Some specific e2e tests will track performance of common scenario and will be integrated in Jenkins.
If customizable thresholds are crossed build fails.
Goal Date: To be defined
Description: improvements to our CI preventing performance regressions
Define precise guidelines and technics that must be implemented consistently to provide a smooth UX.
Goal Date: To be defined
Description: a set of practices to improve perceived reactivity
Copyright and related rights waived via CC0.
Idea: #53
Title: SOB Bounty lock
Status: Draft
Created: 2017-12-01
A developer who is interested in a bounty but would like to reserve it so that someone else cant claim it, can pay X amount of SNT to lock the bounty for Y time frame.
As a developer, I find a bounty that I am interested in working on, but I'm not sure if I can finish it quickly enough before someone else, or maybe I need a few days before I can start it, so I pay an amount of SNT to lock the bounty for a time period where only I can claim it.
1- 3 different time frames (1 day, 3 days, 5 days) that you can lock for
2- SNT value could be fixed or % of value of bounty
3- You can only initiate a bounty lock once per user
4- Whats technically possible for where the SNT would go? Can it go to a separate address different to the bounty to trigger a lock when received?
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Browser update + new chat header look
Status: Draft
Created: 24-11-2017
The idea to treat Dapp's webview and Chat with a person as first class entities requires some UI updates. Need to add a regular browser as well to be able to open in-chat links.
Made the Chat header and Browser header look similar. See browser window in action https://framer.cloud/HuwfG
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: 51-test-cluster
Title: Testing cluster
Status: Draft
Created: 2017-11-29
Provision test cluster consisting of Status nodes running the simulation of real user behavior. Setup high-level metrics monitoring and track changes between releases.
The idea stems from #22 (tools for diagnosing performance regressions). One of the main challenges with it is to simulate real-world load and currently, we have no way to do this. Analyzing performance on a single device is also prone to inaccurate results due to the high variability of hardware, software running in the background and other conditions. We also have no easy to way to gather metrics we want from devices.
This leads to the idea of provisioning a cluster consisting of nodes (status-go, real devices or both), including boot nodes. Cluster may run on its own test network or on existing test network (Ropsten). Each node in the cluster shall be instrumented and configured for metrics collections. Infrastructure for metrics gathering, storing and display should be set up.
Using graph visualization tools (like Graphana) it'd be possible to see statistically sound performance measurements, pinpoint changes to release/version changes and easily identify regressions.
Think about this cluster as a Status network playground, where you can deploy, say, 30% nodes with a new change and easily see the difference in performance metrics against stable version. It also enables further possibilities for data gathering and exploration. Example: by collecting stats about each incoming and outgoing whisper message, we can visualize Whisper protocol behavior which may help to build intuition around it and help to debug/develop future versions of the protocol.
Implementation of this idea has three roughly independent parts that need to be researched, designed and implemented:
This part should start by evaluating the viable size of the cluster we want to have: 50 nodes, 100, 1000, dynamic? Then, which nodes cluster should consist of: only status-go nodes, real devices/simulators or both.
Then find the best software solution for that. This part requires an understanding of the ethereum discovery process. Solutions like Docker Swarm might be enough, but it might be possible that we'll want to simulate real network topology, for which we'll need to use specialized simulators like Mininet. Each node should probably be isolated using containers, but any isolation alternatives can be evaluated of course. That's unlikely that cluster can run on the modern laptop (it would be awesome though), so the cloud provider should be chosen, whichever easier to work with (AWS/GCP/DO, I guess).
Once the vision of how the cluster should look like is clear, provisioning scripts and tools should be implemented and designed to be developer friendly, with a high level of automatization (again, terraform is probably the right way to go). Ideally, we should be able to deploy as many identical clusters as we wish without any hassle.
In case if cluster runs on the private network, it should setup own bootnodes as well.
As the main purpose of having test cluster is to gather data and observe behavior at scale, the code needs to be instrumented to provide those metrics to the metrics collection infrastructure. Here we have two connected parts: code instrumentation and setting up metrics collection infrastructure. Ideally.
Developers might want to add custom metrics apart from obvious things to measure — CPU, memory, I/O stats, etc. Go code would probably want to report number of goroutines, garbage collection stats, etc, plus many custom things like the number of Jail cells, incoming and outgoing RPC requests, etc.
The task here is to make code instrumentation to be as friendly to the developer as possible: it should be easy to add and test new metrics with the minimal learning curve. One of the examples of such easy approach is expvar
Go stdlib package, which might work perfectly for the pull
model of metrics. Which model to use (pull/push) is a subject to investigate.
Finally, the instrumented code should not go into production. It can be implemented via build tags, or simply by mocking it with dummy NooP metrics sender, which doesn't change resulting binary code.
This infrastructure should be a part of cluster deployment, so if there are many clusters, each has its own metrics dashboard and tooling. Essentially it involves metrics collection code, storage (for some period of time) and visualization software. There currently a lot of software to choose from, including Prometheus and Graphana, so the best tools should be chosen here.
Then deployment scripts and code should be implemented. Ideally, it should be (almost) zero configuration for nodes.
This part consists in developing ways of automating user interaction with Status node and researching of real-world user behavior. First one is more or less simple — provide API to talk to the node, and make it do stuff (send messages, create chats, use dApps, send money, etc). The second one is trickier because effectively it's about simulating the whole economy and humans behavior — simulation code should decide who sends the message to whom, how often, how much money to send, how to use dApps, etc.
Obviously, perfect real-world simulation is unlikely to be achieved, we just need the simulation to have two properties:
Each simulation agent could be independent or controlled by a single node in cluster — subject to investigation, which would be a better approach.
MVP should consist of:
Copyright and related rights waived via CC0.
Idea: DEV#26
Title: Status Beta
Status: In Progress
Created: 2017-11-20
Replaces: PROC#019
This issue is a meta-summary of some ideas, goals, and considerations around the beta release of Status. The goal is to
The vision for Status is to drive mass-adoption of Ethereum.
As a first step, the beta will focus on shipping these core features:
The result of the beta will create the leanest product that can validate the vision outlined above in the pursuit of exposing new users to Ethereum and driving the adoption of its technologies. The beta should do just enough to showcase each core foundation, validate our assumptions, and inform future work.
Following from the stated goals of Status, the beta should at a minimum be based on a chat form factor that facilitates interaction with messaging, payments, dapps, wallet-based crypto-assets. We intend to underpromise and overdeliver.
These goals are at a high level, and rather than listing all the required features each Swarm will find their own way to meet these goals so that a user can:
Additionally there are core support functions, such as signup, settings, etc. These support the core features.
Also there are technical goals such as performance, security that need to be considered.
And importantly, the goal of the beta is to ship within an accelerated timeline. Done is better than perfect.
The beta is NOT about extended functionality on top of the core foundation. Instead the beta aims to enable these additional layers later, such as SNT use cases, a sticker market, DApp directory, teller network, group chat etc. All of these will rely on the chat/payment/dapp/wallet foundation established by the beta.
We should not work on something that isn’t explicitly outlined as fundamental in the Status white paper vision and goals.
To support these anti-goals some features will be (temporarily) removed from the current build as they are not explicitly enabling the core vision.
Whilst the long term vision of Status is driving mass-adoption of the app and Ethereum, the beta is not for everyone. Marketing has focused the initial target groups which are DApp developers, crypto-traders, and tech enthusiasts. These are users that will have some familiarity with blockchain, cryptocurrency, and privacy.
Goal Date:
Description:
Goal Date:
Description:
Testing Days required:
Copyright and related rights waived via CC0.
Idea: DEV#00
Title: Public chat discoveries
Status: WIP
Created: 2017-11-13
Requires: #8
Allow public chats to be discoverable so that people can join them.
Where we are at the moment:
Where we want to be:
It is recommended that #8 is implemented before this Idea, so that Discover is in a consistent state before we add any new feature.
TBD
Goal Date: TBD
Description: TBD
Goal Date: iteration sign off + 2 weeks
Description: Discoverable public chats
Copyright and related rights waived via CC0.
Idea code: DEV#042
Title: Multi wallet support
Status: Draft
Created: 2017-11-23
Multiple wallet management
Status provides a comprehensive wallet allowing to manage your main Status ethereum address.
As a user I want to leverage this wallet to manage other addresses.
We will also consider if switching address should also impact other status features (DApps browsing, bot usages, ..)
New addresses can be added and browsed in the wallet. All existing features (browsing funds, access to historical data, send/request funds) are functioning.
Status must be able to interract with hardwallet
and other hardware wallet. Consider how this impact our current wallet abstractions.
A new address can be added and switched to. All wallet features are functioning.
Goal Date: To be defined
Description: any ethereum address can be used in wallet
Decide how switching address impacts other Status features
Goal Date: To be defined
Description: decision on how address switching impacts Status
Identify specific changes needed to interact with hardwallet
Goal Date: To be defined
Description: hardwallet
can be used in Status wallet
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: GitPivot
Status: Draft
Created: 2017/11/22
Incentivize open-source development by providing tools to fairly distribute donations and bounty contributions.
Who owns an open-source project that have contribution of hundred of developers?
Who should control the licensing or accept changes?
Through tokenizing contributions users can proof ownership of project and use it in a voting contract.
To help, we can have a special software licenses stating that the source code owners are expressed in an ethereum smart contract.
For a project being accepted by GitPivot it must have a file in root of tree called .gitpoints
with specifying user-agent:
to *
or gitpivot
.
Example:
user-agent: *
commits-reward: words
issues-reward: pulls, comments, commits, reactions
pulls-reward: comments, commits
comments-reward: reactions
reactions-reward: heart, +1
To control GitPivot users need to link their GitHub user login to an Ethereum address.
User calls GitPivot and passes his username and the gistid, GitPivot registers users by loading gistid file called register.txt
under user login
. This file must contain only the Ethereum address who made the register call, starting with 0x
.
Any repository that enabled commits-rewards will have tokenization enabled of the contributions and a donation bank.
The available modes are lines
or words
that respectively mint tokens by added lines or added words. Custom reward modes are planned.
GitHub Oracle load commits in batches, and accept continue in case of huge commit trees (+4k commits).
Repositories that enabled tokenizations of contributions also have a DonationBank
that can be withdrawn by the Project Token Holders in the start of every epoch, called locked period, where transfers and minting are blocked.
Issues may be tracked by GitPivot, accept payments, depending on the .gitpoints
configuration, positively reacted posts and merged pull requests/commits generate points that allow issue contributors to withdraw a fair share of balances related to the issue.
The elements of the system can be used in other descentralized applications and deployed in other networks, extending the features of SOB.
Different types of contracts can be programmed to automatically buy project tokens, under arbitrary rules, such as a list of users with a maximum amount per day. This can be part of other descentralized application or as a custom contract.
In replacement of selling coins of a promised project, developers can create the tokens their project need by code contribution and get paid for their development selling their development tokens.
The ICO contract might have milestones that realease a share of a prealoccated token source to project token holders.
Issues rewards and commit points are discovered reading GitHub API through Oraclize computation data source, that reads all issues or branch commits at once and return to contract points and authors.
Updates can happen once in a month, or daily, anytime, by anyone.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: DEV#0040
Title: Status Open Bounty end-to-end automation
Status: In Progress
Created: 2017-11-23
In order to reduce time spent on regression testing we should automate the testing
Goal Date: 2017-11-28
Description:
Goal Date: 2018-05-02
Description: define actions needed for future automate tests
Copyright and related rights waived via CC0.
Idea: #48
Title: SOB Bounty sort/filter option
Status: Draft
Created: 2017-11-28
There is no way currently to sort or filter the list of bounties on the page. A sort and filter option would be very useful as our list of active bounties start to add up.
As a developer looking for bounties to work on, I would like to be able to search, filter, and sort the bounties available, in order that I can find suitable bounties that I'm interested in without having to scroll through a large list.
Sort options should include:
Filter options should include:
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: DEV#52
Title: Improve status-go release process
Status: Draft
Created: 2017-11-29
status-go is being consumed by more and more projects like status-react and status-desktop. We also create libraries that wrap status-go like status-nodejs or React Native modules embedded in status-react.
The goal of this idea is to improve status-go release process and allow other projects to safely depend on status-go.
There are a lot of problems with how status-go is released now:
develop
branch,master
,The vision here is that the release process is automated and its outcome is a new git tag, changelog on Releases page and binaries for iOS, Android and node.js (linux and macOS oses).
Also, any code in master
branch should be considered safe, i.e. it should pass all tests, including e2e tests on public networks. master
could be considered also as latest
release. (TBD, we may not need this at all.)
This could be also really helpful for bug reporting (especially, if we want to use SOB for bug reports in the future) and Test Team as it's often unknown, until further analysis, which status-go version (currently git SHA) is used by the current Status app build.
Finally, it's something that may bring more external contributors as the project will be better managed and organized.
I think two contributors is enough. It's hard to split the work here between more developers.
Introduce an automated way of versioning and concept of release branches. It's described in details here: status-im/status-go#422.
Goal Date: TBD
Description: Deliverables described in status-im/status-go#422.
Each release should contain binaries for the following platforms:
.aar
library),Goal Date: TBD
Description: Binaries on Github or other file hosting provider, easily accessible for other projects.
Copyright and related rights waived via CC0.
Idea: #49
Title: SOB activity feed
Status: Draft
Created: 2017-11-28
The current "Activity" tab is confusing and feels disconnected and disjointed from the "Open Bounties". These should be integrated somehow so you can track activity against each Bounty and be able to easy follow its progress.
As a developer looking for bounties to work on, I want to have a uniform view of all bounties, both current and closed, so that I can monitor activity against them, and look at historical bounties for comparison.
As a developer working on a current bounty, I want to easily track its progress, so I can see if anyone else is also working on it or submitted a claim, and any changes to the bounty though out its life, including increase in value.
Integration of the activity feed into the bounties. This may also mean we need a way to capture and display closed bounties
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea code: DEV#003
Status: Done
Created: 2017-11-08
Add ERC20 support
As a user I want my ERC20 tokens to be first class citizen.
Swarm channel: 3-erc20
A user should be able to manage its ERC20 tokens pretty much the same way as ETH.
In particular wallet
and send
command must support ERC20 tokens.
As a first step considered ERC20 tokens will be based on a static list embedded in the application. This might be revisited later (see #18).
ERC20 extensions might also be considered: ERC223, Minime (SNT itself is a Minime token).
https://github.com/status-im/status-react/projects/4
Following features should be considered:
Can be split in 4 categories:
Token details will require some metadata currently not available in ethereum.
Token price details can be provided by cryptocompare
.
List user tokens and display token details
Goal Date: 2017-12-01
Description: token list and details
Allow sending and requesting tokens.
Goal Date: 2017-12-15
Description: send/request tokens
send
STT (status test token) under Ropsten testnet in Wallet
request
STT (status test token) under Ropsten testnet in Wallet
Demo acceptance:
Show token historical data and update percentage info
Goal Date: 2017-12-22
Description: token historical data
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Chat moderation
Status: Draft
Created: 2017-11-23
Related: https://github.com/status-im/ideas/issues/15
Moderation of public chat groups.
Users must have greater control over the content in their chat feeds to ensure a positive experience. We can give users that control by providing them with a suite of moderation tools. Our moderation tools will enable users to define their own content rules or subscribe to a moderation provider to do it for them. A marketplace will ultimately exist where users can choose from a range of moderation providers.
Goal Date:
The MVP provides users with basic moderation tools so that they can block users, filter posts with certain phrases, and reduce spam.
User A enters a public group chat. User B sends a message that User A dislikes. User A blocks User B. All messages from User B no longer show up in any chat feeds of User A.
User A enters a public group chat. User A discovers that messages in the chat feed are low quality (spam). User A adjusts the required SNT burn value until the quality of the chat feed improves.
User A does not want to view any messages that contain the phrase x. User A updates their moderation rules to ignore any messages that contain the phrase x. Messages that contain the phrase x no longer appear in any chat feeds of User A.
User A is a power user. User A configures their moderation rules to include the address of a smart contract that implements a standard rules interface. The smart contract will be called to evaluate new messages as they are received.
Goal Date:
Users can subscribe to moderation providers.
TBD
Goal Date:
A moderation marketplace.
TBD
Goal Date:
#Description:
Copyright and related rights waived via CC0.
Idea: DEV#11
Title: Bounty for the found issues
Status: Draft
Created: 2017-11-13
Make it possible to give bounties for the found bugs
Anyone who reported an issue can be rewarded with a bounty if the issue is valuable.
bug-bounty
.bug-bounty
to the issue. This triggers a bounty contract to be created on the issue.XS
, S
, M
and L
We trust that team members will evaluate the bug and pay proper reward for it (rewards should be listed per project probably, e.g XS in project A is 2 000 SNT, XS in project B is 100 SNT, there is no voting mechanism. Contributors will just see the history for each bug in GH and decide if they want to participate in the project. So if reward is considered unfair then no more contributions will come.
bug-bounty
bot would copy it's tittle and content as a comment, so reviewer can see initial bug report.Goal Date: 2018-03-30
Description:
In short: contributor can get test SNT for the reported bug. All process is manual (to verify it works and find weak spots before implementing smart contracts and changing SOB site)
Bug-Bounty
type in the issue descriptionbug-bounty
and label size
(e.g. bug-bounty
and M
). If bug report not ok then explain why (ask for extra details, close if duplicate with previous issue number, etc)There will be a "closed beta" group of testers to avoid any frauds and games with copying others bug reports. If it works well and we implement copying initial issue description as a comment then next iterations can be open for everyone.
MVP verifies that proposed process can work and is aimed to find weak spots in the process before implementing bot/smart contracts/SOB site modifications.
Outcomes:
Swarm members:
Need several reviewers (2-3) who know open issues or can learn them to review new bugs for duplicates and good description. Also evaluator is needed to decide if swarm does what it promised.
Goal Date:
Description:
Finance: will use funds from SOB funding, if 24 000 SNT are used before end of iteration then we stop cc @andytudhope
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Message viewers for Chat
Status: Draft
Created: 24-11-2017
At the moment there are missing these message viewers for the chat:
These are the initial states, need to add more states, will do soon, work in progress.
Re-using the transaction details screen from wallet for consistency.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: DEV#007
Title: Replace status-go bindings with a single RPC-like one
Status: WIP
Created: 2017-11-10
The idea is to replace most of the currently exposed bindings in status-go with a single one that operates on a JSON-RPC protocol. It will allow us to remove a significant part of glue code that needs to be written between status-go and platforms that use it (status-react, status-desktop, possibly others).
The vision is to have only two bindings exposed: CallRPC
and CallPrivateRPC
(subject to change as may be confusing, CallBinding
or CallPrivateMethod
maybe?). They are totally separate and serve totally different purposes.
CallRPC
is used to forward JSON-RPC calls to the ethereum node that status-go runs inside. It will be used to implement custom providers to web3.js.
CallPrivateRPC
will be used to perform actions like StartNode
, StopNode
, Login
, CreateAccount
and will effectively replace all the bindings that status-go currently exposes.
As bindings are exposed as C functions, glue code is required to call them from status-react (native modules written in Objective-C and Java) and status-desktop (C or C++ code). Reducing the number of bindings and using a single one supporting a protocol like JSON-RPC will allow developers to modify or add new actions without modifying the glue code at all.
This project should finish in a week. It will require at least 2 developers who will work on status-go side and at least 1 who can help with React Native modules and Clojure code.
TBD
TBD
The Status app works as before changes. Some currently exposed bindings may be missing but it should be possible to create an account, start node and use chat.
Goal Date: 2017-11-27
Copyright and related rights waived via CC0.
Idea: 24-onboarding
Title: Onboarding experience
Status: Draft
Update: 2017-12-21
Requires: #26
Status, Ethereum, cryptocurrency and the decentralized internet are new paradigms for many users. The job of onboarding will need to educate and inspire users about these new technologies, as well as help users get started with Status, create an account, send their first message, explore their first app, and initiate their first transaction.
Onboarding will be an important part of the upcoming beta release. Currently this is in a preliminary explore phase, and the requirements will evolve as the beta work matures.
This swarm will be the collaboration of marketing, product, design, and engineering to ensure that users have a consistent brand and product experience.
In progress.
Swarm channel: #24-onboarding
Create onboarding flow mockups
As we define the brand tone of voice, make sure this is reflected in the on boarding experience.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Delegation Proxy
Status: Draft
Created: 2017-11-15
Delegation Proxy provides ability to set other account (some Delegate, any other address) to take influence on behalf of self.
"Having the promise of blockchain be trustless trust and be decentralized, how decentralized the system is in future when, currently, it might change it, only 5 to 30 people in this whole network really understands the ins and outs of such a great discussion. (...) when we need to take action at this moment we need to trust the experts."
Blockchain's Problems with Unknown Unknowns - Shermin Voshmgir
Delegation Proxy enables to set which expert you trust (can be none but yourself). There should be a root delegation proxy level, and for each expertize field there should be a specialized delegation proxy, which in case of unset for a determined account would lookup at parent proxy.
PoC
A specific topic for #18 can be used to improve reach of quorum in Token Registry consensus.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Cryptoeconomics solutions for SOB public adoption
Status: Draft
Created: 2017-11-14
Surround SOB state-change with cryptoeconomics incentives using bounty prize to pay deploy.
Status Open Bounty gas expanses are currently being paid by Status, this is done because repository owners without any Ether can start opening bounties.
Status will not be able to pay for this service forever, however we replace it by a cryptoeconomic solution around the state-change of SOB.
The simpliest implementation would be:
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
@oskarth commented on Thu Sep 21 2017
As a user, I want the Status wallet to show how all assets in my portfolio are doing, so I know what my financial health is and it can inform financial decisions.
This issue is too big as it stands, but I'm using it as an opportunity to capture and clarify how I envision the wallet portfolio calculation working. I'll do this by way of example.
As we progress with these capabilities and we have a better understanding of the problem space, this issue can be closed. There is thus no specific deliverable or end in this issue, other than what has been described in the user story above.
A portfolio consists of multiple assets. Each assets has some valuation in a certain currency (henceforth USD, for simplicity's sake). This valuation fluctuates from day to day. The amount a user has of a certain asset also fluctuates, but usually not on a day to day basis by that much.
As an end user, if I invest $100 USD in crypto and this includes ETH, SNT, etc I want to know roughly how much my portfolio is worth in USD if I were to liquidity it. I also want to know how I'm doing - is my portfolio going up or down in terms of USD? Of course, USD is arbitrary and it could be measured in ETH, BTC or number of second-hand Saabs 93s.
I own two assets, A and B. 10 A and 10 B. One A is worth $100 and one B is worth $10. The whole portfolio is thus worth $1000+$100=$1100. In terms of portfolio composition, 90% of my money is in A. If A goes up 10% and B down 10%, my total portfolio, valued in USD, has gone from 1100 to 1100+90=1190. This represent a 8% increase in portfolio value.
Same portfolio but I sell my assets A before the market starts moving and don't capture any gains. I thus have $1000 that I liquidated from A, and when market closes (or 24h later, say) B has gone down 10%. After 24h my portfolio value is 1000+90=1090, which represent a 1100/1090 a 1% decrease.
This case is a bit tricker since we don't necessarily have all the trading data. Thus it makes sense to assume a static portfolio and only compare last 24h with now. At least for now.
If I don't own any assets, or, equivalently, only own USD (or whatever you measure portfolio value in), then the portfolio value never changes. It thus makes sense to say this represent a 0% (or -%) change on any time horizon.
A new asset C is introduced and we don't have any pricing information on it, but it still part of the wallet. I suggest we visually indicate this by greying out that asset somehow, to make it clear that it's not part of the portfolio calculation. This seems like a design question though.
Those are all the scenarios I can think of now, on a high level.
Title: Remove swipe-through navigation and introduce a tab-based screen hierarchy instead
Status: Draft
Created: 2017-11-22
Remove swipe-through navigation and introduce a tab-based screen hierarchy instead.
Tab-based screen hierarchy will make it possible to use swipes inside the screens:
Copyright and related rights waived via CC0.
Idea: DEV#002
Title: Easy status-go consumption from nodejs environment
Status: Draft
Created: 2017-11-08
A simple nodejs
module encapsulating all ethereum interactions.
Status accesses ethereum via a go module built on top of ethereum. This go module is then used through Java and C bridges.
As we are considering using nodejs
based platforms (notably electron
for status-desktop
) it makes sense to offer a nodejs
module.
NOTE Mobile support, while desirable, is explicitly out of scope. For this reason existing glue code in status-go
will have to be kept for backward compatibility.
As a nodejs
app writer I want to integrate with status-node-ethereum
by simply adding the proper dependency in my package.json
.
web3
(used by status-react
, webview (for DApps) and inside jails) will rely on a Web3 provider
offered by the node module. Other internal APIs can be provided differently depending on implementation convenience.
import Web3 from 'web3.js';
import Statusgo from 'node-status';
const status = new StatusProvider({type: "native", id: "ropsten"});
const web3 = new Web3(status.attach());
web3.eth.doSomething();
A simple REPL could offer a great platform for quick experimentation and testing. This is similar to what geth -console
does.
NodeJS offers ample libraries to facilitate this.
./status-node-ethereum
web3.version;
> "1.0.0"
As a go developer I only have to manage a single interface for status-go
consumers.
status-react
team will be the main consumer of this API so they should provide input on what is expected. status-go
team is responsible from the technical implementation.
Security is our top priority. In particular no internal capacity is leaked to the existing JSON-RPC interface.
A strong focus on performance will be put. There should be little overhead in using this approach compared to the existing one (say .1ms extra). While mobile support is out of scope it is important to keep it in mind.
Particularly a in-process implementation is favored (everything is contained in the library).
Let's constraint work on this to 1 week: we should either have a working implementation by then or very concrete steps on how to achieve this.
A simple module that can be loaded and demonstrates viability of the bindings technical solution.
import Web3 from 'web3.js';
import Statusgo from 'node-status';
const status = new StatusProvider({type: "native", id: "ropsten"});
const web3 = new Web3(status.attach());
web3.version;
Goal Date: 2017-11-17
Description: a simple functional nodejs module
status-desktop
(built using electron) will be used as first consumer of this API. A simple version of chat should be built on top of status-node-ethereum
to validate the viability of the approach.
Offer a Web3 provider
Expose management APIs: admin
, debug
, personal
to the extent they make sense.
Expose status API (https://github.com/status-im/status-go/blob/develop/lib/library.go)
Goal Date: 2017-11-24
Description: the final nodejs module
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: General architecture & patterns for status react
Status: Draft
Created: 2017/11/22
Define and adhere to architecture vision for status react. Have all the best practises clearly defined in one place.
Our architecture (shape and organisation of data + code) is not optimal, what's worse it's nowhere clearly defined and discussed about. The purpose of this Idea is to improve it by identifying all the problematic parts of our current architecture, capture them as user stories, fix them and properly document it for future reference.
Goal Date: 2017-12-08
Description:
Goal Date: 2017-12-08
Description: Requirement 1 should be done
Goal Date: 2017-12-24
Description: Requirement 2 should be done
Goal Date: 2018-01-14
Description: Requirement 3 should be done
Goal Date: 2018-02-07
Description: Requirement 4 should be done
Copyright and related rights waived via CC0.
Idea: #47
Title: SOB Organisation dashboard
Status: Draft
Created: 2017-11-27
A simple dashboard view for organisations that post bounties so they can manage their bounties and track their progress.
As the admin on an Organisations repository on GitHub, I would like to have a dashboard view on Status Open Bounty, so that I can view a summary of my bounty activities, and manage their progress all through a central point.
The Orgainsation should also be able to use the dashboard as a way to take them through the steps to post their bounties - step by step guide, and they can see when they are waiting on SOB manual whitelisting etc.
--Summary view--
List of active bounties
List of closed bounties
Total pay out
Highest contributor
--Functions--
Close the issue and retrieve funds
Pause an active bounty for a time period
Reduce payout?? (Just a thought. This use case might have to be done by closing and creating new bounty)
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
@oskarth commented on Thu Sep 21 2017
As a user, I want the Status wallet to show how all assets in my portfolio are doing, so I know what my financial health is and it can inform financial decisions.
This issue is too big as it stands, but I'm using it as an opportunity to capture and clarify how I envision the wallet portfolio calculation working. I'll do this by way of example.
As we progress with these capabilities and we have a better understanding of the problem space, this issue can be closed. There is thus no specific deliverable or end in this issue, other than what has been described in the user story above.
A portfolio consists of multiple assets. Each assets has some valuation in a certain currency (henceforth USD, for simplicity's sake). This valuation fluctuates from day to day. The amount a user has of a certain asset also fluctuates, but usually not on a day to day basis by that much.
As an end user, if I invest $100 USD in crypto and this includes ETH, SNT, etc I want to know roughly how much my portfolio is worth in USD if I were to liquidity it. I also want to know how I'm doing - is my portfolio going up or down in terms of USD? Of course, USD is arbitrary and it could be measured in ETH, BTC or number of second-hand Saabs 93s.
I own two assets, A and B. 10 A and 10 B. One A is worth $100 and one B is worth $10. The whole portfolio is thus worth $1000+$100=$1100. In terms of portfolio composition, 90% of my money is in A. If A goes up 10% and B down 10%, my total portfolio, valued in USD, has gone from 1100 to 1100+90=1190. This represent a 8% increase in portfolio value.
Same portfolio but I sell my assets A before the market starts moving and don't capture any gains. I thus have $1000 that I liquidated from A, and when market closes (or 24h later, say) B has gone down 10%. After 24h my portfolio value is 1000+90=1090, which represent a 1100/1090 a 1% decrease.
This case is a bit tricker since we don't necessarily have all the trading data. Thus it makes sense to assume a static portfolio and only compare last 24h with now. At least for now.
If I don't own any assets, or, equivalently, only own USD (or whatever you measure portfolio value in), then the portfolio value never changes. It thus makes sense to say this represent a 0% (or -%) change on any time horizon.
A new asset C is introduced and we don't have any pricing information on it, but it still part of the wallet. I suggest we visually indicate this by greying out that asset somehow, to make it clear that it's not part of the portfolio calculation. This seems like a design question though.
Those are all the scenarios I can think of now, on a high level.
Idea: PROC#015
Title: Requirements for a High-Quality Group Chat
Status: Draft
Created: 2017-11-13
Requires: https://github.com/status-im/ideas/issues/6
To make Status strong in group chatting wie have to gather ideas and requirements
and compare them to our competitors.
The group chat situation of Status is a bit messy. We used Slack for our internal
talks as well as for the community. Due to troubles with scammers we tried to use
Riot, which sadly misses features we're familiar with. So right now we use Slack
internally, Riot for the community, and Telegram for discussions about cryptocurrencies
and trading.
Our Status itself provides group chat features too. To create a powerful competitor
to existing products, not only Slack or Riot, we need to gather and prioritize
ideas and requirements for our software.
Additionally we have to compare our vision as well as the gathered set of ideas and
requirements with other tools on the market: Slack, Riot, WeChat, WhatsApp, Facebook
Messenger, Snapchat, and more. Goal is to compile a list of requirements to make Status
stronger than the market.
Goal Date: 2017-12-01
Description: Establishing of infrastructure and initial iteration.
Description: Continuous process to improve our product.
(tbd)
Copyright and related rights waived via CC0.
Title: Update the text input
Status: Draft
Created: 27-11-2017
Clean up the text input, put all actions and commands in one row to make it more flexible. Re-arrange the actions and commands;
To make it more clear for people how the text input and commands work, decided to re-arrange the text input. Main points:
x
icon next to it;This is work in progress, open for any discussion and suggestions
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: StatusBOX
Status: Draft
Created: 2017-11-21
As a Status user i don't want to store ethereum blockchain data on my device and don't want ethereum node to drain my battery, also i don't want to use services like infura because it's not safe and in any case i need status node on my phone, and i want to store my messages during i'm offline, i need some cheap and plug'n'play solution, i want to buy it or make it by myself - StatusBOX?
We can manufacture it or user could DIY it, based on Raspberry Pi 3 — A 64-bit Pi with Built-in Wireless and Bluetooth LE.
As a user i want to plug it into an electrical outlet, connect my Status app using Bluetooth, make some initial settings, connect it to my wi-fi network. Thats it, now my Status app working with StatusBOX, and i don't need node on my phone, and StatusBOX will store my offline messages. Also i can "mine" SNT, storing messages for other users.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea code: PROC#006
Title: Know what to do
Status: WIP
Created: 2017-11-10
Structured way to manage the requirements of an idea
Status builds its set of tools and services around individual
ideas. While these ideas draft a larger vision they will lead
to individual user stories and requirements. To ensure proper
realization and quality assurance these need a common agreed
way how to manage them. Here process and documentation have to
be commonly usable, tracable, and induce only few overhead.
Lead Contributor: @themue
Testing & Evaluation: (tbd)
Contributors: Anyone interested in proper requirements (tbd)
Typical requirements engineering tools are powerful, but also
expensive, seldom prepared for distributed usage, and often
bloated. A pragmatic approach will be around GitHub as our
already used tool.
Here an outline of first ideas:
ideas
as we do todayideas
/active
for active ideas/archive
for archived ideas/active
based on the idea code (e.g. .../dev-001
)README.md
containing and also referencing the issueroles.md
listing and describing the participating roles in thisglossary.md
listing relevant terms for this idea/user-stories
for the user story files/requirements
for the concrete requirementsus-001.md
,001
in ideadev-001
could be referenced as dev-001/us-001
)roles.md
above)req-001.md
Material about a Lightweight Requirements Engineering is currently in progress
and will follow. Changes have to be done in branches and merged after pull request
and review by the lead contributor. She also has to ensure that the scope of
the PR is only inside the according idea.
So far this draft is only very rough. Together with more material it has
to be discussed, improved, and specified. Also the role of swarm leads
has to be defined.
Goal Date: 2017-11-24
Outlined and agreed process has to be documented in our wiki and introduced
to the whole team.
Goal Date: 2017-12-08
Implement scripts allowing to create reports on the current set of issues.
Goal Date: (tbd)
Copyright and related rights waived via CC0.
Idea: Update and clean up the messages in Chat. Add missing message types.
Title: Messages Update
Status: Draft
Created: 2017-11-24
There is a lot of UI/UX issues with the chat at the moment. Here i've put together all issues with messages and message types.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: DEV#34
Title: Extend react-native-desktop to support status-react Desktop functionality
Status: Draft
Created: 2017-11-22
Status React cross-platform (Linux, OS X and Windows) desktop version based on react-native-desktop port of react-native.
React-Native-Desktop is the desktop extension of origin react-native framework developed by Status. With direct access to underlying OS's APIs (via Qt Framework APIs mainly) we should be able to have almost full control on software stack and provide better users experience.
Status IM application should has range of unique screens optimized for the best desktop users experience.
Desktops version of Status IM is supposed to re-use backend implementation of Status IM Mobile, but with unique UI screens and based on react-native-desktop extension of original react-native.
Goal Date: 2017-12-11 (Done)
Description: Enhance development cycle to get acceptable performance in code development (adopt figwheel + live-reload, find the way to compile ClojureScript to JS without code optimization (lein has known issues with that)
Goal Date: 2017-12-15 (Done)
Description: Login screen rendering and functionality
Goal Date: TODO
Description: Integrate react-native-desktop into latest status-react sources with desktops screens available.
Goal Date: TODO
Description: Resolve react-native-desktop related UI issues (missed support of some specific props or components, etc)
Goal Date: TODO
Description: Smoothly working figwheel for dev builds
Goal Date: TODO
Description: Stable Status Desktop application with screens specific for desktop users experience.
Goal Date: TODO
Description: Support by react-native-desktop of [all react-native components](https://github.com/status-im/status-electron/wiki/Status-Components are supported by react-native-desktop) used in Status Desktop.
Goal Date: TODO
Description: Automated process of Status Desktop distributions creations for Linux, OS X and Windows desktop platforms.
Status Desktop application with screens specific for desktop users experience based on Status-React (Status IM Mobile) source code base with possibility to chat without interruption.
react-native-desktop
Successful internal usage by Status Team on daily basis.
Copyright and related rights waived via CC0.
Idea: PROC010
Title: Status issue curation and communication by bounties
Status: Draft
Created: 2017-10-11
As part of scaling Status, we use Status Open Bounty. To use it effectively we need to curate issues, put bounties on them, and ensure proper communication with newcomers.
We are already doing this work, and since we want to continue doing it we should formalize it into a swarm. This will probably require high commitment from some people (QA, Community) and low commitment from a larger number of core developers.
We want to ensure we always have a bunch of issues available for people who want to contribute. These should be more than just translations, and vary in bounty size.
Specifically, Status Open Bounty as a standalone project is out of scope for this. This is about us using Open Bounty for status-react, status-go et al. issues, although there's likely to be some overlap.
This is a process, similar to how we do code reviews and QA now, that we want to install in order to scale Status. It requires:
(a) Curation of issues. Not all issues make for great bounties. It is particularly important issues are well-defined in terms of acceptance criteria, and ideally shouldn't require too much context, and no special permissions. They should also ideally not be time-critical, as these issues are best done by core contributors working full-time in dedicated swarms.
(b) Ongoing communication with developers. We want to make sure they get a warm welcome, and that we help them along the way. Additionally, if a bounty issue has been open for a long time we should figure out why and how we can change this. We also want to increase repeat contributors.
Both of these activities and the swarm as a whole has an eye towards improving our two core metrics:
3 core contributors, 2 from community and one from QA. 1-2 devs from both status-react and status-go to help create, edit and otherwise curate issues just 5hrs/week.
Goal Date: 2017-11-19
Description: A swarm with Slack channel and instructions/flows set up for proposal of bounty issues, creation of bounties, testing etc.
Labelling system on issues so that there is an easy flow from developers -> QA -> community and back.
Goal Date: 20/11/2017
Description: Get access to DB so that we can pull the data we need on contributions. Set up automated processes for creating, managing, accepting and confirming bounties. Create Open Bounty Twitter Bot.
Goal Date: 06/12/2018
Description: Discuss with @tpatja the issue.updated
event and whether we can access that from the DB - still no answer there.
We have already started a GH project to track issues using a kanban board to limit the co-ordination and communication costs internally. We need to make sure everyone is using this and that it is working as expected.
Keep on gathering data and providing to Jonny for analytics and blog posts etc.
Co-ordinate wth Arash to get more Riot bounties in, as well as onboard other organisations. This will also mean helping with basic filtering of issues on SOB (#48) and co-ordinating with @3esmit and @tpatja to see when SOB can implement an admin dashboard, allow multiple contributors to a PR, allow multiple admins to manage and confirm payouts, and set time limits on bounties.
Goal Date (start): 05/12/2018
Goal Date (end): 01/03/2018
Description:
Track actual metrics to improve our understanding of how well this swarm is achieving its goals.
Automation of bounties!! We need to make it so that people can simply assign a size label to their bounty and have it automatically funded from a (super) hot account that they only maintain a small balance in and top up every so often, rather than manually funding each and every bounty. This has been a request from a number of projects, most notably Aragon, who have actually already written a bot for us: https://github.com/aragon/autobounty
10% week over week growth in available issues for all Status repos, as well as in status-go and status-react independently. Currently 11 bounty issues in status-react and 5 in status-go. Do this for 3 months and we are at 30x, then re-evaluate since we might hit on financial limits.
10% week over week growth in new contributors for all Status repos, as well as in status-go and status-react independently. After 1 month of real tracking introduce 3rd metric which measures and grows recurring contributors.
Get this data for last few weeks. Plot it over a timeline. Plaster it all over #general on a weekly basis. This achieves three things:
(a) communicates success
(b) clarifies deficiencies, e.g. this repo failed to meet growth target this week - why and how do we fix?
(c) forces automation naturally, e.g. instead of "automate" or "bounty all issues" at once we can gradually introduce processes that actually solve bottlenecks.
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Recoverable System
Status: Draft
Created: 2017-11-18
Provide framework to emergency stop and upgrade dapps - specifically Status Network.
The RecoverableSystem contract is a delegate message forwarder to Application model address, or in case that address code is size zero, to Recoverer address.
RecoverableSystem address will be storing the value and data storage of the application, but not storing the main business logic neither the recovery logic, but only the emergency stop logic, that is activated by address of Application model's code being empty.
The only way of Application model logic being empty is if it was never deployed at that address, or if the code called selfdestruct
.
address.extcodesize==0
to emergency stop advantages:Application logic model owned by Watchdog, and that this watchdog can call a specific function only in model that triggers selfdestruct
, causing the address code size become zero.
Watchdog address is defined in Application model constructor, because it contains volatile code (therefore impossible to recall), Recoverable System should safely reserve watchdog address variable to ensure that is impossible to call the model destructing method in Recoverable System, and if this requires a selfdestruct
then it must be through it's own logic. If not reserved, a risk of unknown unknowns is risen.
Watchdog contract may be:
The watchdog in a ideal scenario should not share code with the application, as we might have a bug in the tokens and we used that for controlling the watchdog, that would make the watchdog useless. Because of this a InterDAO liquid democracy should be used, that other DAOs could trigger a emergency stop in other DAOs.
A delegative democracy, as specified by #20, that uses tokens by democratically aggregated DAOs, starting with Status token, can vote for emergency stop a topic.
The reach of a quorum on a certain topic would trigger the InterDAO watchdog to call a self-destruct in Application model address of that topic.
When adding a new DAO to the InterDAO congress, the current participants must vote for it in the root topic.
When emergency stop is triggered, in place main logic, a recovering code (Recoverer) takes place that can only set new main code address.
The recoverer contract must be extremly simple and NEVER write or read storage besides of changing the application model address.
The usual recoverer contract will only change the application model address, but this call must only came from a democratic repair address, that may be:
What type of Recoverer logic need to be defined as a per DApp case, as if the DApp is owned by tokenized stake-holders, then 2. should be the case. More complex cases can be build, but this two types would be the most cases for all DApps.
Goal Date: Soon
Description: RecoverableSystem Framework
Goal Date: Later
Description: Safe-Proven Democratic Upgrader
Goal Date: Later
Description: InterDAO Shared Watchdog
Copyright and related rights waived via CC0.
Idea: 35-subscription
Title: Status user subscription
Status: Draft
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
Requires (*optional): <Idea number(s)>
Replaces (*optional): <Idea number(s)>
This idea is to explore the feasibility of the economic model for subscription based access to the Status features that require spending, e.g. offline boxing #1
New users awarded with X SNT after successful onboarding.
Users can subscribe for usage packages and don't care about paying for each message stored for offline, etc (carrier's tariff plans analogy). Although the billing implementation could be cumbersome.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Title: Implement Screen Animations and swipe-back gesture on iOS
Status: Draft
Created: 2017-11-23
Implement native screen animations (slide left when opening a screen, slide right when go back, slide up when opening a fullscreen popup, slide down when closing a popup). And implement swipe-back gesture on iOS.
Also, let's remove the "accidental tap" when you are trying to scroll/swipe a list on IOS.
Here's an example of a native "slide in/slide out" animation on IOS https://framer.cloud/HuwfG
Native screen animations create a more smooth and native experience and provide a visual sense of screen hierarchy
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: PROC#019
Title: T-Minus 100 days to production, or, Janitors Broom Club
Status: Draft
Created: 2017-11-15
Requires (*optional): <Idea number(s)> [TODO: Fill in with critical path swarms]
Release the Status app to production in 100 days, enabling real live users to transact.
We want Status to be live in production as soon as possible. This will be a quantum shift in how we think about the app, as we'll be dealing with real transactions and real users using the app regularly (hopefully). It will be both exhilarating and scary, as reality is the real litmus test for what we are all
working on. This will help guide us in all future endeavours.
In order to get there as soon as possible, we must define a critical path. A critical path is one where if you leave out something then the thing as a whole falls apart. This also means there are a lot of things that are important that we still want to be doing, but they might not be a deal breaker in terms of being live in the App and play store. The purpose of this swarm is to:
(a) outline the critical path so it is crystal clear for everyone
(b) support swarms doing the lion's share of the actual work necessary
(c) do or take responsibility for any miscellaneous janitorial work necessary to get to production in 100 days
TBD. We want people from every department in this one, including lead swarm devs, marketing, community and general support.
There is one main and one auxiliary requirement for this swarm.
In order to fulfill the main requirement we need to figure out the scope and requirements of our production release, but this falls under Goals & Implementation plan.
This implies any work that isn't being done by additional swarms falls under this swarms responsibility.
Before talking about specific goals and implementation plans here, here is an outline for how I personally think about this problem. First, a universal problem: assuming you care about something, it is much easier to not launch and keep adding things than it is to remove things and launch. We must counteract this tendency fiercely.
In order for this goal to be credible, we need to be realistic about what we can do in 100 days. Exactly what do we mean by being in production? To me there are two main hallmarks for saying something is in production:
One worry about pushing for production early with a suboptimal product (onboarding, bad perf, so-so security, confusing UX, bad Whisper scalability, etc) is that we can't push marketing and installs. This means we lose of capability of being top 10 in App store, etc. I believe this reasoning is flawed
for three reasons:
(a) It assumes too much. Scaling more than 2 orders of magnitude is not realistic (~100->10k++) without real-world experience. Additionally we'll hit up on lots of UX and misc quirks just getting an order of magnitude more users than we currently have.
(b) It relies too much on the 'big splash launch' effect and is thus fragile. We launch, things go alright but our retention is bad. Now what? It isn't iterative enough.
(c) It doesn't take into account the possibility of re-launching. We can launch a 'Status Beta' app earlier which has both the hallmarks of being in production and grow users and order of magnitude or two, doing user research etc before doing 'real' launch. If this turns out to be impossible, we can do something similar with Testflight and a much pruned list of only active users.
This would thus create two checkpoint releases. As soon as the first one is out we have real value flowing through the system, as well as real users. This will sharpen our focus even more, and provide valuable lessons for the 'big splash' launch.
Whether we count the Status Beta release as our production release or not is up to this Swarm to determine, in light of what is credible and realistic. The goal here is to not postpone an open and mainnet release several months because we don't have the guts to put Status out there.
Goal Date: 2017-11-24
Description: Decision on whether to proceed with Status Beta approach or not; coarse view of critical path; insight into major things missing from current swarm's work (i.e. a 'Wishlist').
TBD.
Goal Date:
Description:
Y'all.
Copyright and related rights waived via CC0.
Idea: DEV#50
Title: Fix them all
Status: Draft
Created: 2017-11-28
There are bugs that sneak from time to time and just must be fixed. Unfortunately, they are not part of any idea but ruin user experience with the Status app. We need to dedicate some time per week to fix and verify such bugs.
For example: status-im/status-mobile#2426
Any team member can mark any bug for the cleanup, e.g with fix them all
label. Mind the bugs that we can delegate to the community as bounty issues, they will get label bounty-awaiting-approval
!
fix them all
label whenever we think it's not acceptable for the app to behave like this.Goal Date: 2017-12-01
Description: Fix at least 2 bugs from list below
status-im/status-mobile#2426
status-im/status-mobile#2314
Filter to see current open issues with label fix them all
https://github.com/status-im/status-react/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22fix+them+all%22+
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: DEV#008
Title: Fix discoverable statuses
Status: WIP
Created: 2017-11-10
Fix the way discoverable statuses work.
Where we are at the moment:
Where we want to be:
SWARM_COUNT = 3
Currently there is a large mismatch between how statuses should work and how they actually work. This is especially visible if we compare local statuses (without any hashtags) and broadcast statuses (with at least one hashtag). Basically, statuses without hashtags behave like users would expect, but the ones with hashtags behave like a decentralized twitter.
In addition to that there is a number of incorrect or not verified behavior related to status expiration and deletion.
Status discoveries need to comply with the following constraints:
In addition to that, we should enhance the way that statuses are re-broadcast to transitive contacts to include a weight based algorithm that ranks them based on:
Successful implementation of the constraints listed above will result with Discover being in a consistent state where the mismatch between the perception of how it should work and actual implementation largely bridged. That is the must-have list.
Nice to have list contains all the different criteria that may be used in the weighing algorithm.
Nice to haves:
Goal Date: TBD
Description: TBD
Goal Date:
Description: Working MVP
Goal Date:
Description: All constraints fulfilled, basic weighing algorithm working (not all criteria)
Goal Date:
Description: Working weighing algorithm
Copyright and related rights waived via CC0.
Idea: DEV#001
Title: Offline inboxing and persistent messaging
Status: Done
Created: 2017-10-25
Started: 2017-11-14
Ended: 2018-01-04
Make it possible for users to see messages sent to them while they were offline.
No messaging app is complete without persistent messaging. Unlike servers, end users with mobile phones as endpoint go in and out of connectivity. When a user comes back online, the expectation is that they can see messages that was sent while they were gone. How can we solve this without compromising on decentralization and anonymity? There are two basic scenarios we want to solve.
Basic user story A: User A and B are chatting. User A goes offline for a longer period of time. In the meantime, User B sends a message to A and goes offline as well. When User A opens app they see the message from B.
Basic user story B: User A enters public chat room X. User A goes offline and people keep chatting. When User A comes back they instantly see all the missed messages in X.
We want to make it easy to run a Whisper mail server (part of Whisper v5 API). This will archive messages and forward them to a peer upon request. You can run this yourself if you want to, but we’ll also provide default mail servers through our clusters, and make it easy for anyone to set one up. This can be paid using SNT, which aligns incentives in terms of Quality of Service.
Squad size: 5-8 people. Squad channel: #1-offline-inboxing
From a user point of view, anything that solves one or both of the user stories seems like a good start. From a 10 000 feet technical view for the initial version:
RequestHistoricMessages
binding exposed that status-react can callSide note: Exactly what amount of granularity do we want these requirements to be at? And should it be for MVP or for future iterations as well?
Ultimate goal: Decentralized marketplace where people host and connect to wnodes/mailboxes, informed by their reputation, and pay/get compensated with SNT in a fluid fashion. Seamless end user experience in terms of reliability of offline messages showing up when they start the app.
Initial Goal Date: 2017-11-24
Updated Goal Date: 2017-12-08
Completed: 2017-12-08
Passed Full QA: TBD
Description: Run a wnode from the command line; let A send message to B who is offline, and then A goes offline again. When B comes online it should call wnode which should reply with some payload that contains A's message. This payload should be visible in A-B's chat. The wnode can be hardcoded.
Goal Date: 22 December
Started: 2017-11-08 (MVP end) or 2017-11-12 (retro meeting done)
Completed: 2017-12-22 (main user story)
Description: Main user story: User A enters public chat room X. User A goes offline and people keep chatting. When User A comes back they instantly see all the missed messages in X.
Additionally, MVP retainer and laundry: QA of MVP complete and all MVP work merged into develop on status-react and status-go. MVP bug fixing. Basic error handling, refactoring and logging. Documentation for updating wnode-status and API calls introduced. Identify and make bounties of some nice-to-have / upcoming issues. Planning and swarm participants re-organization: likely one more Clojure dev and identify Go dev needs. Clarification on interface (enode). Specify group chat workflow and tests thereof.
Uncertainty: Swarm availability, both w.r.t. other ideas and holidays (seems OK). Availability normal for 2 weeks: Adam 2w 22 Dec, Eugene, Boris, Dmitry, Oskar After Christmas no more Go dev necessary.
Goal Date: TBD - est. +~2w, due to holidays possibly delayed till mid January
State: Aborted
Completed: 2018-01-14 (very partial; read only screen under flag)
Description: Ability to toggle between different wnodes in the app. Show basic connectivity to wnode in interface. The wnodes identifiers are hardcoded in the app. Add by enode (?). Multiple wnodes enabled for redundancy (?).
Uncertainty: Go dev work necessary. Seems docs and options for wnode-status but other than that not. Only on retainer.
Consider how to surface and solve the following challenges in our UI. wnode and mailbox used interchangeably. This list should probably be split into MVP concerns and later concerns as there is quite a lot.
TBD. Smorgasbord of desirable features. Revisit this.
Goal Date:
Description:
TBD.
TBD.
Copyright and related rights waived via CC0.
Idea: Rename sections in bottom navigation of the App
Title: Rename navigation sections
Status: Draft
Created: 2017-11-22
Basically the idea is to change the order of the sections and rename "Chats" to "Tabs" and "Contacts" to "Favourites" to indicate a more generic purpose of those screens.
The idea of changing the order and putting "Tabs" and "Contacts" in the middle seems relevant as these screens are both related to chat, yet "Wallet" and "Discover" are different and it makes sense to put them at the first and last positions respectively.
The words "Tabs" and "Contacts" have been chosen on the basis of being commonly used in browsers which fits well in Status since it's a browser as well.
All resources available for export here zpl://screen?sid=5a1575cef4f55be22789c352&pid=5863cdcee68455850f1929f2
The goal is to decrease confusion for users by using more generic and at the same time representative section names.
After completing this, we can move on to implementing the Omnibar and Chat redesign.
Copyright and related rights waived via CC0.
Idea: DEV#16
Title: Status fiddle (UI online editor)
Status: WIP
Created: 2017-11-14
UI editor in the web (something like fiddle.status.im) for creating status UI in "live" mode, so user can write code for UI and see the result immediately
We're developing UI for status in 3 steps, 1 - designer prepares UI in vector editor and publishes it in Zeplin, 2 - developer implements UI from Zeplin in code, 3 - design review, could take a lot of time and resources for both designers and developers. We can seriously improve this process if designers provide UI in code to developers, but we need a simple way, tools for designers to do that.
Also, if we'll have such a tool, external contributors could develop UI for status without building and running status environment. And chatbot developers could test their bot suggestions UI.
Update1: And we could generate views in different sizes and look how app will look on different devices
Also we could generate views with different labels size to see how it may look with different languages, now we only check English version.
It should be possible to open web page, type hiccup data structures and see resulting UI
And probably tutorials and templates for status UI.
Goal Date: 2018-01-01
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: 37-github-bot
Title: Github Bot
Status: Draft
Created: 2017-11-22
Build a Github bot to automate various tasks and processes on our Github repositories
Github bots are used on repositories such as react-native to automate some tasks that would be too repetetive or cumbersome for a human to do.
As a community manager I want to be able to garantee that external contributors PRs don't get forgotten and get treated within a reasonnable timeframe by the team
As a tester I want to be warned when I have to test migrations in a PR
The bot could mostly be developed via the bounty system in order not to distract the team too much from the critical path of development.
;;;;; template
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: DEV#008
Title: Improve developer experience on status react
Status: Draft
Created: 2017/11/10
Improve developer experience on status react by making necessary refactoring, implementing developer features and supporting clojurescript tooling development.
The current developper experience with status-react has a few rough edges. Our goal is to identify and eliminate them in order to improve the developper experience and get new people onboard more easely.
We shall also improve the clojurescript tools that we are using for status-react to make sure they stay updated and match our expectations.
Making our project more developer-friendly is the best way to get new contributors !
Node is already running
error when connecting to an accountGoal Date: 2017-11-24
Description:
Goal Date: 2017-11-24
Description: Requirement 1 and 4 should be done + as much of 5-10 as possible
Goal Date: 2017-11-01
Description: Requirement 2 should be done + as much of 5-10 as possible
Goal Date: 2017-12-08
Description: Requirement 3 should be done + as much of 5-10 as possible
Copyright and related rights waived via CC0.
Idea: DEV#21
Title: Status and SOB best friends
Status: Draft
Created: 2017-11-16
Status app and SOB Dapp should be closely integrated and be a guide for programmers into new exciting crypto world
As a programmer who is new in crypto world, i want to start work on SOB open bounties and Status should help me to do that easily.
As a potential investor i want to find and fund interesting for me GitHub issues
TBD
TBD
Goal Date:
Description:
TBD
Goal Date:
Description:
TBD
Copyright and related rights waived via CC0.
Idea: DEV#12
Title: Status Desktop (Electron)
Status: WIP
Created: 2017-11-13
Requires #2, #7, #9
Develop Status Desktop application for Mac, Windows, and Linux using Electron (formerly known as Atom Shell, is an open-source framework developed by GitHub)
We are already working on Status Desktop components, implementing React Native components and libraries using Qt technology, but this work requires a lot of resources. Using Electron and React Native Web library we can develop Status Desktop reusing our code base from status-react without a lot of modifications and this work requires only clojure developers resources for code development.
Status Desktop should provide for users all the functionality that is available in the mobile application
Goal Date: 2017-12-12
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: ENS subdomain username registrar
Status: Draft
Created: 2017-11-20
Provide a Registrar for Status users to share their identity easier with their friends.
Sometimes scanning a QRCode in your friend smart phone is not the best, perhaps it would be easier to provide them a URL through ENS. Status would register their domain and upon a fee in SNT register their Identity address to an available subdomain.
Allow the change of address might not needed, as them would be registered against an Identity Contract, that internally can change the manager key.
Goal Date:
Description: Users can register (FIFS) an available username in Status's ENS subdomain
Copyright and related rights waived via CC0.
Idea: DEV#00
Title: DApp catalog
Status: WIP
Created: 2017-11-13
Requires: #8
Add support for discoverable dapps.
Where we are at the moment:
Where we want to be:
TBD
It is recommended that #8 is implemented before this Idea, so that Discover is in a consistent state before we add any new feature.
TBD
Goal Date: TBD
Description: TBD
Goal Date: TBD
Description: Discoverable dapps
Copyright and related rights waived via CC0.
Idea: <to be assigned>
Title: Status Token Registry
Status: Draft
Created: 2014-11-12
Required by: #3
Create a Token Registry owned by SNT holders
Token Registries may get bloated with worthless tokens, leading to high processing in wallet load, to solve this, a Token Registry controlled by SNT holders would be deployed for use in #3 , where the addition of tokens would only happen upon approval of a SNT holders quorum. Any change on the registry should also happen upon SNT holders quorum.
To incentive SNT holders to accept a registry, the registrant can place a bribe to distribute among all yes-voters and Status Network reserve.
Goal Date:
Description:
Goal Date:
Description:
Copyright and related rights waived via CC0.
Idea code: DEV#004
Title: Developers! Developers! Developers!
Status: WIP
Created: 2017-11-09
Towards a better environment for developers
Status provides an ethereum based platform for developers. It must be comprehensive, accessible and complete as much as can be.
This is specifically targeting developer experience.
Bot rely on easy to grasp technologies. My first bot should be testable in 5 minutes.
Bots provide great power and allow developers to tightly integrate in status.
API must cover all cases and have meaningfull semantic. There should be no hole in the paint.
Documentation should detail all available features.
Higher level APIs for common scenario might be considered too (converstations, ..).
It makes sense to test integration with existing ethereum technology to get some hands-on experience (livepeer, trustlines, raiden, favor network).
DApps can be browsed natively in status using web3
object. It makes sense to offer some integration with others status features:
Special care will have to be payed to the security.
status-desktop
offers great potential for an integrated dev environment.
suggestions
previewOnce a bot is developed and tested it must be made available to others. This should be done as much as possible in a decentralized way (swarm).
Identity and versioning might also be considered here.
Scope is very broad and some of the listed scenarios depend on non existing tools (e.g. status-desktop
).
We want to use this umbrella idea to detail mid-term goals and keep them in mind to implement some of the more concrete ones.
Specifically following will be implemented:
status-desktop
dev envUpdated documentation, bot and DApp API.
Goal Date: To be defined
Description: a sound set of dev APIs
Define concrete steps for status-desktop
role and deployment process.
Goal Date: To be defined
Description: a clear plan for the future
Copyright and related rights waived via CC0.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.