├── CNAME ├── .github ├── github-bot.yml └── ISSUE_TEMPLATE.md ├── _data ├── statuses.yaml └── contributors.yaml ├── all.html ├── people.html ├── ideas ├── 314-tribute-to-talk │ ├── mvp-user-a.png │ └── mvp-user-b.png ├── 095-les-service-model │ ├── links.md │ ├── log.md │ └── README.md ├── 369-extensions │ ├── specs.md │ └── research.md ├── 039-group-chat │ ├── roles.md │ ├── glossary.md │ ├── requirements │ │ └── req-1-blocking-menu.md │ ├── user-stories │ │ ├── us-2-reducing-spam.md │ │ ├── us-3-filter-unwanted-content.md │ │ ├── us-1-blocking-a-user.md │ │ ├── us-5-subscribe-to-moderation-providers.md │ │ └── us-4-advanced-filtering-with-smart-contracts.md │ └── README.md ├── 146-status-go-sdk │ ├── PrivateChannels.md │ ├── howto_Sniffing_app_messages.md │ ├── 1to1Channels.md │ ├── PublicChannels.md │ ├── BasicSDK.md │ └── ContactManagement.md ├── 300-core-infra.md ├── 305-core-wallet-account.md ├── 301-core-p2p.md ├── 302-core-mobile-app.md ├── 303-core-desktop.md ├── 912-contribution.md ├── 306-core-browser.md ├── 368-token-economics.md ├── 280-discoverable-trusted-server-nodes │ ├── notes.md │ └── README.md ├── 370-core-ui.md ├── 168-paid-master-nodes │ ├── local-mailserver.md │ └── stt-payment-testing.md ├── 034-react-native-qt │ └── log.md ├── 310-core.md ├── 281-security-process-experiment.md ├── 309-js-protocol-library-webclient.md ├── 293-ulc-integration │ └── README.md ├── 315-core-improvements.md ├── 282-deterministic-builds.md ├── 080-onboarding.md ├── 083-energy-efficient.md ├── 127-SOB-testing-process.md ├── 152-friends-recovery.md ├── 151-ens-usernames.md ├── 275-recyclable-fee.md ├── 386-nim-ewasm.md ├── 279-snt-voting-dapp.md ├── 154-support-web3.js-library.md ├── 254-ultra-light-client │ └── README.md ├── 320-keycard.md ├── 167-extended-automated-testing-for-continuous-delivery │ └── README.md ├── 122-sob-metrics.md ├── 121-swarm-compensation │ ├── models.md │ └── README.md ├── 071-low-traffic.md ├── 312-swarm-janitors.md ├── 225-status-index.md ├── 313-sticker-market │ └── readme.md ├── 322-dao.md ├── 170-wallet-improvements.md ├── 061-app-structure-refinement.md ├── 163-support-erc721.md ├── 120-swarm-process │ ├── permission-less-and-compensated-work.md │ └── town-hall-7-survey-results.md ├── 324-meritocracy.md ├── 090-branch-perf-stats.md ├── 003-erc20-token-support.md ├── 058-mainnet.md ├── 086-push-notif-v2 │ └── 1to1.dot ├── 173-documentation.md ├── 229-hardware-wallet-pro.md ├── 140-sob-improve-onboarding │ └── README.md ├── 088-dapp-experience.md └── 142-wallet-compatibility │ └── README.md ├── .gitignore ├── index.html ├── assets └── main.scss ├── Gemfile ├── TEMPLATE.md ├── _config.yml ├── _includes ├── ideastable.html └── peoplestable.html ├── principles.md └── README.md /CNAME: -------------------------------------------------------------------------------- 1 | ideas.status.im -------------------------------------------------------------------------------- /.github/github-bot.yml: -------------------------------------------------------------------------------- 1 | _extends: probot-settings 2 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | For ideas, please submit a PR with TEMPLATE.md filled in. 2 | -------------------------------------------------------------------------------- /_data/statuses.yaml: -------------------------------------------------------------------------------- 1 | - Draft 2 | - Active 3 | - Limbo 4 | - Completed 5 | - Aborted 6 | -------------------------------------------------------------------------------- /all.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Ideas 4 | --- 5 | 6 | {% include ideastable.html ideas=site.pages %} 7 | -------------------------------------------------------------------------------- /people.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: People 4 | --- 5 | 6 | {% include peoplestable.html ideas=site.pages %} 7 | -------------------------------------------------------------------------------- /ideas/314-tribute-to-talk/mvp-user-a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/status-im/swarms/HEAD/ideas/314-tribute-to-talk/mvp-user-a.png -------------------------------------------------------------------------------- /ideas/314-tribute-to-talk/mvp-user-b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/status-im/swarms/HEAD/ideas/314-tribute-to-talk/mvp-user-b.png -------------------------------------------------------------------------------- /ideas/095-les-service-model/links.md: -------------------------------------------------------------------------------- 1 | ## Links 2 | 3 | - [LES Service Model by Felföldi Zsolt](https://github.com/zsfelfoldi/ethereum-docs/blob/master/les/service_model.md) 4 | 5 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.* 2 | !.github 3 | !.gitignore 4 | !*.md 5 | !*.scss 6 | _site 7 | .sass-cache 8 | .jekyll-metadata 9 | 10 | # allow any files in ideas directories 11 | !ideas/*/* 12 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Home 4 | --- 5 | 6 |

Status Ideas

7 | 8 |

A space for our ideas - our current, past and future efforts.

9 | 10 |

Contributing

11 | 12 | See Github. 13 | -------------------------------------------------------------------------------- /ideas/369-extensions/specs.md: -------------------------------------------------------------------------------- 1 | # Extensions Specifications 2 | 3 | ## MVP 4 | 5 | ### Goal 6 | 7 | ### User Stories 8 | 9 | ### Designs 10 | 11 | ### Measurement & Tracking 12 | **MVP metrics** 13 | 14 | **Future metrics** 15 | 16 | ### Open Questions 17 | 18 | ## Implementation Details 19 | 20 | 21 | ## Future Iterations 22 | -------------------------------------------------------------------------------- /ideas/039-group-chat/roles.md: -------------------------------------------------------------------------------- 1 | # Roles 2 | 3 | | Role | Description | 4 | | ---- | ----------- | 5 | | Owner | Creator and owner of a chat. | 6 | | Moderator | User with rights to moderate a chat. | 7 | | User | Chat user without special rights. | 8 | | Power User | Chat user without special rights but ability to develop smart contracts. | 9 | | Contract Developer | Developer of contracts especially for chats. | 10 | | Contract Provider | Provider of contracts especially for chats. | 11 | -------------------------------------------------------------------------------- /ideas/146-status-go-sdk/PrivateChannels.md: -------------------------------------------------------------------------------- 1 | ## Private channels 2 | 3 | Interacting with private channels is complex than public channels as 4 | 5 | 6 | ### Ability to publish messages on private groups 7 | **[ TBD ]** 8 | 9 | ### Ability to subscribe to private groups 10 | **[ TBD ]** 11 | 12 | ### Ability to unsubscribe from a private groups 13 | **[ TBD ]** 14 | 15 | ### Documented API for private groups 16 | **[ TBD ]** 17 | 18 | ### Working examples for private groups interaction 19 | **[ TBD ]** 20 | -------------------------------------------------------------------------------- /ideas/039-group-chat/glossary.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | | Term | Meaning | 4 | | ---- | ------- | 5 | | Chat | Textual communication between two users. | 6 | | Chat Room | Grouping of users chatting about a topic or having any other kind of relation. Opposite to bilateral chats. Chat rooms have one owner and possible multiple moderators. | 7 | | Public Group Chat | Chat room without restrictions for users to join. Opposite to private chat rooms needing an invitation by the owner or a moderator. | 8 | | SNT Burn Rate | ??? | 9 | -------------------------------------------------------------------------------- /ideas/300-core-infra.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 300-core-infra 3 | title: Core Infra Team 4 | status: Active 5 | created: 2018-05-01 6 | category: core 7 | lead-contributor: jakubgs 8 | contributors: 9 | - jakubgs 10 | - adambabik 11 | - corey 12 | exit-criteria: no 13 | success-metrics: no 14 | clear-roles: yes 15 | future-iterations: no 16 | roles-needed: 17 | --- 18 | 19 | This should probably be filled out similar to Ideas template, but this will do as a skeleton. 20 | 21 | The Core Infra team is an infrastructure team that supports and enables other 22 | client teams (mobile, desktop) as well as product teams (chat, wallet, dapp). It is a sibling to the p2p team. 23 | 24 | Current state of it is: ... 25 | -------------------------------------------------------------------------------- /ideas/305-core-wallet-account.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 305-core-wallet 3 | title: Core Wallet and Account Team 4 | status: Active 5 | created: 2018-05-01 6 | category: core 7 | lead-contributor: goranjovic 8 | contributors: 9 | - chadyj 10 | - goranjovic 11 | exit-criteria: no 12 | success-metrics: no 13 | clear-roles: yes 14 | future-iterations: no 15 | roles-needed: 16 | --- 17 | 18 | This should probably be filled out similar to Ideas template, but this will do as a skeleton. 19 | 20 | The Core Wallet and Account team is a product team that is focused on the wallet and account experience of Status. It gets support and is enabled by the Mobile App team as well as Infra and P2P team. 21 | 22 | Current state of it is: .... 23 | -------------------------------------------------------------------------------- /_data/contributors.yaml: -------------------------------------------------------------------------------- 1 | - 3esmit 2 | - annadanchenko 3 | - adambabik 4 | - adriacidre 5 | - alexvandesande 6 | - alwx 7 | - andmironov 8 | - antdanchenko 9 | - arash009 10 | - asemiankevich 11 | - cammellos 12 | - carlbennetts 13 | - chadyj 14 | - churik 15 | - denis-sharypin 16 | - dmitryn 17 | - dshulyak 18 | - EugeOrtiz 19 | - flexsurfer 20 | - hesterbruikman 21 | - iurimatias 22 | - janherich 23 | - jason 24 | - jarradh 25 | - jeluard 26 | - jpbowen 27 | - lukaszfryc 28 | - mandrigin 29 | - martinklepsch 30 | - MaxRis 31 | - naghdy 32 | - nastya 33 | - nikitalukianov 34 | - oskarth 35 | - pilu 36 | - PombeirP 37 | - rasom 38 | - rachelhamlin 39 | - richard-ramos 40 | - rcullito 41 | - serhy 42 | - themue 43 | - vkjr 44 | - yenda 45 | - yevh-berdnyk 46 | -------------------------------------------------------------------------------- /ideas/301-core-p2p.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 301-core-p2p-team 3 | title: Core P2P Team 4 | status: Active 5 | created: 2018-05-01 6 | category: core 7 | lead-contributor: adambabik 8 | contributors: 9 | - adambabik 10 | - dshulyak 11 | - divan 12 | exit-criteria: no 13 | success-metrics: no 14 | clear-roles: yes 15 | future-iterations: no 16 | roles-needed: 17 | --- 18 | 19 | This should probably be filled out similar to Ideas template, but this will do as a skeleton. 20 | 21 | The P2P team is an infrastructure team that is focused on the P2P layer of Status. It supports and enables client teams such as mobile app and desktop app, as well as product teams such as chat, dapps and wallet. 22 | 23 | They currently share chat home with core-infra. 24 | 25 | Current state of it is: ... 26 | -------------------------------------------------------------------------------- /ideas/302-core-mobile-app.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 302-core-mobile-app-team 3 | title: Core Mobile App Team 4 | status: Active 5 | created: 2018-05-01 6 | category: core 7 | lead-contributor: mandrigin 8 | contributors: 9 | - chadyj 10 | - mandrigin 11 | - rasom 12 | - alwx 13 | - janherich 14 | exit-criteria: no 15 | success-metrics: no 16 | clear-roles: yes 17 | future-iterations: no 18 | roles-needed: 19 | --- 20 | 21 | This should probably be filled out similar to Ideas template, but this will do as a skeleton. 22 | 23 | The Mobile App team is a client team that is focused on the mobile app client of 24 | Status. It gets support and is enabled by the Infra and P2P team, and it 25 | supports product teams Chat, Dapp, and Wallet. 26 | 27 | Current state of it is regular releases, as well as ... 28 | -------------------------------------------------------------------------------- /ideas/303-core-desktop.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 303-core-desktop 3 | title: Core Desktop Team 4 | status: Active 5 | created: 2018-05-01 6 | category: core 7 | lead-contributor: vitaliy 8 | contributors: 9 | - chadyj 10 | - vitaliy 11 | - maxris 12 | - volodymyr 13 | - gnl 14 | exit-criteria: no 15 | success-metrics: no 16 | clear-roles: yes 17 | future-iterations: no 18 | roles-needed: 19 | --- 20 | 21 | This should probably be filled out similar to Ideas template, but this will do as a skeleton. 22 | 23 | The Core Desktop team is a client team that is focused on the Desktop client of Status. It gets support and is enabled by the Infra and P2P team, and it supports the product teams chat, wallet, and dapps. 24 | 25 | Current state of it is focused on getting everyone to use Status everyday at their desktop. 26 | -------------------------------------------------------------------------------- /assets/main.scss: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | @import "minima"; 5 | 6 | @media screen and (max-width: 600px) { 7 | table { 8 | border: 0; 9 | } 10 | 11 | table caption { 12 | font-size: 1.3em; 13 | } 14 | 15 | table thead { 16 | border: none; 17 | clip: rect(0 0 0 0); 18 | height: 1px; 19 | margin: -1px; 20 | overflow: hidden; 21 | padding: 0; 22 | position: absolute; 23 | width: 1px; 24 | } 25 | 26 | table tr { 27 | border-bottom: 3px solid #ddd; 28 | display: block; 29 | margin-bottom: .625em; 30 | } 31 | 32 | table td { 33 | border-bottom: 1px solid #ddd; 34 | display: block; 35 | font-size: .9em; 36 | font-weight: bold; 37 | text-align: right; 38 | } 39 | 40 | table td::before { 41 | content: attr(data-label); 42 | float: left; 43 | font-weight: lighter; 44 | font-size: 0.7em; 45 | text-transform: uppercase; 46 | } 47 | 48 | table td:last-child { 49 | border-bottom: 0; 50 | } 51 | } -------------------------------------------------------------------------------- /ideas/146-status-go-sdk/howto_Sniffing_app_messages.md: -------------------------------------------------------------------------------- 1 | ## HOWTO : Sniffing app messages 2 | 3 | So one of the main points of this swarm is to interact with status app, to do that, we need to speak its same language. 4 | 5 | To do that the easiest way is to sniff messages sent by the app, to do this you can: 6 | 7 | 1.- Clone status-react 8 | 2.- Add a log line on [StatusModule.java::sendWeb3Request method](https://github.com/status-im/status-react/blob/develop/modules/react-native-status/android/src/main/java/im/status/ethereum/module/StatusModule.java#L690) printing the payload like: 9 | 10 | ``` 11 | Thread thread = new Thread() { 12 | @Override 13 | public void run() { 14 | + Log.d("PAYLOAD", "PAYLOAD : " + payload); 15 | + 16 | String res = Statusgo.CallRPC(payload); 17 | callback.invoke(res); 18 | } 19 | ``` 20 | 3.- [Deploy it to your devide/emulator](https://wiki.status.im/Building_Status) 21 | 4.- Connect to your emulator and check the logs `adb logcat|grep "PAYLOAD"` 22 | -------------------------------------------------------------------------------- /ideas/039-group-chat/requirements/req-1-blocking-menu.md: -------------------------------------------------------------------------------- 1 | # Requirement 1: Blocking Menu 2 | 3 | ## User Stories 4 | 5 | - [1: Blocking a User](https://github.com/status-im/ideas/blob/progress/39-init-reqeng/active/039-chat-moderation/user-stories/us-1-blocking-a-user.md) 6 | 7 | ## Description 8 | 9 | The context menu for all participants of a chat must contain a blocking menu point. 10 | 11 | ## Rationale 12 | 13 | Selecting this menu point by *User A* for a *User B* leads to the blocking of the 14 | selected user for all feeds of *User A*. 15 | 16 | ## Fit Criteria 17 | 18 | - Selecting this menu point leads to a security question. 19 | - Confirming the menu point leads to a blinding out of all messages of 20 | *User B* in all common feeds of *User A*. 21 | 22 | ## Dependencies 23 | 24 | None. 25 | 26 | ## Conflicts 27 | 28 | None. 29 | 30 | ## Links 31 | 32 | None. 33 | 34 | ## Remarks 35 | 36 | - Question: Does the list of chat members also shows the own profile? Here the 37 | context menu must contain no blocking menu point. -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | # Hello! This is where you manage which Jekyll version is used to run. 4 | # When you want to use a different version, change it below, save the 5 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 6 | # 7 | # bundle exec jekyll serve 8 | # 9 | # This will help ensure the proper Jekyll version is running. 10 | # Happy Jekylling! 11 | gem "jekyll", "~> 3.7.3" 12 | 13 | # This is the default theme for new Jekyll sites. You may change this to anything you like. 14 | gem "minima", "~> 2.0" 15 | 16 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and 17 | # uncomment the line below. To upgrade, run `bundle update github-pages`. 18 | # gem "github-pages", group: :jekyll_plugins 19 | 20 | # If you have any plugins, put them here! 21 | group :jekyll_plugins do 22 | gem "jekyll-feed", "~> 0.6" 23 | end 24 | 25 | # Windows does not include zoneinfo files, so bundle the tzinfo-data gem 26 | gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby] 27 | 28 | # Performance-booster for watching directories on Windows 29 | gem "wdm", "~> 0.1.0" if Gem.win_platform? 30 | 31 | -------------------------------------------------------------------------------- /ideas/095-les-service-model/log.md: -------------------------------------------------------------------------------- 1 | ## Logfile 2 | 3 | ### 2018-05-09 4 | 5 | - Separated ULC into own swarm 6 | - Renamed back into #095-les-service-model 7 | - Set to draft for new priority setting for ULC 8 | 9 | ### 2018-04-26 10 | 11 | - ULC has higher priority to become independend of Infura asap 12 | - Swarm has been renamed to #095-les-improvement 13 | - MVP is now ULC integration 14 | - Iteration 1 is initial development of LES service model 15 | 16 | ### 2018-04-12 17 | 18 | - Exchange about observer chain/chain filters and sharding 19 | - Discussion about how observer chain/chain filter possibly gut address scaling problems 20 | - Exchange about different micropayment approaches 21 | - Start drafting a common pluggable API for different micropayment solutions for integration 22 | into the LES Service Model 23 | 24 | ### 2018-04-09 25 | 26 | - Zsolt tries to finish the technical documents and the outline of building blocks this week 27 | - Eugene starts to test ULC on real devices 28 | - Frank compares existing micropayment APIs to create a common interface used inside LES 29 | 30 | ### 2018-04-06 31 | 32 | - Moved single idea file into swarm directory 33 | - Added logfile 34 | -------------------------------------------------------------------------------- /ideas/146-status-go-sdk/1to1Channels.md: -------------------------------------------------------------------------------- 1 | ## 1 to 1 messages 2 | 3 | 4 | The ssh_post message on 1 to 1 chats looks like: 5 | ``` 6 | {"jsonrpc":"2.0","id":3146,"method":"shh_post","params":[{"sig":"0x046f29b16371c05880c3da0279c7b8f958f97be79e00ca2a8f9e951eb254ccf8ead793af564a66c952668ad9e6e8f6dac5773bd1087d87273ebcece8da03420085","symKeyID":"7aee3646de46c5b175e5ff7cc16ebe1c4488844700f241fb36a2bc0829cea25d","payload":"0x5b227e236334222c5b2270757475222c22746578742f706c61696e222c227e3a757365722d6d657373616765222c3135323336313837323338323330312c313532333631383732333832315d5d","topic":"0xd977be6d","ttl":10,"powTarget":0.001,"powTime":1}]} 7 | ``` 8 | 9 | And its decrypted message is: 10 | ``` 11 | ["~#c4",["hello world","text/plain","~:user-message",152361872382301,1523618723821]] 12 | ``` 13 | 14 | Basically the only difference between 1to1 and public is the field message type which in this case is set to `~:user-message`.s 15 | 16 | 17 | 18 | ### Ability to send 1 to 1 conversation 19 | 20 | 21 | 22 | ### Ability to subscribe to 1 to 1 conversation 23 | ### Ability to unsubscribe from a 1 to 1 conversation 24 | ### Documented API for 1 to 1 conversations 25 | ### Working examples for 1 to 1 conversations 26 | -------------------------------------------------------------------------------- /ideas/039-group-chat/user-stories/us-2-reducing-spam.md: -------------------------------------------------------------------------------- 1 | # User Story 2: Reducing SPAM 2 | 3 | ## Description 4 | 5 | *User A* enters a public group chat. *User A* discovers that messages in the chat 6 | feed are low quality (SPAM). *User A* adjusts the required SNT burn value until the 7 | quality of the chat feed improves. 8 | 9 | ## Trigger 10 | 11 | Wish of *User A* to reduce SPAM in a public group chat. 12 | 13 | ## Actors 14 | 15 | - *User A* 16 | 17 | ## Pre-Condition 18 | 19 | A public chat room with traffic and *User A* as a user. Quality of the feed 20 | is too low for *User A*. 21 | 22 | ## Post-Condition 23 | 24 | After adjustment of the required SNT burn value the amount of SPAM reduces. 25 | 26 | ## Flow 27 | 28 | - *User A* enters a public chat room and discovers the low feed quality. 29 | - *User A* selects his settings for the chat room and changes the SNT burn rate. 30 | - After changing the burn rate the amount of SPAM varies. 31 | 32 | ## Remarks 33 | 34 | - Question: Do chat rooms have a standard burn rate? 35 | - Question: Do chat rooms have upper or lower limits for burn rate? 36 | - Question: How does the SNT burn rate of *User A* influences the delivery 37 | of low or high quality messages? 38 | - Question: Can a sender influence what it's worth to her having a message 39 | delivered? 40 | -------------------------------------------------------------------------------- /ideas/912-contribution.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | | id | title | status |lead-contributor |contributors |budget | 4 | |--- |--- |--- |--- |--- |--- | 5 | | | Contribution | Research | | | | 6 | 7 | 8 | # Swarm proposal 9 | 10 | ## Summary and Goal(s) 11 | Oversea the acquisition of new contributors to Status. Build strategies and processes that allow the easy onboarding of new contributors. 12 | ## Communication 13 | `status channel (same as swarm id)`: [#912-contribution](https://get.status.im/chat/public/912-contribution) 14 | `sync frequency`: 15 | 16 | ## Research 17 | (required) 18 | `timebox research (approx)` 19 | 20 | ## Specification 21 | 22 | > do after `Research` 23 | 24 | (required) 25 | `timebox specification (approx)` 26 | 27 | (optional) 28 | `user stories`, `architecture`, `designs`, `PoC` 29 | 30 | ## Implementation 31 | 32 | (required) 33 | `timebox implementation (approx)` 34 | 35 | > do after `Specification` 36 | 37 | > All swarm contributors should test and break the implementation, especially developers 38 | 39 | (required) 40 | `document progress` 41 | 42 | (optional) 43 | `townhall demo` 44 | 45 | ## Maintenance 46 | 47 | `lead-contributor`,`post-mortems` 48 | 49 | ## Copyright 50 | 51 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 52 | -------------------------------------------------------------------------------- /TEMPLATE.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #000-template 3 | title: Swarm Proposal 4 | status: research/specification/implementation/maintenance 5 | lead-contributor: 6 | contributors: 7 | - 8 | - 9 | budget: 10 | - actual: xxx 11 | - estimate: yyy 12 | - currency: ETH/USD/SNT 13 | --- 14 | 15 | # Swarm proposal 16 | 17 | ## Summary and Goal(s) 18 | 19 | ## Communication 20 | (required) 21 | `status channel (same as swarm id)`: [#000-foobar](https://get.status.im/chat/public/000-foobar) 22 | `sync frequency`: Weekly Sync 23 | 24 | ## Research 25 | (required) 26 | `timebox research (approx)` 27 | 28 | (optional) 29 | `eips`, `competitors`, `existing research`, `wireframes`, `spike (PoC)` 30 | 31 | ## Specification 32 | 33 | > do after `Research` 34 | 35 | (required) 36 | `timebox specification (approx)` 37 | 38 | (optional) 39 | `user stories`, `architecture`, `designs`, `PoC` 40 | 41 | ## Implementation 42 | 43 | (required) 44 | `timebox implementation (approx)` 45 | 46 | > do after `Specification` 47 | 48 | > All swarm contributors should test and break the implementation, especially developers 49 | 50 | (required) 51 | `document progress` 52 | 53 | (optional) 54 | `townhall demo` 55 | 56 | ## Maintenance 57 | 58 | `lead-contributor`,`post-mortems` 59 | 60 | ## Copyright 61 | 62 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 63 | -------------------------------------------------------------------------------- /ideas/039-group-chat/user-stories/us-3-filter-unwanted-content.md: -------------------------------------------------------------------------------- 1 | # User Story 3: Filter unwanted Content 2 | 3 | ## Description 4 | 5 | *User A* does not want to view any messages that contain the phrase x. *User A* 6 | updates their moderation rules to ignore any messages that contain the phrase x. 7 | Messages that contain the phrase x no longer appear in any chat feeds of *User A*. 8 | 9 | ## Trigger 10 | 11 | Feeds of *User A* contain a phrase the user doesn't want to see. 12 | 13 | ## Actors 14 | 15 | - *User A* 16 | - *User B* 17 | 18 | ## Pre-Condition 19 | 20 | The disliked phrase is not inside the already added phrases of *User A*. 21 | 22 | ## Post-Condition 23 | 24 | After adding a phrase to ignore no more messages containing this phrase are 25 | in the feed of *User A*. 26 | 27 | ## Flow 28 | 29 | - *User A* discovers unwanted phrase. 30 | - *User A* decides to filter this phrase out. 31 | - *User A* opens a (global|chat room) menu and selects the menu point 32 | for filtering. 33 | - *User A* adds a phrase to filter. 34 | 35 | ## Remarks 36 | 37 | - Question: Does a phrase ban of a user effects only one chat room or all 38 | chats of *User A*? 39 | - Question: Does the *User A* get a kind of notification of an unwanted phrase 40 | by *User B*, e.g. to allow her to react on it? 41 | - Question: Which options for filters? Exact match, full words, wildcards, 42 | regular expressions? 43 | - Todo: Add user stories for the changing and the removal of filter phrases. 44 | -------------------------------------------------------------------------------- /ideas/039-group-chat/user-stories/us-1-blocking-a-user.md: -------------------------------------------------------------------------------- 1 | # User Story 1: Blocking a User 2 | 3 | ## Description 4 | 5 | *User A* enters a public group chat. *User B* sends a message that *User A* dislikes. *User A* 6 | blocks *User B*. All messages from *User B* no longer show up in any chat feeds of *User A*. 7 | 8 | ## Trigger 9 | 10 | Any reason *User A* doesn't want to see posts of *User B* anymore. 11 | 12 | ## Actors 13 | 14 | - *User A* 15 | - *User B* 16 | - *User C* 17 | 18 | ## Pre-Condition 19 | 20 | In a chat room with *User A*, *User B*, and possible more more *User A* can read all 21 | messages of *User B*. 22 | 23 | ## Post-Condition 24 | 25 | The same chat room with the same visitors, but *User A* doesn't see any post of *User B*. 26 | Also in other chat rooms with both users *User A* doesn't see any post of *User B*. 27 | 28 | ## Flow 29 | 30 | - *User A* selects account of *User B*. 31 | - Menu with multiple options is display, one of those is `Block ...`. 32 | - After selecting `Block ...` and confirming a security question posts of *User B* aren't 33 | visible anymore to *User A*. 34 | 35 | ## Remarks 36 | 37 | - Question: How to remove this blocking? Is *User B* still visible in the list of chat 38 | participants and can be selected to open a menu like for blocking? Or does the chat 39 | room menu an option to list all blocked users and those can be unblocked there? 40 | - Question: How is quoting, mentioning, or forwarding of *User B* messages by *User C* 41 | handled? Are those visible to *User A*? 42 | -------------------------------------------------------------------------------- /ideas/306-core-browser.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #306-core-browser 3 | title: Core Browser 4 | status: implementation 5 | lead-contributor: Julien 6 | contributors: 7 | - Julien 8 | - Andrey 9 | - Nastya 10 | - Maciej 11 | - Rachel 12 | budget: 13 | - actual: xxx 14 | - estimate: yyy 15 | - currency: ETH 16 | --- 17 | 18 | Browser Swarm Proposal 19 | = 20 | 21 | ## Summary and Goals 22 | 23 | The Core Browser team is going to be primarily responsible in Q12019 for building the P0 SNT Utility feature Stickers market. 24 | 25 | This swarm is also responsbile for maintaining and improving the overall browser experience. 26 | 27 | Any capacity leftover from Stickers market tasks will be dedicated to essential browser features or fixes. 28 | 29 | ## Contributors 30 | 31 | - Julien 32 | - Andrey 33 | - Nastya 34 | - Maciej 35 | - Rachel 36 | 37 | (+ Janitor swarm) 38 | 39 | ## Communication 40 | 41 | `Status channel`: #status-core-dapps 42 | `Sync schedule`: currently twice weekly 43 | `Meeting notes`: Description :https://notes.status.im/wyjNCxeURu6lYSwWGh3biw 44 | `Pivotal link`: https://www.pivotaltracker.com/projects/2231918 45 | 46 | ## Research 47 | 48 | `Timebox`: Complete by 21/12/18 49 | 50 | `Objective`: Define high priority items for browser, outside of Stickers market and independent of current board. 51 | 52 | Notes are available [here](https://notes.status.im/browser-research) 53 | 54 | ## Specification 55 | 56 | ## Implementation 57 | 58 | ## Maintenance 59 | 60 | ## Copyright 61 | 62 | Copyright and related rights waived via CC0. 63 | -------------------------------------------------------------------------------- /ideas/039-group-chat/user-stories/us-5-subscribe-to-moderation-providers.md: -------------------------------------------------------------------------------- 1 | # User Story 5: Subscribe to Moderation Providers 2 | 3 | ## Description 4 | 5 | *User A* discovers a bad quality of her feed regarding advertisement and 6 | unwanted phrases. She heard about *Moderator A* providing a service for 7 | better feed quality. She subscribes to *Muderator A* and her feed improves 8 | by the rules of the moderator. 9 | 10 | ## Trigger 11 | 12 | *User A* wants an improvement of her feed quality. 13 | 14 | ## Actors 15 | 16 | - *User A* 17 | - *Moderator A* 18 | 19 | ## Pre-Condition 20 | 21 | The feed of *User A* is unfiltered, filtered by own rules or filtered 22 | by rules of other moderators. 23 | 24 | ## Post-Condition 25 | 26 | The feed of *User A* is filtered like before plus by the rules of 27 | *Moderator A*. 28 | 29 | ## Flow 30 | 31 | - *User A* opens a global menu and selects the menu point for subbscribing 32 | to moderators. 33 | - A dialog containing list of all so far subscribed moderators plus a field 34 | for entering a new one appears. 35 | - *User A* enters the address of *Moderator A*. 36 | - The address will be added to the moderator list of *User A*. 37 | 38 | ## Remarks 39 | 40 | - Question: Are filters here and in the other user stories only subtractive 41 | or can they also be a kind of valuing (+/- value)? So I can say the phrase 42 | "Status" is for me +5 opposite to a moderators -2. This way I can create 43 | some adjustment. 44 | - Discussion: Does the order of subscribed moderators influence the result? 45 | - Todo: Add user stories for the manipulation of the moderator list. -------------------------------------------------------------------------------- /ideas/146-status-go-sdk/PublicChannels.md: -------------------------------------------------------------------------------- 1 | ## Public channels 2 | 3 | Public channels interaction is about how the developer will be interacting with public channels. 4 | 5 | ### Ability to join public channels 6 | 7 | A new public channel will be joined using Join method: 8 | ``` 9 | ch, err := conn.Join("my_channel") 10 | if err != nil { 11 | panic("Couldn't join my_channel") 12 | } 13 | ``` 14 | 15 | ### Ability to publish messages on public channels 16 | You can use the Channel object to publish messages on it as follows: 17 | ``` 18 | ch, _ := conn.Join("my_channel") 19 | ch.Publish("Hello world") 20 | ``` 21 | 22 | ### Ability to subscribe to public channels 23 | Subscribing a channel means a script will be able to listen to any messages on a specific public channel. This can be achieved with Channel Subscribe method as follows: 24 | ``` 25 | ch, _ := conn.Join("my_channel") 26 | ch.Subscribe(func(m *sdk.Msg) { 27 | log.Println("Message from ", m.From, " with body: ", m.Text) 28 | } 29 | ``` 30 | 31 | ### Ability to unsubscribe from a public channel 32 | In order to unsubscribe from a specific public channel you just have to call Unsubscribe method. 33 | ``` 34 | ch, _ := conn.Join("my_channel") 35 | ch.Subscribe(func(m *sdk.Msg) { 36 | if m.Text == "BYE!" { 37 | ch.Unsubscribe() 38 | } 39 | } 40 | ``` 41 | 42 | 43 | ### Documented API for public channels interaction 44 | 45 | This document can be adapted as a documentation for public channels interaction 46 | 47 | 48 | ### Working examples for public channel interaction 49 | 50 | Actually [here](https://github.com/status-im/status-go/blob/sdk/sdk/examples/) you'll find an example of a "ping pong game". 51 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | # Welcome to Jekyll! 2 | # 3 | # This config file is meant for settings that affect your whole blog, values 4 | # which you are expected to set up once and rarely edit after that. If you find 5 | # yourself editing this file very often, consider using Jekyll's data files 6 | # feature for the data you need to update frequently. 7 | # 8 | # For technical reasons, this file is *NOT* reloaded automatically when you use 9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process. 10 | 11 | # Site settings 12 | # These are used to personalize your new site. If you look in the HTML files, 13 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. 14 | # You can create any custom variable you would like, and they will be accessible 15 | # in the templates via {{ site.myvariable }}. 16 | title: Status - Ideas 17 | email: support@status.im 18 | description: >- # this means to ignore newlines until "baseurl:" 19 | Swarm Home. New, completed and in-progress features for Status. 20 | twitter_username: ethstatus 21 | github_username: status-im 22 | header_pages: 23 | - all.html 24 | - people.html 25 | - core.html 26 | - sob.html 27 | - research.html 28 | - meta.html 29 | 30 | # Build settings 31 | markdown: kramdown 32 | theme: minima 33 | plugins: 34 | - jekyll-feed 35 | 36 | permalink: /:slug 37 | 38 | # Exclude from processing. 39 | # The following items will not be processed, by default. Create a custom list 40 | # to override the default setting. 41 | # exclude: 42 | # - Gemfile 43 | # - Gemfile.lock 44 | # - node_modules 45 | # - vendor/bundle/ 46 | # - vendor/cache/ 47 | # - vendor/gems/ 48 | # - vendor/ruby/ 49 | -------------------------------------------------------------------------------- /ideas/039-group-chat/user-stories/us-4-advanced-filtering-with-smart-contracts.md: -------------------------------------------------------------------------------- 1 | # User Story 4: Advanced Filtering with Smart Contracts 2 | 3 | ## Description 4 | 5 | *User A* is a power user. *User A* configures her moderation rules to include 6 | the address of a smart contract that implements a standard rules interface. 7 | The smart contract will be called to evaluate new messages as they are received. 8 | 9 | ## Trigger 10 | 11 | *User A* want non-standard actions to be performed for each received message. 12 | 13 | ## Actors 14 | 15 | - *User A* 16 | 17 | ## Pre-Condition 18 | 19 | The actions perfomed on arriving messages do not contain the wanted action. 20 | 21 | ## Post-Condition 22 | 23 | After adding the address of a smart contract implementing the standard rule 24 | interface this contract will be called for each received message. 25 | 26 | ## Flow 27 | 28 | - *User A* opens a (global|chat room) menu and selects the menu point 29 | for adding smart contracts. 30 | - After entering the address of a smart contract and confirming the 31 | adding the smart contract will be checked for implementing the standard 32 | rule interface. 33 | - In case of a valid implementation the smart contract will be added. 34 | 35 | ## Remarks 36 | 37 | - Question: Is the only one global list for all messages or also individual 38 | lists per chat room? 39 | - Question: Only one contract (global or per chat room) or multiple ones? 40 | - Question: In case of multiple contracts, can the order of their execution 41 | be defined? 42 | - Question: Can contracts filter messages or send new messages? And the latter 43 | to *User A* or also to other users? 44 | - Todo: Add user stories for the manipulation of the contract set. -------------------------------------------------------------------------------- /ideas/368-token-economics.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #368-token-economics 3 | title: Token Economics 4 | status: research 5 | lead-contributor: corey 6 | contributors: 7 | - carl 8 | - barry 9 | - jarrad 10 | - nabil 11 | - ben 12 | budget: 13 | - actual: xxx 14 | - estimate: yyy 15 | - currency: ETH/USD/SNT 16 | --- 17 | 18 | # Swarm proposal 19 | 20 | ## Summary and Goal(s) 21 | This swarm is responsible for: 22 | - Model the Status Network token economy based on current SNT use-cases 23 | - Explore and consult on new areas for SNT Utility 24 | - Communicate the value of SNT to retail and institutional investors 25 | 26 | ## Communication 27 | (required) 28 | `status channel (same as swarm id)`: [#368-token-economics](https://get.status.im/chat/public/368-token-economics) 29 | `sync frequency`: Weekly Sync 30 | 31 | ## Research 32 | Completion by end of March, 2019 33 | 34 | Barry has already made several models here: 35 | https://beta.observablehq.com/@bgits 36 | 37 | And we have started collecting some empirical growth data. 38 | 39 | ## Specification 40 | 41 | > do after `Research` 42 | 43 | (required) 44 | `timebox specification (approx)` 45 | 46 | (optional) 47 | `user stories`, `architecture`, `designs`, `PoC` 48 | 49 | ## Implementation 50 | 51 | (required) 52 | `timebox implementation (approx)` 53 | 54 | > do after `Specification` 55 | 56 | > All swarm contributors should test and break the implementation, especially developers 57 | 58 | (required) 59 | `document progress` 60 | 61 | (optional) 62 | `townhall demo` 63 | 64 | ## Maintenance 65 | 66 | `lead-contributor`,`post-mortems` 67 | 68 | ## Copyright 69 | 70 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 71 | -------------------------------------------------------------------------------- /_includes/ideastable.html: -------------------------------------------------------------------------------- 1 | {% for status in site.data.statuses %} 2 | {% assign ideas = (include.ideas | where:"status", status) | sort: 'id' %} 3 | {% assign count = ideas|size %} 4 | {% if count > 0 %} 5 |

{{status}}

6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | {% for page in ideas %} 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | {% endfor %} 31 |
Lead ContributorIdeaTitleCategorySuccess metrics?Exit criteria?Clear roles?Future iterations?
{{page.lead-contributor|xml_escape}}{{page.id|xml_escape}}{{page.title|xml_escape}}{{page.category|xml_escape}}{% if page.success-metrics %}✅ {% else %}❌{% endif %}{% if page.exit-criteria %}✅{% else %}❌{% endif %}{% if page.clear-roles %}✅{% else %}❌{% endif %}{% if page.future-iterations %}✅{% else %}❌{% endif %}
32 | {% endif %} 33 | {% endfor %} 34 | 35 | -------------------------------------------------------------------------------- /ideas/280-discoverable-trusted-server-nodes/notes.md: -------------------------------------------------------------------------------- 1 | Discoverable And Trusted Server Nodes 2 | ===================================== 3 | 4 | ## Proposed Workflow 5 | 6 | 1. Mail Server registers itself with a topic `mailserver` in Discovery V5 pool, 7 | 1. A client subscribes to Discovery V5 for peers registered with `mailserver` topic, 8 | 1. A client verifies that a found Mail Server is trusted using a smart contract, 9 | 1.1. If so, the selected Mail Server is cached and used to retrieve historic messages, 10 | 1.2. Otherwise, it's discarded and the client waits for new candidates. 11 | 12 | ### What does happen when a previously trusted Mail Server is not trusted anymore? 13 | 14 | (when a previously trusted Mail Server got removed from the smart contract registry) 15 | 16 | We can use smart contract events to observe that in order not to check if a given Mail Server is trusted whenever the historic messages are requested ([discussion](https://github.com/status-im/ideas/pull/280/files?utf8=%E2%9C%93&diff=unified#r194015066)). 17 | 18 | ## Token-Curated Registries 19 | 20 | [Detailed Specification](https://docs.google.com/document/d/1BWWC__-Kmso9b7yCI_R7ysoGFIT9D_sfjH3axQsmB6E) 21 | 22 | This concept overlaps in many aspects with the smart contract that is needed to be designed for this swarm. TCRs can be used as a solution or inspiration to design the smart contract. 23 | 24 | ## Q&A 25 | 26 | ### Q: What consistency level do Mail Servers provide? 27 | 28 | Each Mail Server is independent and stores its own log of historic messages. It means there is no sync between them and the consistency is not maintained or even verified. In particular: 29 | - stored messages might be in a different order on each Mail Server, 30 | - if a given Mail Server was down for longer than TTL of some messages, those messages could be lost on a given server. 31 | -------------------------------------------------------------------------------- /ideas/370-core-ui.md: -------------------------------------------------------------------------------- 1 | # Core-UI 2 | 3 | ## Q2 critical path 4 | 5 | **SNT utility features** 6 | 7 | SNT utility features take priority over new items. 8 | 9 | _Sticker Market:_ ToB audit kicked off 26/4. Estimated time for completion is 1-2 weeks. Feature launch date dependent upon issues found. 10 | 11 | _TtT:_ [Two remaining issues](https://github.com/status-im/status-react/issues?q=is%3Aissue+is%3Aopen+label%3Atribute-to-talk) being bountied; Eric/Vitaliy fixing issues found in QA on core flows. ToB will audit after stickers. Same procedure as stickers, but the feature will require two release cycles to go public. One to introduce it settings option behind a flag and chat flow introduced; the second with both. This is to ensure that users who don't update from client n-1 to client n will still be able to interact with users who set tributes. Could be an issue for users who don't update from client n-2 or n-3. 12 | 13 | 14 | **New items** 15 | 16 | | Item | Status | Completed? | 17 | | -------- | -------- | -------- | 18 | | _Profile changes_ | | 19 | | Restructuring Profile screen | Ready for implementation | No | 20 | | ENS setting & usage | Being implemented | No | 21 | | _Wallet_ | | | 22 | | Add custom tokens | Requirements, design needed | No | 23 | | Set max Tx amount | Requires scoping | No | 24 | | Improve Tx history | Requirements, design needed | No | 25 | | _Onboarding_ | | | 26 | | Normal account creation flow | In design | No | 27 | | Keycard account creation flow | In design/being implemented | No | 28 | | Normal account recovery | In design | No | 29 | | Keycard account recovery | In design | No | 30 | | _Browser_ | | | 31 | | Privacy mode setting UI | In design | [Yes](https://github.com/status-im/status-react/pull/8112) | 32 | | _ENS DApp_ | | | 33 | | Check for deprecation in light of new registrar | Research required (domains from old registrar must be migrated) | | 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /ideas/168-paid-master-nodes/local-mailserver.md: -------------------------------------------------------------------------------- 1 | # How to run and use mail server locally 2 | 3 | ## status-go 4 | 5 | Just some notes: 6 | 7 | ``` 8 | make statusgo 9 | ./build/bin/statusd -shh -datadir=paid-data-mailserver -shh.mailserver -shh.passwordfile=wnode-data-mailserver/password.txt -listenaddr=127.0.0.1:30303 -log=DEBUG -ipc 10 | ``` 11 | 12 | Verify peers are connected separately: 13 | 14 | ``` 15 | geth attach ~/git/status-go/paid-data-mailserver/geth.ipc 16 | admin.peers 17 | ``` 18 | 19 | ## Clojure side 20 | 21 | Add local mail server to `constants.cljs` where address is RLPx in print out above, e.g: 22 | 23 | ``` 24 | "paid" {:id "paid" 25 | :name "Status testnet mailserver paid, experimental" 26 | :address 27 | "enode://9f0a55f116aedb40d4036d9a385d505d9c183fd708ef1aa2f883895df97864f758eee911c26c86732ae13a57664a076de2527189f983ee24dda2a4cb5f5db777@127.0.0.1:30303"} 28 | ``` 29 | 30 | Connect to it, might need to switch networks and login/logout etc to trigger 31 | requestMessages`. Make sure networks match. Check logs for `offline inbox` to 32 | see flow. Can switch offline server in advanced settings. 33 | 34 | If there are issues with peers, and mail server has peers, then going into CLJS repl and: 35 | 36 | ``` 37 | (require 'status-im.transport.inbox) 38 | (status-im.transport.inbox/add-peer "enode://987c40d5761678f030d80de13a2f8a0150da651e5d2c430b96e4f8c2c544389918c7bd820d2d6a5610afb96dcedf8ebb0b941859a0cdbd7dddbbd13994dcbe52@[::]:30303" println println) 39 | (status-im.transport.inbox/fetch-peers println println) 40 | ``` 41 | 42 | can help with debugging. 43 | 44 | ## Notes 45 | 46 | Note that this above flow only modifies the 'server' side of mail server and UI 47 | side of client. If you want to modify status-go node on client side you need to 48 | make sure status-go is built and linked properly in the app. See 49 | https://github.com/status-im/status-react/blob/develop/scripts/bundle-status-go.sh 50 | -------------------------------------------------------------------------------- /_includes/peoplestable.html: -------------------------------------------------------------------------------- 1 |

Classifieds

2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | {% assign ideas = include.ideas | sort: 'id' %} 15 | {% assign count = ideas|size %} 16 | 17 | {% for page in ideas %} 18 | {% assign count = page.roles-needed|size %} 19 | {% if count > 0 %} 20 | 21 | 22 | 25 | 30 | 31 | 37 | 38 | {% endif %} 39 | {% endfor %} 40 | 41 |
IdeaLooking forIdea statusOKRs
23 | {{page.id|xml_escape}} 24 | 26 | {% for role in page.roles-needed %} 27 | {{ role }} 28 | {% endfor %} 29 | {{ page.status }} 32 | {% for okr in page.okrs %} 33 | {{ okr }}
34 | {% endfor %} 35 | 36 |
42 | 43 |

Commitment registry

44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | {% for contributor in site.data.contributors %} 54 | {% assign ideas = include.ideas|where:"status","Active" %} 55 | 56 | 57 | 58 | 65 | 66 | {% endfor %} 67 |
contributorIdeas
{{contributor|xml_escape}} 59 | {% for page in ideas %} 60 | {% if page.contributors contains contributor %} 61 | {{page.id|xml_escape}} 62 | {% endif %} 63 | {% endfor %} 64 |
68 | 69 | -------------------------------------------------------------------------------- /ideas/146-status-go-sdk/BasicSDK.md: -------------------------------------------------------------------------------- 1 | ## Status messaging basic interaction 2 | 3 | ** * TODO its still not clear how username works on the new protocol, it may change the methods using it, as it's not used atm. ** 4 | 5 | ### Setup a new connection 6 | 7 | SDK should offer an **easy** but **configurable** way to setup the status node. 8 | 9 | 10 | #### Connect 11 | 12 | Connect method will create a new connection, attach the default configuration, and login with the provided password. 13 | 14 | ``` 15 | conn, err := sdk.Connect(username, password) 16 | ``` 17 | 18 | 19 | ### Ability to close a specific connection 20 | 21 | In order to close all channels, sdk.Conn object should offer a `Close` method. 22 | ``` 23 | conn, err := sdk.Connect(username, password) 24 | defer conn.Close() 25 | ``` 26 | 27 | ### Ability to change connection configuration 28 | 29 | Even `Connect` method is suitable for almost all situations, some developers may want to customize statusNode configuration. To accomplish that, one can simply divide Connect method on its internal calls like: 30 | ``` 31 | cfg := sdk.DefaultConfig() 32 | cfg.NodeConfig.WhisperConfig.MinimumPoW = 0.001 33 | 34 | conn := sdk.New() 35 | if err := conn.Start(cfg); err != nil { 36 | panic("Couldn't connect to status") 37 | } 38 | 39 | if err := conn.SignupOrLogin("username", "password"); err != nil { 40 | panic(err) 41 | } 42 | ``` 43 | 44 | ### Ability to sign up on the platform 45 | 46 | `SignupOrLogin` method is provided so you can sign up as a specific user 47 | 48 | ``` 49 | if err := conn.SignupOrLogin("username", "password"); err != nil { 50 | panic(err) 51 | } 52 | ``` 53 | 54 | 55 | ### Ability to login as a specific account 56 | 57 | `Login` method provides an interface to log in 58 | 59 | ``` 60 | if err := conn.Login("username", "password"); err != nil { 61 | panic(err) 62 | } 63 | ``` 64 | 65 | 66 | ### Documented API for basic sdk interaction 67 | 68 | This document can be adapted as a documentation for basic sdk interaction 69 | -------------------------------------------------------------------------------- /ideas/146-status-go-sdk/ContactManagement.md: -------------------------------------------------------------------------------- 1 | ## Contact management 2 | 3 | ### Invite new contact 4 | The UI for Inviting a new contact should be something like: 5 | ``` 6 | if account, err := conn.Invite("my_friend_public_key"); err != nil { 7 | panic("An error occurred while inviting a friend") 8 | } 9 | ``` 10 | 11 | Before starting to chat with someone privately you should have its contact details. In order to do that, the next process should happen 12 | 13 | ##### Generate a new symkey (shh_newSymKey): 14 | Generates a new symetric key 15 | ``` 16 | {"jsonrpc":"2.0","id":872,"method":"shh_newSymKey","params":[]} 17 | ``` 18 | 19 | 20 | ##### GetSymKey (shh_getSymKey): 21 | Polls any message for the symetric key 22 | ``` 23 | {"jsonrpc":"2.0","id":873,"method":"shh_getSymKey","params":["14829092e1b30cb9ab643ef9aa3c37e5a576e69821259cc690f8cccedd08dc94"]} 24 | ``` 25 | ** [ TBD : How do i calculate what's on params? ] ** 26 | 27 | 28 | ##### Create filter for new topic (shh_newMessageFilter): 29 | ``` 30 | {"jsonrpc":"2.0","id":879,"method":"shh_newMessageFilter","params":[{"topics":["0x6c0b63af"],"symKeyID":"14829092e1b30cb9ab643ef9aa3c37e5a576e69821259cc690f8cccedd08dc94","allowP2P":true}]} 31 | ``` 32 | Main difference here with public channels is how the topic is calculated 33 | **[ TODO DEFINE HOW TOPIC IS CALCULATED ]** 34 | 35 | 36 | ##### Send first message with my contact information (shh_post) 37 | ``` 38 | {"jsonrpc":"2.0","id":880,"method":"shh_post","params":[{"sig":"0x046f29b16371c05880c3da0279c7b8f958f97be79e00ca2a8f9e951eb254ccf8ead793af564a66c952668ad9e6e8f6dac5773bd1087d87273ebcece8da03420085","pubKey":"","payload":"... 39 | ``` 40 | Where the decrypted payload looks like : 41 | ``` 42 | ["~#c1",["0xcfbb3e7c45ced993287039e9a3aa37d15d6c2f80ba2599e07ee53520f239d4d1","0x6c0b63af",["~#c2",["","data:image/png;base64,......","b5b16e93dbd4bbcb2448b98bfbb9e0062ea18603",null]]]] 43 | ``` 44 | 45 | 46 | ### Accept new contact 47 | 48 | **[ TBD ]** 49 | -------------------------------------------------------------------------------- /ideas/168-paid-master-nodes/stt-payment-testing.md: -------------------------------------------------------------------------------- 1 | # Getting and sending STT, proof of payment 2 | 3 | Some notes for initial payment MVP and testing thereof. 4 | 5 | ## How do I get STT? 6 | 7 | - Be on Ropsten 8 | - Advanced settings -> Development mode 9 | - Chat with console and use `/faucet ` to get ETH 10 | - > For STT simply send a transaction (can be 0 ether) with Gas limit 105000 (you need to set the value manually!) to the following address: 0x34358C45FbA99ef9b78cB501584E8cBFa6f85Cef (https://wiki.status.im/Testing_FAQ_(core_team)) 11 | - You should have 1000 STT 12 | 13 | ## Sending and getting proof of payment 14 | 15 | Send STT tx to (friend, mail server) with default gas and: 16 | :status-im.ui.screens.wallet.send.events/transaction-completed 17 | :response -> :id/:hash => 0x1734f4ff6840ec92b589ca7fc2adbee3c8bcb16b4bffe9954496e00f9d27eeb1 18 | 19 | Shows up here: https://ropsten.etherscan.io/tx/0x1734f4ff6840ec92b589ca7fc2adbee3c8bcb16b4bffe9954496e00f9d27eeb1 20 | 21 | Can probably be queried in a more trustless way, but requires further 22 | investigation. Depends on what services are running on mail server. 23 | 24 | ## Requesting funds? 25 | Limitation: can't currently request funds in STT. Also coupled with chat, etc. 26 | Easier to just pop up tx screen. Prefilled. 27 | 28 | ## Payment for MVP 29 | 30 | Navigate to `:wallet-send-transaction` with: 31 | - recipient 32 | - STT 33 | - amount 34 | - gas price filled in / default 35 | 36 | You send it, and once you get tx completed you have hash id. This can be sent to 37 | mail server who can verify it and accept it. This means you paid and it is up to 38 | mail server to respect in a way. You send this tx id to mail server. It responds 39 | with some OK message. 40 | 41 | (Ideally funds are locked so you don't send payment and it doesn't respect it, 42 | but this is a later iteration). 43 | 44 | ## Problem re proof of payment 45 | 46 | If you send tx id, you have enode, but this should be verified with address. So 47 | ideally you'd sign tx with your account. Iteration 1? Separate dock. 48 | -------------------------------------------------------------------------------- /ideas/034-react-native-qt/log.md: -------------------------------------------------------------------------------- 1 | ## Logfile 2 | 3 | ### 2018-06-05 4 | - Decision to pause this swarm. The work to be continued in Desktop swarm. 5 | 6 | ### 2018-05-25 7 | - TextInput enchancements: Support of keyboard modifiers keys, newline character. (Volodymyr) 8 | - patch-package node.js tool is used to automate patching of 3rd party node modules on `npm install`. (Max) 9 | 10 | ### 2018-05-18 11 | - Build script to fully automate Mac OS bundle build process. (Volodymyr) 12 | - TextInput react-native component issues resolution to work as expected in StatusIm Desktop. (Volodymyr) 13 | - react-native-desktop optional support of QtWebKit web engine. (Max) 14 | - status-go C library build process is automated as part of cmake build script. (Max) 15 | - react-native-desktop docs update with the relevant information about the project (supported platforms, new app init process, 3rd party react-native-modules support). (Max) 16 | 17 | ### 2018-05-15 18 | - StatusIm AppImage distribution tested on Ubuntu and Debian (Has issues on Arch Linux distro). (Max) 19 | 20 | ### 2018-05-14 21 | - Pre-building of QtWebKit for Qt 5.9.1 MinGW based on Windows to enable WebView react-native component support. (Max) 22 | 23 | ### 2018-05-11 24 | - Building react-native-desktop sources on Windows. (Max) 25 | 26 | ### 2018-05-07 27 | - StatusIm Windows portable binaries distribution. (Max) 28 | 29 | ### 2018-05-05 30 | - StatusIm Ubuntu binaries distribution. (Max) 31 | - Investigation and resolution of StatusIm.app bundle new account creation issues on Mac OS. (Volodymyr) 32 | 33 | ### 2018-05-04 34 | - JavaScriptCore integrated into react-native-desktop. (Max) 35 | 36 | ### 2018-05-01 37 | - StatusIm.app bundle for Mac OS. (Volodymyr) 38 | 39 | ### 2018-04-27 40 | - Production build of StatusDesktop. (Volodymyr) 41 | - Native react-native-desktop module for Realm with JavaScriptCore support In-Progress. (Max) 42 | 43 | ### 2018-04-20 44 | - Known crashes of StatusDesktop are fixed. (Volodymyr) 45 | - JavaScriptCore is integrated with react-native-desktop and is working on Ubuntu. Changes are not yet merged. (Max) 46 | 47 | ### 2018-04-14 48 | - status-react Desktop is running on top of react-native-desktop. Messages sending and receiving working. (Volodymyr) 49 | 50 | ### 2018-04-10 51 | - Moved single idea file into swarm directory 52 | - Added logfile 53 | -------------------------------------------------------------------------------- /ideas/310-core.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #310-core 3 | title: Core Team 4 | status: research 5 | lead conributor: Igor 6 | contributors: 7 | - Adam 8 | - Andrea MP 9 | - Pedro 10 | - Roman 11 | - Dmitry S 12 | - Volodymyr K 13 | budget: 14 | - actual: xxx 15 | - estimate: yyy 16 | - currency: ETH/USD/SNT 17 | --- 18 | 19 | # Core Team 20 | ## Summary and Goal(s) 21 | Status Core is responsible for implementing a decentralized, reliable Ethereum reference client for Mobile on Android and iOS. This client should provide a reliable communication medium and ability to access the open decentralized web. 22 | 23 | Mobile: The highest priority is to prepare Status to the public release in terms of performance and reliability. 24 | 25 | Desktop: support and make usable for core contributors; do releases; reuse mobile codebase as much as possible to simplify feature development and bugfixing, with the goal of supporting `react-native-desktop` only. 26 | 27 | Core needs an accountable, passionate get-shit-done mentality and drive, in contrast to the meandering blame-shifting. 28 | 29 | 30 | ## Additional contibutors 31 | - Andrei M (Design) 32 | - Serhy/Anna/Nastya(QA) 33 | 34 | ## Scope 35 | 36 | Core should focus on problems/features that require multidisciplinary understanding and influence the application architecture. With the highest priority of making Status Mobile app a usable application for consumption. 37 | 38 | ### Active Swarms 39 | * [Network Incentivization Swarm](./313-core-networking.md) 40 | * [Core Improvements Swarm (deprioritized)](./315-core-improvements.md) 41 | * Desktop 42 | 43 | 44 | ## Communications 45 | (required) 46 | `status channel`:[`#status-core`](http://get.status.im/chat/public/status-core). 47 | `sync frequency`: Weekly Sync, Monday 10am CET 48 | `meeting notes`: [this running doc on notes.status.im](https://notes.status.im/sm7x7tPpQESkRwu7YNFzSQ) 49 | 50 | 51 | ### Process 52 | Weekly sync-up calls 53 | - goals for the week 54 | - focus area, progress 55 | 56 | Each project that is currently active should have an umbrella Epic in Pivotal Tracker that should 57 | link all the other issues. It contains a full description of the project and is 58 | closed when the project is considered "done". 59 | 60 | Pivotal Tracker project for Core: https://www.pivotaltracker.com/n/projects/2232205 61 | 62 | ## Copyright 63 | 64 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 65 | -------------------------------------------------------------------------------- /ideas/281-security-process-experiment.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 281-security-process-experiment-pilot 3 | title: Securty Process Experiment / Pilot 4 | status: In Progress 5 | created: 2018-07-25 6 | category: core 7 | lead-contributor: mandrigin 8 | contributors: 9 | - flexsurfer 10 | - goranjovic 11 | exit-criteria: yes 12 | success-metrics: yes 13 | clear-roles: yes 14 | future-iterations: yes 15 | roles-needed: 16 | --- 17 | 18 | ## Preamble 19 | 20 | Idea: #281-security-process-experiment-pilot 21 | Title: Security Process Experiment / Pilot 22 | Status: In Progress 23 | Created: 2018-07-25 24 | 25 | The Security Experiment consists of a Security Process and potentially a few 26 | one-time projects, like retroactively threat-modeling the app and setting up 27 | the security-related automation features. 28 | 29 | This experiment starts in a limited amount of teams (pilot) and to be expanded 30 | if successful. 31 | 32 | Pilot is limited to `#core-wallet` and `#core-dapps` projects. 33 | 34 | ## Objectives 35 | 36 | - build security culture in the organization; 37 | 38 | - implement "security first" approach to building our projects. 39 | 40 | ## Key Results 41 | 42 | - Security Champions are identified; 43 | 44 | - There is a security-related community in the organization; 45 | 46 | - The projects are build using the best practices of secure development 47 | (including automation); 48 | 49 | - Each team has a security contact; 50 | 51 | - All the new features get security & privacy assessments; 52 | 53 | ## Timeline / Checkpoints 54 | 55 | Length of the experiment: 3 months 56 | 57 | Experiment starts July, 25th 58 | 59 | Check-ups: 60 | 61 | - after month 1 (Aug, 23th) 62 | 63 | - assessment of key results and security perception/awareness within Status; 64 | 65 | - Polly check-ups with security champions; 66 | 67 | - Retrospective/1:1s with security champions; 68 | 69 | - Retrospective with each of the pilot teams. 70 | 71 | # Exit Criteria 72 | 73 | - 1 month has passed; 74 | 75 | # Success Metrics 76 | 77 | - New features in both wallet and dapps team are being security-assessed and 78 | threat modelled if needed; 79 | 80 | - Security Champions know their responsibilities; 81 | 82 | - People in Status are aware about the security process. 83 | 84 | ## What exactly we going to do? 85 | 86 | See [Security Experiment @ docs.status.im](https://docs.status.im/docs/security_experiment.html) 87 | 88 | 89 | 90 | -------------------------------------------------------------------------------- /ideas/309-js-protocol-library-webclient.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 309-js-library 3 | title: Build a status protocol JS library & example web client for status 4 | status: draft 5 | created: 2018-10-15 6 | category: multi-category 7 | lead-contributor: iurimatias (Iuri Matias) 8 | contributors: 9 | - Richard Ramos 10 | - Barry G 11 | exit-criteria: no 12 | success-metrics: 13 | - js library that is easy to reuse to implement custom clients for status 14 | - proof of concept web chat client 15 | clear-roles: no 16 | future-iteration: yes 17 | roles-needed: 18 | - JS or TS developers (nodejs, react, redux) 19 | - Frontend developers (css, bootstrap) 20 | --- 21 | 22 | ## Preamble 23 | 24 | Idea: 309 25 | Title: Build a status protocol JS library & example web client for status 26 | Status: Draft 27 | Created: 2018-10-15 28 | 29 | ## Summary 30 | 31 | We need to make it easier for devs & 3rd parties to build their own chat clients & applications on top of the status protocol. 32 | We also need different/new client implementations which just like in the case of Ethereum itself, helps out flush the protocol and define it better. Arguably It also helps decentralization as users are not necessarily dependant on one client implementation. 33 | 34 | ### Swarm Participants 35 | 36 | - Contributor: [@iurimatias](https://github.com/iurimatias) 37 | - Contributor: [@richard-ramos](https://github.com/richard-ramos) 38 | - Contributor: [@bgits](https://github.com/bgits) 39 | 40 | ### Technical solution 41 | 42 | - JS library that abstracts protocol, so developer can: 43 | -- connect to (a) network 44 | -- listen & send messages to a channel or another user 45 | -- is allowed to specify his own (sub)-app protocol 46 | - Webapp client 47 | -- serverless app, connects to local geth node (initial solution) 48 | -- implements similar UI & functionality to existing status desktop 49 | 50 | ### Technologies to use 51 | 52 | - nodejs + webpack (to build library for both node and browser) 53 | - react 54 | - redux 55 | 56 | ### Milestones 57 | 58 | * 1. poc script that listens & display messages on the command line connected to a configured geth node. 59 | * 2. NodeJS library to listen to & send messages to custom channels. 60 | * 3. poc WebUI to listen to & send messages to custom channels. 61 | 62 | ### Dates 63 | 64 | To start after Devcon. 65 | 66 | ### relevant work 67 | 68 | - https://github.com/trazyn/weweChat 69 | - https://github.com/noman-land/matrix-whisper-bridge 70 | 71 | -------------------------------------------------------------------------------- /ideas/293-ulc-integration/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 293-ulc-integration 3 | title: ULC integration 4 | status: In Progress 5 | created: 2018-08-06 6 | category: core 7 | lead-contributor: mandrigin 8 | contributors: 9 | - mandrigin Clojure dev 10 | - b00ris Go dev 11 | - jeka Go dev 12 | exit-criteria: yes 13 | success-metrics: yes 14 | clear-roles: yes 15 | future-iteration: yes 16 | okrs: 17 | - Core. [P0] LES and/or ULC are operational and used by at least 10% of all users. 18 | --- 19 | 20 | ## Preamble 21 | 22 | Idea: 293-ulc-integration 23 | Title: ULC integration 24 | Status: In Progress 25 | Created: 2018-08-06 26 | Requires (*optional): #254 27 | 28 | ## Summary 29 | Status app can use LES and ULC as Ethereum providers instead of Infura. 30 | 31 | ## Swarm Participants 32 | - Lead Contributor: @mandrigin 33 | - Contributor: @jeka 34 | - Contributor: @b00ris 35 | - Contributor: TBD 36 | - QA: TBD 37 | 38 | ## Product Overview 39 | We need LES client enabled on mobile device to be really decentralized and to enable all web3 features for dApps. 40 | 41 | ### Requirements & Dependencies 42 | ULC integration depends on research swarm #254 43 | 44 | ### Security and Privacy Implications 45 | * Free slots for LES servers(can be resolved by les service model, onlyannounce servers, vipnode) 46 | * Trusted nodes selection(trusted nodes list can be automatically expanded or changed) 47 | 48 | ### Minimum Viable Product 49 | * LES can work as the second Ethereum provider in status app. 50 | * ULC can work as the third Ethereum provider in status app with static trusted nodes. 51 | 52 | ### Iteration 0 53 | 54 | Goal Date: 2018-09-10 55 | 56 | Description: 57 | * Add LES as an option for test networks 58 | * ULC in go-ethereum master(#254) 59 | * Add LES servers to our staging fleet 60 | 61 | ### Iteration 1 62 | 63 | Goal Date: 2018-09-14 64 | 65 | Description: 66 | * investigate les integration problems and add it to backlog 67 | 68 | ### Iteration 2 69 | 70 | Goal Date: 2018-09-25 71 | 72 | Description: 73 | * run in our cluster onlyAnnounce LES servers 74 | * update go-ethereum with ULC in status-go 75 | * graceful downgrade(use infura by default and if it fails, start ULC node) 76 | 77 | ### Iteration 3—... 78 | 79 | Goal Date: 2018-09-25 80 | * TBD 81 | 82 | ## Success Metrics 83 | * Status app can use LES and ULC provider instead of Infura (10% of users are using it). 84 | 85 | ## Exit criteria 86 | * Running on Mainnet 87 | 88 | ## Copyright 89 | 90 | Copyright and related rights waived 91 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 92 | -------------------------------------------------------------------------------- /principles.md: -------------------------------------------------------------------------------- 1 | # Status Principles 2 | 3 | The goal of Status is widespread adoption of the decentralized web. Our challenge is achieving mass adoption while staying true to our principles outlined below. 4 | 5 | **I. Liberty** 6 | We believe in the sovereignty of individuals. As a platform that stands for the cause of personal liberty, we aim to maximize social, political, and economic freedoms. This includes being coercion-resistant. 7 | 8 | **II. Censorship resistance** 9 | We enable free flow of information. No content is under surveillance. We abide by the cryptoeconomic design principle of censorship resistance. Even stronger, Status is an agnostic platform for information. 10 | 11 | **III. Security** 12 | We don't compromise on security when building features. We use state-of-the-art technologies, and research new security methods and technologies to make strong security guarantees. 13 | 14 | **IV. Privacy** 15 | Privacy is the power to selectively reveal oneself to the world. For us, it's essential to protect privacy in both communications and transactions, as well as being a pseudo-anonymous platform. Additionally, we strive to provide the right of total anonymity. 16 | 17 | **V. Transparency** 18 | We strive for complete openness and symmetry of information within the organization, and have no border between our core contributors and our community. We are frank about our shortcomings, especially when making short-term tradeoffs in service of our long-term goals. 19 | 20 | **VI. Openness** 21 | The software we create is a public good. It is made available via a free and open source license, for anyone to share, modify and benefit from. We believe in permission-less participation. 22 | 23 | **VII. Decentralization** 24 | We minimize centralization across both the software and the organization itself. In other words, we maximize the number of physical computers composing the network, and maximize the number of individuals who have control over the system(s) we are building. 25 | 26 | **VIII. Inclusivity** 27 | We believe in fair and widespread access to our software, with an emphasis on ease-of-use. This also extends to social inclusivity, permissionless participation, interoperability, and investing in educational efforts. 28 | 29 | **IX. Continuance** 30 | We create software incentivized to continue to exist and improve, without the stewardship of a single entity or any of the current team members. 31 | 32 | **X. Resourcefulness** 33 | We are relentlessly resourceful. As we grow and have ready access to capital, it is our obligation to token holders to fight bureaucracy and inefficiencies within the organization. This means solving problems in the most effective way possible at lower economic costs (in terms of capital, time and resources). 34 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Status Swarms 2 | 3 | Swarms follow a structured approach to developing features. These include: 4 | - Research 5 | - Specifications / Planning 6 | - Implementation 7 | - Communication / Post-mortem 8 | 9 | ## Getting Started 10 | 11 | For new swarms: 12 | - Copy and Paste [TEMPLATE.md](https://github.com/status-im/swarms/blob/master/TEMPLATE.md) into [notes.status.im](https://notes.status.im) 13 | - Define Contributors 14 | - Define Rough summary 15 | - [Timebox](https://en.wikipedia.org/wiki/Timeboxing) (approx) `Research` 16 | - Submit to [this repo](https://github.com/status-im/swarms) as a pull request. 17 | 18 | For existing swarms: 19 | - Go to the file in Github 20 | - Click edit and commit 21 | 22 | ## Active swarms 23 | 24 | ### SNT Utility 25 | - [316-core-network-incentives](ideas/316-core-network-incentives.md) (research until 31/1) 26 | https://www.pivotaltracker.com/reports/v2/projects/2232205/epics 27 | - [313-sticker-market](ideas/313-sticker-market/readme.md) (implementation) 28 | https://www.pivotaltracker.com/reports/v2/projects/2231918/epics 29 | - [314-tribute-to-talk](ideas/314-tribute-to-talk/README.md) (implementation) 30 | https://www.pivotaltracker.com/reports/v2/projects/2231830/epics 31 | - [317-dapp-store](ideas/317-dapps-store.md) (research) 32 | https://www.pivotaltracker.com/reports/v2/projects/2235976/epics 33 | - [321-teller-network](ideas/321-teller-network.md) (implementation) 34 | https://www.pivotaltracker.com/reports/v2/projects/2231548/epics 35 | 36 | 37 | ### Essential 38 | - [368-token-economics](ideas/368-token-economics.md) (research) 39 | - [315-core-improvements](ideas/315-core-improvements.md) (implementation) 40 | https://www.pivotaltracker.com/reports/v2/projects/2232205/epics 41 | - [311-protocol](ideas/311-status-protocol.md) (research) 42 | - [322-dao](ideas/322-dao.md) (research) 43 | https://www.pivotaltracker.com/reports/v2/projects/2231548/epics 44 | - [312-janitors](ideas/312-swarm-janitors.md) (implementation) 45 | 46 | ### Teams (fallback for responsibility) 47 | - [310-core](ideas/310-core.md) (implementation) 48 | https://www.pivotaltracker.com/reports/v2/projects/2232205/epics 49 | - [306-core-browser](ideas/306-core-browser.md) (implementation) 50 | https://www.pivotaltracker.com/reports/v2/projects/2231918/epics 51 | - [304-core-chat](ideas/304-core-chat.md) (implementation) 52 | https://www.pivotaltracker.com/reports/v2/projects/2231830/epics 53 | - ~[318-desktop](ideas/318-desktop.md)~ (merged with [310-core](ideas/310-core.md)) 54 | - [319-wallet](ideas/319-core-wallet.md) (research) 55 | https://www.pivotaltracker.com/reports/v2/projects/2231938/epics 56 | - [320-keycard](ideas/320-keycard.md) (implementation) 57 | https://www.pivotaltracker.com/reports/v2/projects/2236359/epics 58 | -------------------------------------------------------------------------------- /ideas/315-core-improvements.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #313-core-improvements 3 | title: Core Improvements Swarm 4 | status: research 5 | lead contributor: igor 6 | contributors: 7 | - adam 8 | - dmitry s 9 | - roman 10 | - pedro 11 | budget: 12 | - actual: xxx 13 | - estimate: yyy 14 | - currency: ETH/USD/SNT 15 | --- 16 | 17 | # Core Improvements Swarm 18 | 19 | ## Summary and Goal(s) 20 | 21 | Status Core Improvements swarm's goal is the preparation of Status Mobile Client to be released publicly (AppStore/GP release tracks). 22 | 23 | A few key areas that we need to focus on: 24 | 25 | * all the critical security and privacy issues are resolved (including audit); 26 | - a security and privacy document is delivered (it lists guarantees we make around security and privacy; as well as ways we are falling short) 27 | 28 | * all the critical tech debt issues are resolved; 29 | * key UX problems are solved in two areas: 30 | - adoption issues; 31 | - retention issues. 32 | 33 | The work includes releasing internal "dogfood" builds as well as betas in preparation to the public release. 34 | 35 | ### Additional contributors 36 | - Andrea MP 37 | - Andrei M (Design) 38 | - Serhy/Anna/Nastya(QA) 39 | - Rachel/Hester (PO) 40 | 41 | ## Communication 42 | (required) 43 | `status channel (same as Core Team)`: [`#status-core`](https://get.status.im/chat/public/status-core) 44 | `sync frequency`: Weekly Sync Mondays, 10:00 CET (the regular "Core Team" standup) 45 | `meeting notes`: [this running doc on notes.status.im](https://notes.status.im/sm7x7tPpQESkRwu7YNFzSQ) 46 | 47 | # Research 48 | 49 | ### Backlog refresh 50 | 5th February — refresh and re-prioritize backlog to keep it up to date 51 | 52 | ## Specification 53 | 54 | ## Implementation 55 | 56 | See https://www.pivotaltracker.com/n/projects/2232205 57 | 58 | O.9.32 releases (hotfixes) 59 | 0.9.33 release in preparation (feature update) 60 | 61 | ## Maintenance 62 | 63 | ### 1. Battery usage 64 | 65 | ### 2. Application performance profiling 66 | 67 | ### 3. Mobile Releases 68 | 69 | - [Mobile release guide](https://notes.status.im/mobile-release-guide) 70 | - [Mobile release notes](https://notes.status.im/mobile-release-notes) 71 | - Upgrade policy 72 | * *User’s data.* User should be able to successfully upgrade preserving all his/her data from 0.9.19 to any beta release. 73 | * *Messaging/Transactions.* User should be able to successfully interact (make transactions, chat, etc) with users that have 0.9.20 or later release. 74 | 75 | ## Backlog 76 | 77 | See Pivotal Tracker: https://www.pivotaltracker.com/n/projects/2232205 78 | 79 | 80 | ## Copyright 81 | 82 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 83 | 84 | 85 | -------------------------------------------------------------------------------- /ideas/282-deterministic-builds.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 282-deterministic-builds 3 | title: Deterministic Mobile App Builds 4 | status: In Progress 5 | created: 2018-09-01 6 | category: infra 7 | lead-contributor: jakubgs 8 | contributors: 9 | - corpetty 10 | - adambabik 11 | - mandrigin 12 | - divan 13 | - cammellos 14 | - antdanchenko 15 | - Graeme-Code 16 | exit-criteria: yes 17 | success-metrics: yes 18 | clear-roles: yes 19 | future-iterations: yes 20 | roles-needed: 21 | --- 22 | 23 | ## Preamble 24 | 25 | Idea: #282-deterministic-builds 26 | Title: Deterministic Mobile App Builds 27 | Status: In Progress 28 | Created: 2018-09-01 29 | 30 | The purpose of achieving deterministic builds is encuring security of Status software. Deterministic builds depend on ensuring stable inputs, ensuring stable outputs, and capturing as little of the build environment as possible. 31 | 32 | In simple terms, deterministic builds mean the same commit generates exactly the same software package(s) regardless of where and when it is built. This is achieved by controlling all possible variables in a build, which includes controlling your build environment as well. 33 | 34 | ## Objectives 35 | 36 | - status-go builds are deterministic 37 | - status-react builds are deterministic 38 | 39 | ## Key Results 40 | 41 | - Anyone can build a commit on their own machines and verify the result by comparing against our builds 42 | - We can upload Android builds to F-Droid which requires deterministic builds 43 | 44 | ## Timeline / Checkpoints 45 | 46 | Time is given since start of swarm. 47 | 48 | * __1 month__ 49 | - All major blockers are identified for major build steps 50 | - Dependencies 51 | - Compilation 52 | - Packaging 53 | * __3 months__ 54 | - All dependencies are contolled and versioned 55 | - Env controlling solution is chosen and implemented(vm, nix, docker) 56 | * __4 months__ 57 | - Remaining blockers are cleared 58 | - CI is configured to build in a deterministic way 59 | - Instructions to check build vailidty are published for anyone to use 60 | 61 | # Exit Criteria 62 | 63 | - All Status mobile and desktop app builds are deterministic 64 | 65 | ## What exactly we going to do? 66 | 67 | - Verify all of our dependencies are frozen and versioned (`Gemfile.lock`) 68 | - Verify we depend on no resources pulled from internet during build 69 | - Make sure we initialize all variables in an explicit way 70 | - Verify the build output does not depend on build system time/locale/encoding 71 | - Eliminate timestamp related changes (use `SOURCE_DATE_EPOCH`) 72 | - Use [gitan-builder](https://github.com/devrandom/gitian-builder) or [Nix](https://nixos.org/nix/) to have a controlled build environment 73 | - Configure deterministic builds to run on Jenkins 74 | -------------------------------------------------------------------------------- /ideas/080-onboarding.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 080-onboarding 3 | title: Onboarding 4 | status: Aborted 5 | created: 2018-01-25 6 | category: core 7 | lead-contributor: andmironov 8 | contributors: 9 | - andmironov 10 | - flexsurfer 11 | - annadanchenko 12 | - yevh-berdnyk 13 | - chadyj 14 | - hester 15 | exit-criteria: yes 16 | success-metrics: yes 17 | clear-roles: yes 18 | future-iterations: yes 19 | roles-needed: 20 | --- 21 | 22 | 23 | ## Preamble 24 | 25 | Idea: 80 26 | Title: Onboarding 27 | Status: In Progress 28 | Created: 2018-01-25 29 | 30 | ## Summary 31 | Design and implement a smooth onboarding experience for the Status app. 32 | 33 | ## Swarm Participants 34 | - Lead Contributor: @andmironov 35 | - Lead developer: @flexsurfer 36 | - Testing & Evaluation: @anna, @yevh-berdnyk 37 | - PM: @chadyj 38 | - UX: @hester 39 | 40 | ## Product Overview 41 | This project is about creating an onboarding experience for the users. Not only setting up an account, but introducing the app functionality and explaining how to benefit from it. The goal is to explain commonly unclear concepts and possible misconceptions. 42 | 43 | ## Iterations 44 | 45 | ### Historical: What was done in Q1 - MVP/Iteration 1 46 | 47 | Date: 2018-04-01 48 | 49 | Description: A simple and straightforward path from a fresh start of the app to sending a transaction. Basic empty states and basic educational layer. 50 | 51 | ### Iteration 2 52 | 53 | Date: 2018-04-09 54 | 55 | Description: 56 | - Improving the copy https://docs.google.com/document/d/1rq6lYgWDd-QQ9-F7th-2t1vH9Fs6yosTDkKcm19AdFU/edit 57 | - Design: Drafting out the Welcome Screen, Home screen, New screen to improve the UX 58 | 59 | ### Iteration 3 60 | 61 | Date: 2018-04-23 62 | 63 | Description: 64 | - Development: Update copy in the app 65 | - Design: Drafting out the Welcome Screen, Home screen, New screen to improve the UX 66 | - Design: Add invite friends via link (Wireframes and mockups) 67 | - Design: Explore possibility of adding touch id 68 | - Design: improve wallet setup, add screens to encourage transfering funds to status wallet 69 | 70 | ## Success Metrics 71 | - 80% of users complete initial account setup onboarding. Measured by in-app metrics. 72 | - 100% of users understand that Status is a messenger. Measured in survey. 73 | - 80% of users start a new chat during first use. Measured by user test session. 74 | - 50% of users understand what is a DApp and how to open a DApp. Measured by in-app metrics. 75 | - 50% of users invite friends to Status during first week. Measured by in-app metrics. 76 | 77 | ## Exit criteria 78 | New onboarding UI designed and agreed upon by design team / UXR, as well as implemented. 79 | 80 | ## Copyright 81 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 82 | -------------------------------------------------------------------------------- /ideas/039-group-chat/README.md: -------------------------------------------------------------------------------- 1 | ## Preamble 2 | 3 | Idea: 4 | Title: Group Chat 5 | Status: Draft 6 | Created: 2017-11-23 7 | Related: https://github.com/status-im/ideas/issues/15 8 | 9 | ## Summary 10 | 11 | Provide a powerful group chat with flexible moderation features 12 | 13 | ## Swarm Participants 14 | 15 | - Lead Contributor: @james 16 | - Testing & Evaluation: (TBD) 17 | - Contributor: @themue 18 | - Contributor: 19 | - PM: (TBD) 20 | - UX (if relevant): (TBD) 21 | 22 | ## Product Overview 23 | 24 | Users want to have a convenient and powerful group chat comparable to the market competitors. But beside these standard operations they want to have greater control over the content in their chat feeds ensuring 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. 25 | 26 | ### Minimum Viable Product 27 | 28 | - Goal Date: (TBD) 29 | - Description: The MVP provides users with basic moderation tools so that they can block users, filter posts with certain phrases, and reduce spam. 30 | 31 | #### User Stories 32 | 33 | - [US 1: Blocking a user](./user-stories/us-1-blocking-a-user.md) 34 | - [US 2: Reducing SPAM](./user-stories/us-2-reducing-spam.md) 35 | - [US 3: Filter unwanted content](./user-stories/us-3-filter-unwanted-content.md) 36 | - [US 4: Advanced filtering with smart contracts](./user-stories/us-4-advanced-filtering-with-smart-contracts.md) 37 | - [US 5: Subscribe to moderation providers](./user-stories/us-5-subscribe-to-moderation-providers.md) 38 | 39 | #### Requirements 40 | 41 | - A format / schema for moderation rules must be defined. 42 | - A standard rules interface for smart contracts must be defined. 43 | - A smart contract that must: 44 | - Allow a caller to burn any ERC20 token. 45 | - Allow a caller to label burn amounts. 46 | - Return burn amounts given a token address, user address, and an optional label. 47 | - A moderation settings UI must exist where the user may configure: 48 | - Blocked users. 49 | - Filtered phrases. 50 | - The address of a smart contract to call. 51 | - Burn amount required. 52 | - UserA must be able to block a UserB from UserB's profile. 53 | - Messages are evaluated against the moderation rules before they are rendered, aborting render where necessary. 54 | - Moderation rules must persist between sessions. 55 | - Chat group settings UI must: 56 | - Display the user's burn amount for that channel. 57 | - Allow users to burn tokens for that channel. 58 | 59 | ## Dates 60 | 61 | - Goal Date: (TBD) 62 | - Description: (TBD) 63 | - Testing Days required: (TBD) 64 | 65 | ## Success Metrics 66 | 67 | ## Copyright 68 | 69 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 70 | -------------------------------------------------------------------------------- /ideas/083-energy-efficient.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 083-energy-efficient 3 | title: Energy Efficient Status 4 | status: Active 5 | created: 2018-02-19 6 | category: core 7 | lead-contributor: mandrigin 8 | contributors: 9 | - mandrigin 10 | - lukaszfryc 11 | - janherich 12 | exit-criteria: yes 13 | success-metrics: yes 14 | clear-roles: yes 15 | future-iterations: yes 16 | okrs: 17 | - "[P4] Objective: Performance significantly improves" 18 | - "[P0] KR: Reduce power consumption to <120% of Telegram/Skype" 19 | --- 20 | 21 | ## Preamble 22 | 23 | Idea: 83 24 | Title: Energy Efficient Status 25 | Status: In Progress 26 | Created: 2018-02-19 27 | 28 | 29 | ## Summary 30 | A specific issue about the energy efficiency of different parts of Status (`status-go`, `status-react`, `desktop` (when running on a laptop battery). 31 | 32 | 33 | ## Swarm Participants 34 | - Lead Contributor: @mandrigin (~25h) 35 | - Contributor (Clojure): @janerich 36 | - Contributor (Clojure): @yenda 37 | - Contributor (QA): @lukaszfryc (~10h/week) 38 | 39 | ## Product Overview 40 | Energy consumption is a crucial part of the mobile experience, and even though it is related to performance, it is worth having a separate. 41 | The end goal is: 42 | - to provide a toolkit and guidelines to test energy efficiency of different parts of an app on different platforms; 43 | - using this toolkit to fix the top battery drainers; 44 | - notice regressions early by having tests in place. 45 | 46 | ### Goals 47 | 48 | 1. Create a BoK for Energy efficiency testing: https://github.com/orgs/status-im/projects/18 49 | a. test apps are created for both Android and iOS 50 | b. test cases are written and tools are created to measure the energy efficiency of both Status client (status-react+status-go) and tests apps (status-go exclusively). 51 | c. tests are run on a regular basis 52 | d. (stretch goal) tests are automated for both platforms 53 | 54 | 2. Fix obvious issues with energy consumption 55 | https://github.com/orgs/status-im/projects/17 56 | 57 | 58 | ## Exit criteria 59 | - [x] We have test cases and tools to check the energy efficiency of `status-go` and `status-react` independently; 60 | - [x] We can notice regressions/improvements caused, e.g. by updating the version of `go-ethereum` or new features of Status; 61 | - [ ] Top energy draining issues are identified and fixed. 62 | 63 | ## Success Metrics 64 | KR: 65 | (1) foreground chat energy consumption is < 120% of the apps in a similar class (messengers) 66 | (2) background chat energy consumption is < 120% of the apps in a similar class (messengers) 67 | (3) foreground dapps energy consumption is < 120% of the apps in a similar class (browsers) 68 | 69 | ## MVP(s) 70 | MVP (development): Identify top issues with CPU hogging in Status for Android 71 | 72 | 73 | ## Supporting Role Communication 74 | 75 | ## Useful Links 76 | https://github.com/dgryski/go-perfbook 77 | 78 | ## Copyright 79 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 80 | -------------------------------------------------------------------------------- /ideas/127-SOB-testing-process.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 127-sob-testing-process 3 | title: Improve OpenBounty Testing and make it easy to contribute 4 | status: Limbo 5 | created: 2018-04-02 6 | category: openbounty 7 | lead-contributor: churik 8 | contributors: 9 | - churik 10 | - annadanchenko 11 | - asemiankevich 12 | exit-criteria: yes 13 | success-metrics: yes 14 | clear-roles: yes 15 | future-iterations: yes 16 | --- 17 | 18 | ## Preamble 19 | 20 | Idea: 127 21 | Title: Improve OpenBounty Testing and make it easy to contribute 22 | Status: In Progress 23 | Created: 2018-04-02 24 | 25 | ## Summary 26 | - make QA process in SOB team easy to understand and support; 27 | - in order to reduce time spent on regression testing automate main use cases; 28 | 29 | ## Swarm Participants 30 | - Lead Contributor:@churik 31 | - Testing & Evaluation: @annadanchenko 32 | - Contributor: @asemiankevich 33 | 34 | ## Product Overview 35 | Full and transparent QA process in Status Open Bounty team will help to involve new people into the testing process more quickly (if needed) and provide developers with more info about what was tested in particular PR or in `develop` branch. Ideally process should be integrated with TestRail, but initially, a smoke checklist should be defined and then automated. 36 | 37 | All regression test cases should be automated eventually in order to reduce time for SOB testing and to find issues faster. 38 | In future would be nice to integrate GitHub pull requests with automation testing thus after PR will be built and deployed, it will trigger end-to-end tests and publish test results in PR comment. 39 | Hence this idea is a placeholder for current and future iterations of improving QA process in SOB team. 40 | 41 | ## Iterations 42 | 43 | ### Iteration 1 - `2018-04-30` 44 | 45 | #### Documentation 46 | - [ ] Tutorial video or docs about QA process in SOB team 47 | - [ ] Basic use cases (smoke checklist) are defined in TestRail 48 | #### Involvement 49 | - [ ] one more QA can test SOB 50 | #### Automation 51 | - [ ] automate PR creating, new claim check in `Activity` feed 52 | - [ ] define function for PR merging, `Manage Payouts` check 53 | - [ ] all tests are running successfully in [Jenkins](https://jenkins.status.im/job/end-to-end-tests/job/sob-end-to-end-tests/) 54 | 55 | ### Iteration 2 (WIP, can be modified) - `2018-05-30` 56 | 57 | #### Automation (1 full test for SOB, which contains all bounty stages) 58 | - [ ] define function for SNT transfer 59 | - [ ] define function for signing transaction and payout confirmation 60 | - [ ] 1 full end-to-end test is running successfully in [Jenkins](https://jenkins.status.im/job/end-to-end-tests/job/sob-end-to-end-tests/) 61 | 62 | ## Exit Criteria 63 | - The smoke checklist is fully automated and autotests are running through each PR which comes to `To test` column 64 | - Test artifacts (screenshots, log etc.) are integrated with GitHub and put to PR comments 65 | 66 | ## Success Metrics 67 | This idea should affect the following: 68 | - Reduced timeframe for testing 69 | - Speed up feedback provided on PRs 70 | -------------------------------------------------------------------------------- /ideas/152-friends-recovery.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 152-friends-recovery 3 | title: Friends Recovery (Secret Multisig) 4 | status: Draft 5 | created: 2018-04-07 6 | category: core 7 | lead-contributor: 3esmit 8 | contributors: 9 | - 3esmit 10 | - richard-ramos 11 | exit-criteria: yes 12 | success-metrics: yes 13 | clear-roles: no 14 | future-iterations: no 15 | --- 16 | 17 | # Friends Recovery (Secret Multisig) 18 | 19 | ## Preamble 20 | 21 | Idea: 152-friends-recovery 22 | Title: Friends Recovery (Secret Multisig) 23 | Status: Draft 24 | Created: 2018-04-07 25 | Requires: 145-identity 26 | 27 | 28 | ## Summary 29 | 30 | A multisig controller that store owners privately and requires a secret to sign a call, to be used as a recovery for Identity through trust of selected friends. 31 | 32 | ## Swarm Participants 33 | - Lead Contributor: Ricardo Guilherme Schmidt 34 | - Testing & Evaluation: 35 | - Contributor: Richard Ramos 36 | - PM: 37 | - UX: 38 | 39 | ## Product Overview 40 | 41 | A bad experience of cryptosystems is the lost or exposure of a private key, which can lead to irreversible situations. 42 | Some contracts, such as Identity, support a recovery address which can recover a lost key or compromised contract. 43 | This product will provide a way of Status users selecting friends to recover this contracts, together with a built-in user interface for requesting to friends and signing recovery request from locked-out friends. 44 | 45 | ### Product Description 46 | 47 | User would be able to: 48 | - Use semi-private data as secret, such as personal details or biometric data. 49 | - Select privately a big amount of friends able to recover but only require a few of them 50 | 51 | Locked out user would be able to: 52 | - Request recovery to friends 53 | 54 | User's friends would be able to: 55 | - Only know they are recovery when recovery is completed 56 | - Sign recovery call allowance for Friends Recovery contract to help locked out user (gas is paid by anyone/user) 57 | - Call Friends Recovery from Identity call allowance to help locked out friends (gas is paid by allower) 58 | 59 | 60 | ### Requirements & Dependencies 61 | 62 | - Idea 151-Identity is the first use case of this product, but Friends Recovery contract itself don't depend on Identity. 63 | 64 | ### Minimum Viable Product 65 | 66 | Goal Date: 2018-07-01 67 | 68 | Description: 69 | 70 | - Users can use a semi-private secret answer as recovery lock 71 | - Users can use friends as allowance for Identity recovery 72 | - Users are notified when a recovery is requested for them 73 | - Users can help locked out friends to recover their Identity without paying gas 74 | 75 | ## Success Metrics 76 | 77 | - Users are able to easly recover their Identity. 78 | 79 | ## Exit criteria 80 | 81 | - Becomes an extension of Identity settings 82 | 83 | ## Supporting Role Communication 84 | 85 | 86 | ## Copyright 87 | 88 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 89 | -------------------------------------------------------------------------------- /ideas/151-ens-usernames.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 151-ens-usernames 3 | title: Username ENS subdomain Registrar 4 | status: Draft 5 | created: 2017-11-20 6 | category: core 7 | lead-contributor: 3esmit 8 | contributors: 9 | - 3esmit 10 | - richard-ramos 11 | - alexvandesande 12 | - hesterbruikman 13 | - denis-sharypin 14 | - rachelhamlin 15 | exit-criteria: yes 16 | success-metrics: yes 17 | clear-roles: yes 18 | future-iterations: no 19 | --- 20 | 21 | # Username ENS subdomain Registrar 22 | 23 | ## Preamble 24 | 25 | Idea: 151-ens-usernames 26 | Title: Username ENS subdomain Registrar 27 | Status: Draft 28 | Created: 2017-11-20 29 | Replaces: 027-ens-usernames 30 | 31 | ## Summary 32 | 33 | Eliminates the need to copy/scan - and worse, type - long hexadecimal addresses / public keys, by providing an [ENS](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md) subdomain registry and recognition of ENS names in Status for interacting with other people in Status. 34 | 35 | ## Swarm Participants 36 | 37 | - Lead Contributor: Ricardo Guilherme Schmidt 38 | - Contributor: Richard Ramos 39 | - UX (Mist): Alexandre Van de Sande 40 | - UX (Status): Hester Bruikman 41 | - Design: Denis Sharypin 42 | - PM: Rachel Hamlin 43 | 44 | ## Product Overview 45 | 46 | A bad experience in most cryptosystems, aswell Status, is the requirement of typing or scanning the public keys and addresses to interact with other users in the network. 47 | ENS disrupt centralized DNS: like DNS resolves into IPs, ENS resolve into ethereum addresses (and more) trustlessly. 48 | Status would introduce a option for users registering a human readable contact username and its URI would be used in place of QR codes / private keys. 49 | A small fee is required, so users are buying the subdomain, and therefore could be exchanged with other users, this network effect is ignored by this idea. 50 | 51 | ### Product Description 52 | 53 | Users would be able to: 54 | - buy a subdomain from one of the ENS domains owned by Status. 55 | - find users by using the configured ENS Resolver for EMS address (subdomain.domain.eth) 56 | - search/suggest domain for a username. 57 | - send funds by typing their ENS address. 58 | 59 | Subdomain owners would be able to: 60 | - change the owner of the subdomain 61 | - change the resolver of the subdomain 62 | 63 | Democracy (or authority) would be able to: 64 | - add new domains available with its own price 65 | - change domains price 66 | - change owner of domain (required for update of subdomian registry) 67 | 68 | ### Minimum Viable Product 69 | 70 | Goal Date: 2018-05-10 71 | Description: 72 | 73 | - Users can register (FIFS) an available username in Status's ENS subdomain 74 | - Users can add friends by entering an ENS address 75 | - Basic UI for call include a domain 76 | 77 | ## Success Metrics 78 | 79 | Most users opt-in to register their username and use username subdomain to find their friends. 80 | 81 | ## Exit Criteria 82 | 83 | Running on Mainnet 84 | 85 | ## Copyright 86 | 87 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 88 | 89 | -------------------------------------------------------------------------------- /ideas/369-extensions/research.md: -------------------------------------------------------------------------------- 1 | # Extensions research 2 | 3 | `Timing`: 29/03/2019 4 | 5 | ## Selected use cases for MVP 6 | 7 | ### Out of alpha 8 | 9 | #### List current errors and identify missing ones 10 | 11 | Errors are represented as map containing well defined keys. It closely relates to the `trace` structure. 12 | Result of `parse` returns a map containing eventually a vector of `errors`. It is up to the consumer to decide what to do depending on those errors. 13 | 14 | ##### Error structure 15 | 16 | An error is a map composed of the following keys: `category`, `type`, `context` and `target`. 17 | 18 | Errors fall down into 2 main `categories`: 19 | 20 | * `format`: failure to read the extension (incorrect EDN) 21 | * `syntax`: failure to parse the extension 22 | 23 | Parse errors are related to the semantic applied to the EDN format. 24 | 25 | * incorrect keys (missing, unknown) 26 | * incorrect values (incorrect syntax, depends on value type) 27 | 28 | `context` is a map whose structure depends on the error type and target (.e.g {:message "Invalid .."}) 29 | 30 | `type` characterizes the error: `ìnvalid`, `missing`, `unknown` or `overriden`. 31 | 32 | `target` is a map composed of the following keys: 33 | 34 | * `key` the element key (e.g. 'meta or 'views/my-view) 35 | * `type` the type (e.g. view/query/event, block, reference, type, format, property, bindings) 36 | 37 | ##### Examples 38 | 39 | ```clojure 40 | {:category :format :type :reader} 41 | {:category :format :type :invalid :target {:type :key :key 'meta} :context {:data {..}}} 42 | {:category :format :type :unknown :target {:type :key :key 'unknown}} 43 | {:category :format :type :missing :target {:type :key :key 'meta}} 44 | {:category :format :type :overriden :target {:type :key :key 'views/view}} 45 | 46 | {:category :syntax :type :invalid :target {:type :reference :key 'views/sds :location [0]} :context {:data [unknown {}]}} 47 | {:category :syntax :type :invalid :target {:type :bindings :key 'views/sds :location [0]} :context {:type :assoc :data []}} 48 | {:category :syntax :type :invalid :target {:type :block :key 'views/sds :location [0]} :context {:type 'let :data [] :reason :body}} 49 | {:category :syntax :type :invalid :target {:type :block :key 'views/sds :location [0 1]} :context {:type 'if :data [] :reason :too-many-clauses}} 50 | {:category :syntax :type :invalid :target {:type :view :key 'views/sds} :context {:location [0 1 0]}} 51 | {:category :syntax :type :unknown :target {:type :reference :key 'view/sds} :context {:location [1]}} 52 | ``` 53 | 54 | #### Conduct risk assessment of all existing, potential or requested primitives 55 | 56 | All primitives can potentially leak private information. To surface this information to the end user ech primitive will define a `permission` set that details the potential associated risk. 57 | 58 | Some priitives can make private data available (e.g. an input file might make some local file available; a location event might leak the user location). Some other primitives can let this information escape status (e.g. an http event; an image with a specially crafted URL). 59 | Privacy risks emerges from the combination of both. -------------------------------------------------------------------------------- /ideas/275-recyclable-fee.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 275-recyclable-fee 3 | title: Recyclable Fee 4 | status: draft 5 | created: 2018-06-02 6 | category: core 7 | lead-contributor: Ricardo Guilherme Schmidt 8 | contributors: 9 | - 10 | exit-criteria: no 11 | success-metrics: no 12 | clear-roles: no 13 | future-iteration: no 14 | roles-needed: 15 | - QA 16 | - PM 17 | - UXR 18 | - Designer 19 | okrs: 20 | - 21 | - 22 | --- 23 | 24 | ## Preamble 25 | 26 | Idea: 275-recyclable-fee 27 | Title: Ricardo Guilherme Schmidt 28 | Status: Draft 29 | Created: 2018-06-02 30 | Requires: 172-topic-democracy 31 | 32 | ## Summary 33 | 34 | Instead of Burning fees, user lock them in a contract where a democracy can choose where user can destine them, such as approved Status Open Bounties. 35 | 36 | ## Swarm Participants 37 | 38 | - Lead Contributor: Ricardo Guilherme Schmidt 39 | - Contributor: 40 | - QA: 41 | - PM: 42 | - UX: 43 | 44 | ## Product Overview 45 | 46 | Burning fees are used when there is no rightful beneficiary for the destination of funds, however in a fixed supply economy will ultimately lead to a failed model because of excessive deflation of economy. 47 | Recycling fees to approved destinations by Status Democracy can lead to a self funded DAO through its own fees. 48 | This fees should not be introduced without reason, instead they are only introduced when there is no other way of achieving an social-economic feature, for example, a curation board where users can pay to increase a determined rating but there is no rightful destination of this funds in an decentralized organization. 49 | Future features of Status Network, such as "Emoji Score Board" will send fees to recycling. 50 | Users that have their locked fees will be able to select where that fees can go, therefore deciding by themselves which features to be implemented in Status are more important. 51 | 52 | ### User Stories 53 | 54 | Users have low incentives for donating his own funds to Status Open Bounty. 55 | While using Status Network, users sometimes have to pay to change the state of network, but that funds are kept in control of user. 56 | Users now have locked funds which they can only spend in approved Open Bounties, and they have free time to decide which one they want to support. 57 | 58 | ### Requirements & Dependencies 59 | 60 | 172-topic-democracy voting app for deciding where the fees can be destined. 61 | 62 | ### Security and Privacy Implications 63 | 64 | Pseudo-anonymous addresses can have public behavior tracked. 65 | 66 | ## Dates 67 | 68 | ### Minimum Viable Product 69 | 70 | Goal Date: 71 | 72 | Description: Dapp listing approved bounties and enable to send part or total user locked funds. 73 | 74 | ### Iteration 1 75 | 76 | Goal Date: 77 | 78 | Description: MVP + Voting app controls approved bounties. 79 | 80 | ## Success Metrics 81 | 82 | Status Open Bounty gets funded by users of the platform through the Recycle system. 83 | 25% of locked fees are recycled within a month. 84 | 85 | ## Exit criteria 86 | 87 | Launch recycling Status App in Mainnet with at least one source of fees. 88 | 89 | ## Copyright 90 | 91 | Copyright and related rights waived 92 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /ideas/386-nim-ewasm.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #386-nim-ewasm 3 | title: Nim Based Smart Contract Language targeting EWASM 4 | status: research 5 | lead-contributor: Jacques 6 | contributors: 7 | - Jacques 8 | 9 | budget: 10 | - actual: to be determined 11 | - estimate: 300 12 | - currency: ETH 13 | --- 14 | 15 | # Swarm proposal 16 | 17 | Ethereum 2.0 will introduce a new Virtual Machine for writing smart contracts, based on WebAssembly (WASM). This swarm will deliver a Nim based smart contract language to allow developers to write smart contracts in Nim, with minimal boilerplate. 18 | 19 | ## Summary and Goal(s) 20 | 21 | ## Communication 22 | 23 | `status channel (same as swarm id)`: [#386-nim-ewasm-dsl](https://gitter.im/status-im/nimplay) 24 | * Weekly Sync 25 | 12:00 UTC every Tuesday 26 | Call Link: https://meet.google.com/ozg-dova-eod 27 | 28 | ## Timeline 29 | 30 | * 2 months: Research and PoC 31 | * 2 months: Development and tooling 32 | * 2 months: Documenation and testing 33 | 34 | 35 | eWasm nim kick off point: 36 | 37 | - https://ewasm.readthedocs.io 38 | - https://discuss.status.im/t/wrc20-and-nim-the-ewasm-token-challenge/1167 39 | - https://github.com/jacqueswww/nim-eth-contracts 40 | - https://github.com/status-im/nim-eth-contracts 41 | 42 | Project repository: 43 | 44 | - https://github.com/status-im/nimplay 45 | 46 | Using existing eWASM compiler tookit in above repositories. Establish what a clean Nim - ethereum smart contract would look like. 47 | 48 | ## Specification 49 | 50 | The ethereum smart contract language will aim to have the following features: 51 | 52 | - Concept of public & private (exported & local) method. 53 | - Tooling 54 | - ABI encoding & decoding 55 | - Parameter Return Type decoder & encoder for public functions. 56 | - Start off with 64-Bit based if standardised at time of implementation. 57 | - WRC20 as reference point (https://gist.github.com/axic/16158c5c88fbc7b1d09dfa8c658bc363) 58 | - ABI JSON generating with Ethereum specific types (e.g. `uint256` and `map()`). 59 | - Strict ruleset for allowing only subset of Nim to be used. 60 | - Emphasis on readibility and verifiability. 61 | - Minimisation of "footguns". 62 | - Standard library and macros 63 | - Emitting of Log Events. 64 | - Specific syntax to store in the global scope of the contract (self/this). 65 | - Basic arithmetic support for Ethereum specific types. 66 | - Overflow protection (to be determined). 67 | - Must be able to write at minimum Token (ERC20) or NFT (ERC721) with DSL. 68 | - eWASM internal functions must be abstracted away (no direct interface with CallData, Storage and similar "ethereum" exposed functions). 69 | - Web3 Test suite against Ewasm chain/client (to be determined). 70 | 71 | ### Milestones 72 | 73 | - Defining principles for the Language 74 | - Simple tooling for nim contract development 75 | - ABI encoding/decoding 76 | - Deployment tools 77 | - Development environment / Framework 78 | - Townhall demo 79 | - WRC202 / ERC20 Token Contract running on ewasm testnet 80 | 81 | 82 | 83 | ## Implementation 84 | 85 | 86 | ## Maintenance 87 | 88 | - Jacques 89 | 90 | ## Copyright 91 | 92 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 93 | -------------------------------------------------------------------------------- /ideas/279-snt-voting-dapp.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 279-snt-voting-dapp 3 | title: SNT Voting Dapp 4 | status: draft 5 | created: 2018-06-05 6 | category: dapp 7 | contributors: 8 | - Barry 9 | - 3esmit 10 | - rramos 11 | - rachelhamlin 12 | exit-criteria: yes 13 | success-metrics: yes 14 | clear-roles: yes 15 | future-iteration: yes 16 | roles-needed: 17 | - QA 18 | - UXR 19 | - Designer 20 | okrs: 21 | - 22 | - 23 | --- 24 | 25 | ## Preamble 26 | 27 | Idea: 279 28 | Title: SNT Voting Dapp 29 | Status: Draft 30 | Created: 2018-05-21 31 | Requires (*optional): 172-topic-democracy 32 | 33 | ## Summary 34 | 35 | Provide Status users with a dApp to vote on ideas using their SNT thru carbon voting, without affecting their token balance. 36 | 37 | ## Swarm Participants 38 | 39 | - Lead Contributor: @3esmit 40 | - Contributor: @Barry 41 | - Contributor: @rramos 42 | - QA: 43 | - PM (required for user-facing): @rachelhamlin 44 | - UX(R) (required for user-facing swarms): 45 | 46 | ## Product Overview 47 | 48 | We want to provide a mechanism for SNT Holders to be able to vote on proposals and features using their token balance. 49 | 50 | Each token represents 1 vote, and the balance can be allocated proportionally between the different options a proposal may have, in order to determine the interest level and priorize features. 51 | 52 | 53 | ### Requirements & Dependencies 54 | 55 | The final goal for this DApp is to be managed via Liquid Democracy. Idea #172 needs to be implemented before the final iteration of this swarm is completed 56 | 57 | 58 | ### Minimum Viable Product 59 | 60 | Goal Date: 2018-07-29 61 | 62 | Description: 63 | For the initial delivery, these are the minimum features proposed: 64 | - UI to list all items subject to votation 65 | - UI to allow SNT holders to vote / cancel vote 66 | - UI to view details about an item 67 | - UI to create voting items by the contract owner 68 | - Use contracts from Idea #172 for creation of proposals and to handle voting. 69 | - After N blocks a votation is closed and results tabulated 70 | 71 | ### Iteration 1 72 | 73 | Goal Date: TBD 74 | 75 | Description: 76 | - Design / Prototypes are created 77 | - Design and layout of dApp is updated 78 | - SNT holders may create items to vote 79 | - Proposals may contain different options, and SNT can be allocated among them. 80 | 81 | ### Iteration 2 82 | 83 | Goal Date: TBD 84 | 85 | Description: 86 | - UI for vote delegation is created 87 | - Vote tabulation based on Liquid Democracy 88 | - Multiple choice polls can be created 89 | 90 | 91 | ## Success Metrics 92 | 93 | Initial emphasis is on deliver a working product with no bugs at contract level and no critical bugs for the UI 94 | 95 | - Items to vote on can be created 96 | - Users can browse on the different proposals 97 | - Users can vote with their SNT tokens 98 | - Users can cancel their vote 99 | - After a votation period ends, votes are tabulated correctly. 100 | 101 | ## Exit criteria 102 | 103 | - Launch voting DApp in the mainnet 104 | - Users are able to vote on ideas 105 | 106 | ## Copyright 107 | 108 | Copyright and related rights waived 109 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 110 | -------------------------------------------------------------------------------- /ideas/154-support-web3.js-library.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 154-web3 3 | title: Support web3.js library 4 | status: Completed 5 | created: 2018-04-09 6 | category: core 7 | lead-contributor: flexsurfer 8 | contributors: 9 | - flexsurfer 10 | - dmitryn 11 | - mandrigin 12 | - dshulyak 13 | - rachelhamlin 14 | exit-criteria: yes 15 | success-metrics: yes 16 | clear-roles: yes 17 | future-iterations: yes 18 | roles-needed: 19 | --- 20 | 21 | ## Preamble 22 | 23 | Idea: 154 24 | Title: Support web3.js library 25 | Status: Completed 26 | Created: 2018-04-09 27 | 28 | ## Summary 29 | Ensure that any DApp that works in Metamask also works in Status by providing web3.js library support. 30 | 31 | ## Swarm Participants 32 | - Lead Contributor: [@flexsurfer](https://github.com/flexsurfer) 33 | - Contributor: [@dmitryn](https://github.com/dmitryn) 34 | - Contributor: [@mandrigin](https://github.com/mandrigin) 35 | - Contributor: [@dshulyak](https://github.com/dshulyak) 36 | - Testing & Evaluation: 37 | - PM: [@rachelhamlin](https://github.com/rachelhamlin) 38 | - UX: N/A 39 | 40 | ## Product Overview 41 | 42 | A fundamental step in supporting the developer ecosystem is to ensure that any existing DApp loads and is operable in the Status browser. 43 | 44 | Users: 45 | 1. Developers who want to develop a new HTML DApp for Ethereum from scratch 46 | 2. Developers of existing HTML DApps that work on desktop with Metamask 47 | 3. Users exploring DApps in Status 48 | 49 | There are a number of bugs preventing this currently. In addition to resolving any known issues, we will provide support for the web3.js library. 50 | 51 | ### Product Description 52 | 53 | Developers testing on Status should find that any mobile-optimized HTML DApp is compatible. 54 | 55 | Users can load, log in to, and transact inside any DApp using the Status browser. 56 | 57 | ### Requirements & Dependencies 58 | 59 | - [X] [#3174](https://github.com/status-im/status-react/issues/3174): Some Android devices can't find web3 library 60 | 61 | - [X] [#2704](https://github.com/status-im/status-react/issues/2704): Personal sign message support (CryptoKitties blocker) 62 | 63 | - [X] [#784](https://github.com/status-im/status-go/issues/784): Contract handler not called after contract deployment 64 | 65 | - [X] [#3823](https://github.com/status-im/status-react/issues/3823): Sync calls are not supported in Status 66 | 67 | - [X] [#2479](https://github.com/status-im/status-react/issues/2479): web3 filters don't work with Status chat bot 68 | 69 | - [X] [#3824](https://github.com/status-im/status-react/issues/3824): [Blockchain Cuties](https://blockchaincuties.co ) does not load inside Status 70 | 71 | ### Minimum Viable Product 72 | 73 | Goal date: 74 | 75 | Description: 76 | - Fix known issues. 77 | - Support web3.js library v.0.20.3 78 | 79 | Testing days required: 80 | 81 | Swarm closed 2018-05-14. 82 | 83 | ## Exit Criteria 84 | - Test cases defined for web3.js v.0.20.3 85 | - Known issues closed 86 | 87 | ## Success Metrics 88 | - All tests pass QA 89 | - Every Selected DApp works (loads, logs in, transacts) 90 | 91 | ## Future Iterations 92 | - Support [web3.js 1.0](https://web3js.readthedocs.io/en/1.0/) 93 | 94 | ## Copyright 95 | 96 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 97 | 98 | -------------------------------------------------------------------------------- /ideas/254-ultra-light-client/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 254-ultra-light-client 3 | title: Integration of ULC in Status 4 | status: Draft 5 | created: 2018-05-02 6 | category: research 7 | lead-contributor: b00ris 8 | contributors: 9 | - b00ris 10 | - jeka 11 | - themue 12 | - zsfelfoldi (external) 13 | exit-criteria: yes 14 | success-metrics: yes 15 | clear-roles: yes 16 | future-iterations: yes 17 | --- 18 | 19 | ## Preamble 20 | 21 | Idea: 254-ultra-light-client 22 | Title: Integration of ULC in Status 23 | Status: Draft 24 | Created: 2018-05-02 25 | 26 | ## Summary 27 | 28 | Current LES is not yet optimized for ultra-light devices like mobile phones. So in the first step introduce 29 | the ULC addressing this kind of clients. 30 | 31 | ## Swarm Participants 32 | 33 | - Lead Contributor: @b00ris 34 | - Testing & Evaluation: TBD 35 | - Contributor: @jeka 36 | - Contributor: @themue 37 | - PM: @zsfelfoldi (external) 38 | - UX (if relevant): 39 | 40 | ## Product Overview 41 | 42 | Current LES is not optimized for usage on mobile phones. So Status is using Infura with all its assets and 43 | drawbacks. ULC is addressing ultra-light clients and distribution without dependency to central providers. 44 | Instead a network of trusted LES nodes acts as counterpart for the protocol. 45 | 46 | So Status is supporting the development and testing of ULC to accelerate integration into `go-ethereum` as 47 | well as into Status itself. 48 | 49 | ### Product Description 50 | 51 | - Research of ULC design 52 | - Definition and implementation of ULC 53 | - Integrate ULC in `statusd` and the `lib` 54 | - Documentation 55 | 56 | ### Minimum Viable Product 57 | 58 | Goal Date: 2018-07-02 59 | Working board: https://github.com/status-im/go-ethereum/projects/5 60 | 61 | Description: 62 | 63 | - [ ] New Ultra Light Client mode is added to patched LES 64 | - [ ] Integrate ULC with `status-go` with Status nodes as trusted nodes 65 | - [ ] Collect metrics (CPU, mem, disk, network I/O) when starting with a branch new install and after 1h of inactivity 66 | - [ ] Keep battery and network consumption at least as low as today with Infura 67 | 68 | ### Iteration 2018-05-21 - 2018-06-04 69 | 70 | Goal Date: 2018-06-04 71 | 72 | Description: 73 | 74 | - [x] Fix [downloader N/M validation](https://github.com/status-im/go-ethereum/issues/51) 75 | - [x] Fix [announce type on handshake](https://github.com/status-im/go-ethereum/issues/55) 76 | - [x] [ULC config refactoring](https://github.com/status-im/go-ethereum/issues/52) 77 | - [x] PR to `go-ethereum` 78 | 79 | ### Iteration 2018-06-04 - 2018-06-18 80 | 81 | Goal Date: 2018-06-18 82 | 83 | Description: 84 | [ULC milestone 2018-06-04](https://github.com/status-im/go-ethereum/milestone/1) 85 | 86 | 87 | ### Iteration 2018-06-18 - 2018-07-02 88 | 89 | Goal Date: 2018-07-02 90 | 91 | Description: 92 | [ULC milestone 2018-06-18](https://github.com/status-im/go-ethereum/milestone/2) 93 | 94 | ## Artifacts 95 | 96 | - None 97 | 98 | ## Success Metrics 99 | 100 | LES of `go-ethereum` is extended to use ULC with a similar or better use of bandwidth and CPU as Infura. 101 | 102 | ## Copyright 103 | 104 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 105 | 106 | -------------------------------------------------------------------------------- /ideas/095-les-service-model/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 095-les-service-model 3 | title: Adding a service model to LES 4 | status: Draft 5 | created: 2018-03-20 6 | category: research 7 | lead-contributor: @b00ris 8 | contributors: 9 | - themue 10 | - jeka 11 | - b00ris 12 | - zsfelfoldi (external) 13 | exit-criteria: yes 14 | success-metrics: no 15 | clear-roles: yes 16 | future-iterations: yes 17 | --- 18 | 19 | ## Preamble 20 | 21 | Idea: 095-les-service-model 22 | Title: Adding a service model to LES 23 | Status: Draft 24 | Created: 2018-03-20 25 | 26 | ## Summary 27 | 28 | Add the LES Service Model where clients can subscribe to higher quality services. Different payment models will 29 | be available, negotiation between client and full node is done via auctions based on demands and capacity. This 30 | way full node service provide are able to monetize the services they provide. LES will make the beginning, Whisper 31 | and Swarm may follow. 32 | 33 | ## Swarm Participants 34 | 35 | - Lead Contributor: @b00ris 36 | - Testing & Evaluation: TBD 37 | - Contributor: @jeka 38 | - PM: @zsfelfoldi (external) 39 | - UX (if relevant): 40 | 41 | ## Product Overview 42 | 43 | Right now all light clients are treated equal by the full nodes they connect. A future service model will 44 | introduce the separation between free and payed services. As outlined by Felföldi Zsolt: 45 | 46 | - LES will be available either as free or paid service, 47 | - paid service can guarantee availability and short response times, 48 | - client bandwidth demand fluctuates with time, good service quality requires reserve capacity, 49 | - for-profit LES servers can still give away their extra capacity for free (with lower priority than paid service), 50 | - free service is a good indicator of high bandwidth capacity and therefore the capability to provide good service, and 51 | - paying clients will prefer servers which already gave them free service so free service can act as an advertisement. 52 | 53 | Here Status supports the development and testing to make the service model become a part of *geth* and be 54 | integrated into Status. 55 | 56 | ### Remark 57 | 58 | For Status it also could become interesting to become a service provider offering payed full node services not only 59 | for own clients. This business case should be evaluated in an own swarm. 60 | 61 | ### Product Description 62 | 63 | Parts of the LES Service Model introduction are: 64 | 65 | - research, definition, and implementation of connection management system of paying clients for full nodes, 66 | - research, definition, and implementation of auctioning, 67 | - research, definition, and implementation of payment methods and models, 68 | - documentation. 69 | 70 | ### Minimum Viable Product 71 | 72 | Goal Date: TBD 73 | 74 | Description: 75 | 76 | - [ ] Auctioning protocol between client and full node is defined 77 | - [ ] Payment methods and interfaces are defined 78 | - [ ] Initial implementation validates auctioning and micropayment in automated tests 79 | 80 | ## Artifacts 81 | 82 | - [Information about Micropayment](micropayment.md) 83 | - [Logfile](log.md) 84 | - [Links](links.md) 85 | 86 | ## Success Metrics 87 | 88 | LES of `go-ethereum` is extended to provide micropayed services with a higher quality 89 | level as well as free services depending on capacity and configuration. 90 | 91 | ## Copyright 92 | 93 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 94 | 95 | -------------------------------------------------------------------------------- /ideas/320-keycard.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 320-keycard 3 | title: Status Keycard 4 | status: implementation 5 | lead-contributor: guylouis 6 | contributors: 7 | - Michele @bitgamma 8 | - Andrea @gravityblast 9 | - Dmitry @dmitryn 10 | - xFntesting @nastya 11 | - xFndesign @denis-sharpyn 12 | budget: 13 | - actual: xxx 14 | - estimate: yyy 15 | - currency: ETH/USD/SNT 16 | --- 17 | 18 | # Swarm proposal 19 | 20 | ## Summary and Goal(s) 21 | 22 | We want to give Status users control over their private keys, and offer them the possibilty to store them in a air-gapped secure device. This kind of control is provided by hardware wallets, however there is no hardware wallet on the market today that integrates with mobile apps, and hardware wallets are quite expensive. 23 | 24 | Javacard smartcards are a good platform to solve this issue: their inexpensive, provides very high level of physical security (CC EAL5+), and are contactless (NFC) and thus work with Android apps. 25 | 26 | Our goal is to: 27 | - manufacture such a smartcard, called Keycard, 28 | - standardize a protocol 'Keycard API' for integration of clients with smartcards securing access to crypto assets 29 | - propose an open source javacard applet 'Keycard applet' 30 | - integrate Keycard with Status app 31 | 32 | This swarm is about: 33 | - Keycard applet 34 | - Status software integration 35 | 36 | ## Communication 37 | 38 | [#status-keycard](https://get.status.im/chat/public/status-keycard) 39 | 40 | Weekly Sync, tuesday 11:00 AM Paris time 41 | 42 | Weekly meeting notes https://notes.status.im/BSmOfT4qSuWLLXS6AuxcXQ 43 | 44 | Team page https://notes.status.im/Uyg8wkVESjKyvwWAa19czQ?view 45 | 46 | ## Research 47 | 48 | **Keycard applet** 49 | 50 | closed 51 | 52 | **Status software integration** 53 | 54 | closed 55 | 56 | ## Specification 57 | 58 | **Keycard applet** 59 | 60 | closed 61 | 62 | **Status software integration** 63 | 64 | The use cases for the Status integration are: 65 | 1. sign transaction by tapping card + entering PIN 66 | 2. login into account by tapping card and entering PIN 67 | 3. export of the whisper key from the card to the app (goal : not store the whisper private key in Flash at anay time on the app) 68 | 4. export of the password used to encode the database from the card to the app 69 | 70 | 71 | UPDATE 15012019 72 | 73 | It has been decided to leave Keycard card upgradeable to allow software upgrade of Keycard during its lifecycle. This has affected our state diagrams and specifications. Sepcifications (see below)have been updated and approvded by the team on wk2 2019. 74 | 75 | Specifications reference document (UI flows + State Diagrams) 76 | https://bit.ly/2NdxoUB 77 | 78 | 79 | ## Implementation 80 | 81 | **Keycard applet** 82 | 83 | closed 84 | 85 | **Status software integration** 86 | 87 | Alpha stage: up to 28/02/2019 88 | Beta stage: 01/03/2019 (Beta success consists of functional availability of use cases 1-2-3-4) 89 | 90 | 15012019 UPDATE 91 | - detailed status in weekly meeting notes and pivotal tracker 92 | - overview 93 | - Done: card initialization, account creation 94 | - In progress: card settings (change PIN, reset cards, unpair), decoupling of whisper and private key in go 95 | - To be done : card login, sign transaction, import account 96 | 97 | ## Maintenance 98 | 99 | 100 | 101 | ## Copyright 102 | 103 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 104 | -------------------------------------------------------------------------------- /ideas/167-extended-automated-testing-for-continuous-delivery/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 167-automated-testing 3 | title: Functional automated testing as a part of Continuous Delivery process 4 | status: Limbo 5 | created: 2018-04-12 6 | category: core 7 | lead-contributor: antdanchenko 8 | contributors: 9 | - antdanchenko 10 | - yevh-berdnyk 11 | - lukaszfryc 12 | - Serhy 13 | - asemiankevich 14 | exit-criteria: yes 15 | success-metrics: yes 16 | clear-roles: yes 17 | future-iterations: yes 18 | roles-needed: 19 | --- 20 | 21 | ## Preamble 22 | 23 | Idea: 167 24 | Title: Functional automated testing as a part of Continuous Delivery process 25 | Status: In Progress 26 | Created: 2018-04-12 27 | 28 | ## Summary 29 | For automated testing to be a part of CD process we need to: 30 | - increase coverage 31 | - increase reliability 32 | - provide visible results on daily basis 33 | 34 | ## Swarm Participants 35 | - Lead Contributor: @antdanchenko 36 | - Testing & Evaluation: @antdanchenko 37 | - Contributor: @yevh-berdnyk 38 | - Contributor: @lukaszfryc 39 | - Contributor: @Serhy 40 | - Contributor: @asemiankevich 41 | - PM: 42 | 43 | ## Product Overview 44 | Extended set of automated tests which will run against each nightly build in order to provide results via TestRun in TestRail + short summary via Slack notification 45 | As result during nightly build testing a tester should execute only those tests which are not covered by automation in the same TestRun 46 | In case of failure in automated test a tester should add an appropriate status to the test (see `An option to review results should be added for each test via adding 4 statuses to TestRail` in `Product Description` section) 47 | Actual sanity test case which is running against each PR will keep running without changes 48 | 49 | 50 | ### Product Description 51 | - Each automated test suite should be based on existing set of cases from TestRail for tracking percents of functional test coverage 52 | - Each automated test should be the reflection of a test case from TestRail 53 | - Results of each automated test from a build should be provided via TestRun in TestRail and linked to the appropriate case 54 | - An option to review results should be added for each test via adding 4 statuses to TestRail: 55 | - feature changed (for changed product behavior) 56 | - known bug (link to the issue) 57 | - false failure (bug in test) 58 | - infrastructure issue 59 | 60 | ### Minimum Viable Product 61 | Goal Date: 2018-05-01 62 | 63 | - New test suite is add to TestRail (`Functional tests for Nightly Build`) 64 | - 80% of test cases for nightly build test suite from TestRail are covered by automated tests 65 | - Extended set of automated tests is running against each nightly build 66 | - Detailed test results are provided in TestRail via TestRuns + short summary via Slack notification 67 | 68 | Testing Days required: 10 69 | 70 | ## Success Metrics 71 | - 80% of functional test cases in `Functional tests for Nightly Build` are covered 72 | - not more than 10% of tests are failing due to an issue with a test 73 | - results are visible and understandable for all status-react team members 74 | 75 | ## Exit criteria 76 | Extended set of automated tests covers 80% of functional nightly test cases from TestRail 77 | The set is running against each nightly build 78 | Results are visible in TestRail as TestRuns, also summary is visible in Slack notifications 79 | 80 | ## Copyright 81 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 82 | -------------------------------------------------------------------------------- /ideas/122-sob-metrics.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 122-sob-metrics 3 | title: Open Bounty - Platform Usage Metrics 4 | status: Limbo 5 | created: 2018-04-04 6 | category: openbounty 7 | lead-contributor: arash009 8 | ontributors: 9 | - arash009 10 | - siphiuel 11 | exit-criteria: yes 12 | success-metrics: yes 13 | clear-roles: yes 14 | future-iterations: yes 15 | roles-needed: 16 | --- 17 | 18 | ## Preamble 19 | 20 | Idea: 122-sob-metrics 21 | Title: Open Bounty - Platform Usage Metrics 22 | Status: In progress 23 | Created: 2018-04-04 24 | Related: 25 | 26 | ## Summary 27 | 28 | To identify the successful use of a platform, it's important and imperative to be able to measure its usage. As the Open Bounty platform continues to grow and evolve, its important to be able to track its growth, and make data-driven decisions. 29 | 30 | One of the key objectives of Open Bounty is to increase the usage of the platform. The purpose of this swarm is to build the tools and means necessary to capture these metrics and be able to report on them on a regular basis. 31 | 32 | ## Swarm Participants 33 | 34 | - Lead Contributor\PM: @arash009 (Arash) 35 | - Contributor: @siphiuel (Vitaliy) 36 | - Testing and QA: @arash009 (Arash) 37 | 38 | ## Product Overview 39 | 40 | This swarm will create the mechanism to capture **five** specific metrics on the usage of Open Bounty (specific criteria for each metric yet to be defined): 41 | 42 | - **Value transacted** — This metric is to capture the **$USD equivalent** of total tokens that have been paid out in a given timeframe (daily, weekly, monthly, annual) 43 | - **Active bounty creators** — This metric is to capture the **Monthly Active Contributors** who have posted a minimum of 1 bounty in the previous 30 days. 44 | - **Active bounty hunters** — This metric is to capture the **Monthly Active Contributors** against each organization who have succesfully completed a bounty. 45 | - **Unique pageviews** — This metric is to capture the **Unique Monthly Pageviews** to the Home Page (https://openbounty.status.im/) and the Open Bounties page (https://openbounty.status.im/app#/) 46 | - **Activation** - This metric is to capture the percentage of users who have used the platform to post or solve a bounty within XX days after joining (e.g. 30 days) 47 | 48 | The collection of these metrics is to be automated, however their reporting and sharing can be manual, or basic automation, with future iterations looking at full automation/analytics. 49 | 50 | ## Success Criteria 51 | 52 | #### Milestone 1 - '13 April 2018' 53 | - Swarm participants identified 54 | - Swarm kick off held 55 | - Detailed specifications for each metric identified and documented 56 | - User stories and project board setup 57 | - Effort estimate and high-level schedule established 58 | 59 | #### Milestone 2 - '27 April 2018' 60 | - All reports have been built and tested 61 | 62 | #### Milestone 3 - '11 May 2018' 63 | - Graphical reports that represent the above metrics over time built and tested 64 | 65 | #### Milestone 4 - '25 May 2018' 66 | - Create above reports to be made available to bounty creators for their repositories 67 | 68 | ## Exit Criteria 69 | 70 | This swarm will be deemed successful and be closed upon the delivery of the above milestones. If any of the above milestones cannot be completed within a 2-week window, they will be dropped from this swarm and parked for possible future development. 71 | 72 | ## Success Metrics 73 | 74 | Tools and means are avilable to measure Key Results 75 | 76 | ## Copyright 77 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 78 | -------------------------------------------------------------------------------- /ideas/121-swarm-compensation/models.md: -------------------------------------------------------------------------------- 1 | A list of potential models to explore in experiments as part of this swarm 2 | 3 | - [Bountify All](#bountify-all) 4 | - [Grant & Burn](#grant--burn) 5 | 6 | 7 | # Bountify All 8 | 9 | ## Problem 10 | 11 | We have a lot of issues in various Status repositories. These could to a large 12 | extent be solved by the larger community, as well as incentivized according to 13 | priority by core contributors. 14 | 15 | Additionally, there's no reward for putting bounties on issues, which leads to 16 | an uphill battle in terms of bounty growth (see Andy's slides Town Hall). 17 | 18 | ## Solution 19 | 20 | Create a swarm that will put a bounty on all outstanding issues and give 21 | bountifier/issue creator a reward (finder's fee) for doing so, assuming the 22 | issue gets solved. 23 | 24 | The finder's fee can be ad hoc in inital implementation, and if proven 25 | successful it can be encoded in a SOB contract. 26 | 27 | There are five objections for putting a bounty on all issues as far as I 28 | can see: 29 | 30 | 1. **Issue is not well-defined enough** 31 | 32 | Then it should be closed. 33 | 34 | 2. **Issue requires privileged access** 35 | 36 | OK exception - mark with label 'closed-flow' and move on. 37 | 38 | 3. **Cost** 39 | 40 | Currently we have around 500 issues in status-react. Assuming they are all good 41 | issues, and they get rewarded an average of $100 _if solved_, that's $50k. This 42 | isn't an unreasonable amount, assuming we actually solve these issues. 43 | 44 | Additionally, we can put an artificial growth limit on this. So first week 20 issues, 45 | next week 22, etc. 46 | 47 | 4. **Perverse incentives** 48 | 49 | This is only true for core contributors, and we aren't currently operating in a 50 | byzantine environment. So this can be solved simply by a basic honor system, and 51 | simple soft rules like not solving bounties you yourself put up. 52 | 53 | 5. **Effort involved** 54 | 55 | The finder's fee of 10% (or 5% for issue creator 5% for bounty creator) 56 | hopefully solves this issue. This is the hypothesis this swarm would test. 57 | 58 | ## Future work 59 | 60 | 1. Automatically put bounties on all new issues, given some conditions 61 | 62 | 2. Instead of spitballing bounty size, use issue size and priority to determine 63 | bounty size. E.g. a matrix where bounty size can be 1\*3=3 (small, high prio), 64 | 3\*3=9 (big, high prio). 65 | 66 | 67 | # Grant & Burn 68 | 69 | 1. A user can request funds for a certain time interval, e.g. SNT10.000 for the next 30 days. 70 | - Usually this request will be tied to a specific proposed project/piece 71 | of work but that should be treated as implementation detail. 72 | 2. Other people "Supporters" can pay into this contract until the threshold is reached 73 | 3. After 30 days all supporters can either do 74 | - A) Nothing, their stake will be paid out to the requesting user in full after 10 more days. 75 | - B) Burn half their stake and receive back the other half. 76 | 77 | Burning half the money is a big statement and people won't do that 78 | lightly — it's useful to flag bad actors though. The more usual case 79 | would be just not working with the user again (which is an acceptable 80 | outcome that should not have negative consequences for either side). 81 | 82 | Allowing supporters to delegate the burning decision to someone else 83 | could be interesting in making this work for swarms as well. Swarm 84 | lead could be delegate for other people on the team while the swarm 85 | lead still remains accountable to original supporters. This might 86 | create a weird dynamic when the swarm lead doesn't get his chunk 87 | though. 88 | -------------------------------------------------------------------------------- /ideas/071-low-traffic.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 071-low-traffic 3 | title: Low traffic consumption(techncal) 4 | status: Aborted 5 | created: 2018-01-25 6 | category: core 7 | lead-contributor: JekaMas 8 | contributors: 9 | - JekaMas 10 | - annadanchenko 11 | - b00ris 12 | - PombeirP 13 | - feuGeneA 14 | - yenda 15 | exit-criteria: no 16 | success-metrics: yes 17 | clear-roles: yes 18 | future-iterations: no 19 | --- 20 | 21 | ## Preamble 22 | Idea: 71-low-traffic 23 | Title: Low traffic consumption(technical) 24 | Status: Aborted 25 | Created: 2018-01-25 26 | 27 | ## Summary 28 | 1) Issues related to statusgo network overhead 29 | 30 | ## Swarm Participants 31 | - Lead Contributor: @JekaMas (40h/w) 32 | - Testing & Evaluation: @annadanchenko (?) 33 | - Go Contributor: @b00ris (40h/w) 34 | - Go Contributor: @PombeirP (30h/w) 35 | - Go Contributor: @feuGeneA (30h/w) 36 | - Clojure Contributor: @yenda (20h/w) 37 | 38 | ## Product Overview 39 | Measure network overhead for main `statusgo` usage scenarios. 40 | Identify and fix the bottlenecks. 41 | 42 | ### Product Description 43 | Main use cases to track: 44 | 1) node was started in background(sync was ended) 45 | 1.1) node was started in background(sync was ended) + whisper 46 | 2) node was started in background(sync is running) 47 | 2) node was started in background(upstream) 48 | 2.1) node was started in background(upstream) + whisper 49 | 3) one chat 1-1. sending messages(60rpm) 50 | 4) 60 chats 1-1. receiving messages(10rpm per chat) 51 | 5) 10 group chats(60 rpm per chat) 52 | 6) 100 chats 1-1. 30 group chats. receiving historic messages for last day(100 messages per chat) 53 | 54 | 55 | Many topics problem https://github.com/status-im/status-react/issues/2964 56 | Whisper network overhead https://github.com/status-im/status-react/issues/2931 57 | 58 | ### Requirements & Dependencies 59 | Part of https://github.com/status-im/ideas/issues/55 60 | Related to ultralight client 61 | 62 | ## [Iterations](#iterations) 63 | ### Research to define further steps and related metrics. Iteration 1. 64 | Goal Date: 2018-02-13 65 | Description: 66 | * Define reasonable steps to reduce network overhead 67 | * We have tools to measure CPU usage and network of statusgo for main use cases to track progress(part of https://github.com/status-im/ideas/issues/22)(status-go tasks TBD) 68 | * Success metrics for the issue was defined 69 | 70 | ### Minimum Viable Product. Iteration 2. 71 | Goal Date: 2018-02-26 72 | * Reduce Status mean traffic to 50-100Mb/day (2-4 Mb/hour) from current 10-20Gb/day. This relates only to online chatting without offline mailboxing 73 | * Make WhisperV6 production ready and switch to it https://github.com/status-im/status-go/issues/634 74 | 75 | ### Acceptable traffic consumption. Iteration 3. 76 | Goal Date: 2018-03-05 77 | * Reduce Status mean traffic to 10-40Mb/day(0.5-2 Mb/hour) 78 | * Many topics problem resolved https://github.com/status-im/status-react/issues/2964 79 | * Many topics used for topics subscription 80 | * Setup maximum Whesper's peers 81 | 82 | ### Acceptable traffic consumption at the start of Status. Iteration 4. 83 | Goal Date: 2018-03-26 84 | * Reduce traffic overhead on a Status start 85 | * Many topics used for offline mailboxing 86 | * Offline mailboxing sends only messages by given period of time (from-to timestamps) 87 | * Update mail server to send only messages that used doesn't receive yet https://github.com/status-im/status-go/issues/690 88 | 89 | ### Minimal offline mailboxing overhead. Iteration 5. 90 | Goal Date: 2018-04-09 91 | * Further traffic overhead decrease on a Status start 92 | * Use new offline mailboxing API on Clojure script side. 93 | 94 | ## Success Metrics 95 | 5 Mb/day of traffic 96 | -------------------------------------------------------------------------------- /ideas/312-swarm-janitors.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #312-janitors 3 | title: Swarm Janitors 4 | status: research 5 | lead-contributor: jarrad 6 | contributors: 7 | - nabil 8 | - oskar 9 | - hester 10 | - rachel 11 | budget: 12 | - actual: xxx 13 | - estimate: yyy 14 | - currency: ETH 15 | --- 16 | 17 | # Swarm proposal 18 | 19 | ## Summary and Goal(s) 20 | The Status Janitors oversee the delivery and completion of the [Status white paper](https://status.im/whitepaper.pdf) by the end of Q1, with a hard deadline of the end of Q2 2019. 21 | 22 | ## Communication 23 | (required) 24 | `status channel (same as swarm id)`: [#312-janitors](https://get.status.im/chat/public/312-janitors) 25 | `sync frequency`: Weekly Sync, Monday 10am UTC 26 | 27 | Meeting notes: https://notes.status.im/384OqZPUR1-viP7l2Fxeew?edit 28 | 29 | ## Research 30 | Completion by the end of January, 2019. 31 | 32 | Goals of Specifications: 33 | - **Document our way of working** 34 | - Swarm Framework 35 | - Define critical path for completing the swarm goal 36 | - SNT utility swarms 37 | - Identify essential non-SNT swarms (e.g. onboarding, product teams) 38 | - Report organisational progress regularly during Town Hall 39 | - Regular check-ins with swarms 40 | 41 | _Unknowns_ 42 | * Security audit timing 43 | * [NN] What do we want to audit? Our entire codebase? status-go and our smart contracts only? status-react? DApps should probably have their own securit audit (TN and DAO) 44 | * Launch (i.e. public app store) release scope 45 | * [NN] Can be determined once we see the critical path 46 | * [OT] Checking with Corey as well 47 | * Software for process management 48 | * Resource allocation to get swarm cost 49 | * Global view of state 50 | * Critical path 51 | * Monte Carlo simulations 52 | 53 | ## Specification 54 | 55 | TODO: Update based on research phase. 56 | 57 | **Timeline** 15th Jan to complete specifications of all > P2 features below. 58 | **Swarm Framework**: https://github.com/status-im/swarms 59 | **SNT Utility Swarms**: 60 | * Teller Network [P0] (Iuri and co + Wallet for hooks) 61 | * Tribute to Talk [P0] (Chat swarm) 62 | * Anti-spam [P2] 63 | * Sticker Market [P0] (Extensions) 64 | * Network Incentivisation [P1] (Core) 65 | -- [OT] With this, do we mean a possibly half-baked solution assuming the existing protocol? One concern would be if we change things around later on, but we can also provide this and clarify it isn't great and will likely be replaced. It depends on how much weight we put on ticking off boxes in whitepaper. 66 | * DApp store / Discover [P1] (Andy/DevRel) 67 | * User acquisition engine [P2] 68 | * Web of Trust / Trustlines [P3] 69 | 70 | -- Get legal guidance on what is acceptable for completion of the White Paper -- 71 | 72 | **Essential Swarms**: 73 | 1. DAO (Iuri and co) 74 | 2. Onboarding/Patient Zero/Polish (Core/Relevant teams) 75 | 3. Status Protocol (Oskar and co) 76 | 77 | **Team Structures** 78 | - Core (Igor) 79 | - Chat (Eric) 80 | - Wallet (Goran) 81 | - DApp browser (Julien) 82 | - Desktop (?) 83 | - Keycard (Guy-Louis) 84 | 85 | ## Implementation 86 | **Timeline**: 87 | * Soft deadline - EOQ1 2019 88 | * Hard deadline - EOQ2 2019 89 | 90 | > All swarm contributors should test and break the implementation, especially developers 91 | 92 | For above swarms to be in research phase: https://github.com/status-im/swarms/issues/338 93 | 94 | (required) 95 | `document progress` 96 | 97 | (optional) 98 | `townhall demo` 99 | 100 | ## Maintenance 101 | 102 | `lead-contributor`,`post-mortems` 103 | 104 | ## Copyright 105 | 106 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 107 | -------------------------------------------------------------------------------- /ideas/225-status-index.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 225-status-index 3 | title: Status Index 4 | status: Draft 5 | created: 2018-04-27 6 | lead-contributor: yenda 7 | contributors: 8 | - 9 | - 10 | - 11 | exit-criteria: no 12 | success-metrics: no 13 | clear-roles: no 14 | future-iteration: no 15 | roles-needed: 16 | - Dev 17 | - Designer 18 | - Community 19 | okrs: 20 | - 21 | - 22 | --- 23 | 24 | ## Preamble 25 | 26 | Idea: 000-status-index 27 | Title: Status Index 28 | Status: Draft 29 | Created: 2018-04-27 30 | 31 | ## Summary 32 | 33 | We have a growing number of very useful standalone webpages that are providing valuable 34 | informations and services. 35 | 36 | Examples of those are: 37 | - cluster visualization, 38 | - cluster status, 39 | - history of the #status channel on the different whisper networks, 40 | - nightly build QR codes page (https://status-im.github.io/nightly/) 41 | - status.im people list (https://rawgit.com/jacqueswww/b5460887fe86871434dcef833fa00c92/raw/status_people.html) 42 | - documentation 43 | 44 | The goal of this swarm is to build an index of these pages so that they can be listed 45 | and easily accessed from a single place. We also want to make sure that each of these 46 | pages are documented to make it easy to reproduce them or for someone other than their 47 | creator to contribute. 48 | 49 | ## Current status 50 | 51 | - weekly sync calls tbd 52 | 53 | ## Swarm Participants 54 | 55 | - Lead Contributor: yenda 56 | - Evaluator (defaults to lead contributor): 57 | - Contributor: 58 | - Contributor: 59 | - QA: 60 | - PM (required for user-facing): 61 | - UX(R) (required for user-facing swarms): 62 | 63 | ## Product Overview 64 | 65 | The purpose of this Swarm is to build an index of all the standalone webpages that 66 | have been built by various members of the team and should be made accessible via a 67 | simple single directory page. We will evaluate cloud/container provider to host/run 68 | those websites as well. 69 | 70 | It also aims at pushing production of documentation to make it easier to contribute to 71 | this projects and troubleshoot them. 72 | 73 | ### User Stories 74 | 75 | > What user stories are you solving? 76 | As as status core developper, I have troubles with messaging, I suspect the cluster 77 | to be responsible, I want to be able to go to index.status.im and find the page that 78 | will show me the current status of the cluster. 79 | 80 | As a status community member, I want to create a bot that interacts with status clients 81 | with status communication protocol. I want to be able to easily find the documentation 82 | of the communication protocol by checking index.status.im 83 | 84 | As a status community member, I want to improve the static website rendering status 85 | ideas repository. I want to be able to check on index.status.im and find the documentation 86 | on how this website is built so that I can contribute. 87 | 88 | ### Security and Privacy Implications 89 | 90 | None 91 | 92 | ## Dates 93 | 94 | Weekly sync call tbd 95 | 96 | ### Minimum Viable Product 97 | 98 | > Mandatory, completes the Idea in the fastest route possible, can be hacky, 99 | > needed to feel progress. See https://imgur.com/a/HVlw3 100 | 101 | Goal Date: 102 | 103 | Description: 104 | 105 | ### Iteration 1 106 | 107 | Goal Date: 108 | 109 | Description: 110 | 111 | ## Success Metrics 112 | 113 | - In-org survey shows 80+% of the team is aware of the existence of the page 114 | 115 | ## Exit criteria 116 | 117 | - The index web page is online at index.status.im 118 | 119 | ## Supporting Role Communication 120 | 121 | > Once Requirements and Goals are fleshed out, then it should be communicated to 122 | > supporting organelles if required 123 | 124 | ## Copyright 125 | 126 | Copyright and related rights waived 127 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 128 | -------------------------------------------------------------------------------- /ideas/313-sticker-market/readme.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #313-sticker-market 3 | title: Sticker Market 4 | status: implementation 5 | lead-contributor: Julien/Rachel 6 | contributors: 7 | - Andrey 8 | - Julien 9 | - Nastya 10 | - Rachel 11 | - Hester 12 | budget: 13 | - actual: $21k 14 | - estimate: yyy 15 | - currency: USD 16 | --- 17 | 18 | Sticker Market Swarm Proposal 19 | === 20 | 21 | ## Summary and Goals 22 | 23 | Stickers are a must-have for any messenger, particularly with Asian markets in mind. 24 | 25 | The goal of the Status sticker market is two-fold: 26 | 27 | 1) Allow users to buy and use stickers in chat using SNT. 28 | 2) Allow creators to sell stickers permissionlessly through a curated marketplace, for SNT. 29 | 30 | For the initial scope, the focus is on use case #1. 31 | 32 | We can commission a set of stickers to populate the marketplace starting out. 33 | 34 | ## Contributors 35 | 36 | - Julien 37 | - Andrey 38 | - Nastya 39 | - Ricardo 40 | - Maciej 41 | 42 | (+ Janitor swarm) 43 | 44 | ## Communication 45 | 46 | `status channel`: [#313-sticker-market](https://get.status.im/chat/public/313-sticker-market) 47 | 48 | `sync schedule`: biweekly sprint planning, ad hoc meetings as needed 49 | 50 | `Pivotal project:` https://www.pivotaltracker.com/projects/2231918 51 | 52 | `Meeting notes:` https://notes.status.im/wyjNCxeURu6lYSwWGh3biw 53 | 54 | `Research notes:` https://notes.status.im/stickers-market-research 55 | 56 | ## Latest 57 | 58 | Monday, 11/2 59 | - Sticker UI is complete 60 | - Andrey working on contract/UI interface 61 | - Illustrator hired 62 | - [Community contest planning](https://docs.google.com/document/d/1LxVHnWzdS9D1xO5b6lcferKX8xeIySzQ95u5eLZh8Q0/edit?ts=5c61c866) underway 63 | 64 | Friday, 1/2 65 | - First iteration of UI complete 66 | - Design issues identified by Maciej 67 | - Rachel talking with sticker illustrators 68 | - Ricardo making final changes to contract to: 69 | - Allow multiple categories per pack 70 | - Include a function to globally set a burn percentage. One more option: global fee to all packs, only controller can set it. 71 | - Add new contract state restricting all market functions to controller but “buyToken” 72 | 73 | ## Research 74 | 75 | `Timing`: wrap on 28/12 76 | 77 | `References`: LINE & Kakao are two of the best sticker markets. Looking at these two alone can give ample guidance on great sticker market UX. Telegram another worthy reference. 78 | 79 | `Initial stories to inform technical research`: 80 | - As a user, I want to view and select stickers from my stickers within a chat. 81 | - I want to send and receive stickers in chat. 82 | - I want to buy new stickers via a marketplace accessible from chat.
83 | --
84 | - As a creator, I want to push my stickers to the market without waiting for approval. 85 | - I want my stickers to be hosted in a decentralized way. 86 | - I want my stickers to be protected from free use/stealing. 87 | 88 | `Research questions`: 89 | - What are the pros & cons of implementing as an extension vs. native feature? 90 | - Does one smart contract handle...? 91 | - Price setting 92 | - Payment from users 93 | - Payout to creators 94 | - Which audience are we designing these stickers for? How should character design be informed? 95 | - What's the cost to commission 1-3 initial sticker packs? 96 | - Sticker usage: 97 | - How many sets do people own on average? 98 | - How many do they use? 99 | - What makes certain characters popular? 100 | - etc. 101 | 102 | ## Specification 103 | 104 | ## Implementation 105 | ### 21st January Update 106 | - Finalizing specs for registry contract 107 | - Basic UI POC 108 | 109 | ### 4th February Update 110 | - Finalized specs 111 | - Contract implemented and deployed on Ropsten 112 | - Awaiting audit info 113 | - First stage of MVP UI merged 114 | - In talks with sticker illustrators 115 | 116 | 117 | 118 | 119 | ## Maintenance 120 | 121 | ## Copyright 122 | Copyright and related rights waived via CC0. 123 | -------------------------------------------------------------------------------- /ideas/322-dao.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #322-Dao 3 | title: DAO 4 | status: research 5 | lead-contributor: Barry @bgits 6 | contributors: 7 | - Barry @bgits 8 | - Iuri @iurimatias 9 | - Jarrad @jarradhope 10 | - Ricardo @3esmit 11 | - Richard @richard-ramos 12 | budget: 13 | - actual: $15k 14 | - estimate: yyy 15 | - currency: USD 16 | --- 17 | 18 | 19 | DAO 20 | = 21 | 22 | ## Summary and Goals 23 | 24 | One major drawback in legacy social networks is the lack of influence their users possess over the networks themselves. They are often powerless in having a say on how the platform evolves. We aim to democratise this power, giving stakeholders a direct influence over all decisions within the network, including how the software is developed with voting and allocation of funds via liquid pledging 25 | 26 | #### Goals 27 | - Funding done on the mainnet. A goal is to have funds currently in the multisig of the GMBH to start moving to DAO’s for allocation to projects. 28 | 29 | 30 | ## Contributors 31 | 32 | - Barry @bgits 33 | - Iuri @iurimatias 34 | - Jarrad @jarradhope 35 | - Ricardo @3esmit 36 | - Richard @richard-ramos 37 | 38 | (+ Janitor swarm) 39 | 40 | ## Communication 41 | 42 | - `status channel`: #status-dao 43 | - `sync schedule`: brainstorming on Mondays / stand ups on Wednesday 44 | - `pivotal link`: https://www.pivotaltracker.com/n/projects/2231548 45 | - `research notes`: #status-dao 46 | - `github repo`: 47 | - - https://github.com/status-im/liquidpledging/tree/embark-dapp 48 | - - https://github.com/status-im/snt-voting 49 | 50 | ## Research 51 | 52 | - Consider using Aragon for DAO related functionality. Currently Aragon does not support the delegation chain used by Liquid Pledge, however this is something that could be built by us. This also promotes collaboration between organizations, reuse of expertise, and avoids reinventing the wheel. 53 | 54 | - Liquid Pledge uses Solidity < `0.5.0`. Migrating to 0.5.0 would make debugging easier thanks to revert exceptions including an error message. However, the project uses OpenZeppelin and Aragon's contracts which would make the migration to `0.5.0` more complicated. 55 | 56 | - What information is important to be displayed to funders, delegates and projects? 57 | 58 | - What is the ideal specification for a "Pledge"? 59 | 60 | #### Key assumption to test: 61 | - Voting is described as part of governance in the Status whitepaper. The voting dapp is currently used as a signaling tool, and it does not have in-chain consequences. Will voting be used also for project funding? (via topic democracy or other mechanism) 62 | - Principles signing should be required in order to access the funds. A plugin could be made for this, or in case identities are implemented, maybe a Claim could be created for an identity once the principles are signed. 63 | - Are delegates needed? 64 | - Is directly funding a specific purpose Aragon DAOs from the primary multisig easier to manage? 65 | 66 | ## Specification 67 | TODO 68 | 69 | ## Implementation 70 | 71 | #### Initial Sprint 72 | - *Continue the work of @perissology of migrating Giveth's project to Embark*: The migration to Embark has been a process that has not been 100% straightforward but any issues raised has been notified to and addressed by the Embark team. This has had the beneficial effect of making the framework even more robust. 73 | 74 | - *Create a demo frontend that implements the main work flow*: a Demo UI has been built, following the unit tests of the liquid pledge project. Projects can be funded, and pledges created and delegated. 75 | 76 | - *Working proof of concept on Rinkeby Testnet* 77 | 78 | #### Feb 4th Update 79 | - Event Sourcing & Persistence solution (watermelon) 80 | - Liquid-funding is in the implementation phase. ETA is by the end of Q1. 81 | - Contracts are deployed on Rinkeby testnet. Client side data persistence + DB is implemented which gives the dapp much faster load times and flexible querying capabilities for the data generated by LF. 82 | 83 | 84 | ## Maintenance 85 | TODO 86 | 87 | ## Copyright 88 | 89 | Copyright and related rights waived via CC0. 90 | -------------------------------------------------------------------------------- /ideas/170-wallet-improvements.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 170-wallet-improvements 3 | title: Wallet Improvements 4 | status: Limbo 5 | created: 2018-04-13 6 | category: core 7 | lead-contributor: goranjovic 8 | contributors: 9 | - goranjovic 10 | - asemiankevich 11 | - chadyj 12 | - denis-sharypin 13 | - hesterbruikman 14 | - jpbowen 15 | exit-criteria: yes 16 | success-metrics: yes 17 | clear-roles: yes 18 | future-iterations: yes 19 | okrs: 20 | - "[P0]: Objective: Beta is launched successfully" 21 | - "[P3]: >20% of users send a transaction" 22 | --- 23 | 24 | ## Preamble 25 | 26 | Idea: 170 27 | Title: Wallet Improvements 28 | Status: In Progress 29 | Created: 2018-04-13 30 | 31 | ## Summary 32 | 33 | Status Wallet does not fully support ERC20 tokens (requesting and transaction history not available) 34 | and generally the transactions UX is different between Chat and Wallet. The intention of this swarm 35 | is to wrap up those inconsistencies and study and improve wallet and transaction UX problems and 36 | limitations to make the wallet experience great. 37 | 38 | ## Swarm Participants 39 | - Lead Contributor: [@goranjovic](https://github.com/goranjovic) 40 | - Contributor: 41 | - Testing & Evaluation: [@asemiankevich](https://github.com/asemiankevich) 42 | - PM: [@chadyj](https://github.com/chadyj) 43 | - UX: [@denis-sharypin](https://github.com/denis-sharypin) 44 | - UX: [@hesterbruikman](https://github.com/hesterbruikman) 45 | 46 | ## Product Overview & Description 47 | 48 | Add native support for all ERC20 token operations and rudimentary support for ERC721 tokens. 49 | 50 | ## Use Cases 51 | 52 | - As a user I want to see my ERC20 transactions in history of transactions (Wallet -> Transaction History). 53 | - As a user I want to distinguish my ERC20 transactions easily in History of transactions. 54 | - As a user I want to understand clearly whom i sent transaction to (ERC20, ETH, etc). 55 | - As a user I want to request erc20 tokens in 1x1 chat. 56 | - As a user I want to send erc20 tokens in 1x1 chat by responding to appropriate request. 57 | - As a user I want to send erc 20 tokens in a group chat. 58 | - As a user I want to send erc20 tokens in a group chat by responding to appropriate request. 59 | 60 | 61 | ### Requirements & Dependencies 62 | 63 | - Possibly depends on extensions swarm for integrations with Chat 64 | - Related to #163 - support ERC721 tokens 65 | 66 | 67 | ### Minimum Viable Product 68 | 69 | Goal Date: 2018-05-12 70 | 71 | Description: 72 | 73 | - Support for ERC20 transaction history in Wallet. 74 | - UX improvements derived from UXR sessions 75 | 76 | ### Iteration 1 77 | 78 | Goal Date: 2018-05-04 79 | 80 | Description: 81 | 82 | - Wallet spring cleanup - triage, fix or remove reported bugs so far - https://github.com/orgs/status-im/projects/24 83 | - Compile UX insights into design decisions for the next iterations 84 | - Update the subsequent iterations accordingly 85 | 86 | ### Iteration 2 87 | 88 | Goal Date: 89 | 90 | Description: 91 | - Support for ERC20 tokens in `/send` and `/request` chat command API. 92 | This iteration covers the prerequisites on the Command API side. 93 | - UXR sessions and recommendations 94 | 95 | ### Iteration 3 96 | 97 | Goal Date: 98 | 99 | Description: Integration of Send and Request operations between Wallet and Chat. 100 | 101 | 102 | ### Iteration 4 103 | 104 | Goal Date: 105 | 106 | Description: ERC721 support in Wallet 107 | 108 | Testing days required: 109 | 110 | ## Exit Criteria 111 | 112 | - Display ERC20 token transfers in transaction history 113 | - Send ERC20 tokens from chat 114 | - Request ERC20 tokens from wallet and chat 115 | - Unified Chat/Wallet transaction UX 116 | - ERC721 support in Wallet 117 | 118 | ## Success Metrics 119 | 120 | - All exit criteria met 121 | - UXR retested with measurable improvements 122 | 123 | ## Copyright 124 | 125 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 126 | 127 | -------------------------------------------------------------------------------- /ideas/061-app-structure-refinement.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 061-structure refinement 3 | title: App structure refinement 4 | status: Completed 5 | created: 2017-12-14 6 | category: core 7 | lead-contributor: jeluard 8 | contributors: 9 | - jeluard 10 | - asemiankevich 11 | - Serhy 12 | - flexsurfer 13 | - goranjovic 14 | - chadyj 15 | - andmironov 16 | exit-criteria: no 17 | success-metrics: no 18 | clear-roles: yes 19 | future-iterations: yes 20 | --- 21 | 22 | ## Preamble 23 | 24 | Idea: #61-app-structure 25 | Title: App structure refinement 26 | Status: In Progress 27 | Created: 2017-12-14 28 | 29 | 30 | ## Summary 31 | 32 | For the beta launch there needs to be some app structure refinements and UI tweaks in order to simplify the experience and orientate users on clear actions and expectations. 33 | 34 | ## Swarm Participants 35 | 36 | - Lead Contributor: @jeluard 37 | - Testing & Evaluation: @asemiankevich , @Serhy 38 | - Contributor: @flexsurfer 39 | - Contributor: @goranjovic 40 | - PM: @chadyj 41 | - UX: @andmironov 42 | 43 | ## Product Overview 44 | 45 | The current alpha build is an expression of many ideas at various stages of completion that showcases the longer term potential of Status. However, not all features are optimized and polished with the user in mind. An app structure update will re-focus the app around the core flows and provide a solid platform for future updates. 46 | 47 | The new app structure will focus the user around DApps, Chat, Wallet, and profile/settings. From a users perspective this presents a clear, focused, and unambiguous explanation of what Status does without the need to hunt around in the app. 48 | 49 | Lastly, a simplified and flatter structure will have a smaller surface area for bugs/testing/etc that will enable us to reach out beta goal sooner. 50 | 51 | ### Product Description 52 | 53 | The app will have 3 tabs: Home, Wallet, Profile (copy tbc). 54 | 55 | Home consolidates chats, contacts, and discover in the current release. This removes a lot of redundancy. 56 | 57 | The sidebar is removed and contents merged into Profile. 58 | 59 | Each screen is cleaned up and focused slightly. 60 | 61 | screen shot 2017-12-14 at 4 04 15 pm 62 | (sample screenshots for illustration) 63 | 64 | ### Minimum Viable Product 65 | 66 | Description: migrate `wallet` and `profile` tabs 67 | Goal Date: 2 weeks after start (target start date: 2018-01-02) 68 | Started: 2018-01-06 69 | Completed: 2018-02-09 70 | 71 | __WARNING__ Related mockups are a dependency for this iteration. 72 | 73 | * migrate existing profile to the `profile` tab (according to MVP mockups) 74 | * update `wallet` tab (according to MVP mockups) 75 | * migrate to tab based navigation (as described in #33) 76 | * remove tabs `contacts` and `discover` 77 | * prepare a detailed plan for `home` tab 78 | 79 | ### Iteration 1 80 | 81 | Description: migrate `home` tab 82 | Goal Date: 3 weeks after start 83 | Started: 2018-02-12 84 | Completed: 2018-03-22 85 | 86 | * Restyle profile 87 | * Update home tab 88 | * Rework home "add" 89 | * Refine chats 90 | * Remove old commands 91 | 92 | __WARNING__ Related mockups are a dependency for this iteration. 93 | 94 | ## Post-Mortem 95 | 96 | The scope of the iteration was very broad. Probably our biggest set of changes so far! 97 | 98 | Nonetheless this swarm took significantly more time than expected. 99 | We identified a number of area that could be improved: 100 | 101 | * better scoping and time spent upfront to detail atomic tasks 102 | * assign task per iteration and let assignees estimate them 103 | * have a fixed scope per iteration: no new issue can be added during an iteration 104 | * have a fixed team, at least per iteration (limit turnaround) 105 | * improve test automation and ensure PRs do not introduce regression 106 | * improve communication related to technical cost / hidden complexity 107 | 108 | ## Copyright 109 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 110 | -------------------------------------------------------------------------------- /ideas/163-support-erc721.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 163-support-erc721-tokens 3 | title: Support ERC721 tokens 4 | status: Draft 5 | created: 2018-04-10 6 | category: core 7 | lead-contributor: rachelhamlin 8 | contributors: 9 | - rachelhamlin 10 | - jeluard 11 | - goranjovic 12 | - denis-sharypin 13 | exit-criteria: yes 14 | success-metrics: yes 15 | clear-roles: yes 16 | future-iterations: no 17 | --- 18 | 19 | ## Preamble 20 | 21 | Idea: 163 22 | Title: Support ERC721 tokens 23 | Status: Draft 24 | Created: 2018-04-10 25 | 26 | ## Summary 27 | Add ERC721 support to Status wallet so that users can see their CryptoKitties, Punks, Celebrities, etc. alongside their other assets. 28 | 29 | ## Swarm Participants 30 | - Lead/PM: [@rachelhamlin](https://github.com/rachelhamlin) 31 | - Testing & Evaluation: 32 | - Contributor: [@jeluard](https://github.com/jeluard) 33 | - Contributor: [@goranjovic](https://github.com/goranjovic) 34 | - UX: [@denis-sharypin](https://github.com/denis-sharypin) 35 | 36 | ## Product Overview 37 | 38 | ERC721 tokens, or non-fungible tokens (NFTs), represent unique assets on the blockchain. The ability to use rare digial assets as a store of value has spawned a large market of digital collectibles. 39 | 40 | With 100+ digital collectibles on the market and a combined sales volume greater than $50MM, it's important that we allow users to access their NFT collections inside Status right alongside their ETH and ERC20 tokens. 41 | 42 | The two primary cases we need to support are: 43 | 1. Having my existing collectibles in my Status wallet 44 | 2. Buying or receiving new collectibles and seeing them in my Status wallet 45 | 46 | Additional use cases may focus on gifting collectibles from one user to another, or sending collectibles in a chat. 47 | 48 | ### Product Description 49 | 50 | ##### For already owned crypto assets 51 | 52 | Users should be able to view their collection of NFTs in a dedicated section of their Status wallet. 53 | Tokens associated with a user's Mainnet address should appear there automatically. 54 | 55 | Any ERC721 token should be supported, and individual assets within a collection should display available metadata such as name or number, properties, creation date, etc. To whatever extent possible, we can standardize the metadata displayed for each type of collectible and provide a link to the DApp for more. 56 | 57 | ##### For newly purchased crypto assets 58 | 59 | When a user buys a new collectible through some other browser, it should automatically appear in their Status wallet. Same goes for collectibles that can be gifted, as is the case with Cryptokitties; Status should recognize when a user receives a new collectible as a gift. 60 | 61 | A user should also be able to purchase collectibles from the Status browser, and the collectible should appear in their wallet. 62 | 63 | Initially we can use marketplaces to support this by consuming metadata from [Opensea.io](https://opensea.io/) or [Rarebits.io](https://rarebits.io/), but users should also be able to purchase new collectibles inside each DApp. 64 | 65 | ### Requirements & Dependencies 66 | 67 | Potential dependency on Status extensions (formerly #101) 68 | 69 | ### Minimum Viable Product 70 | Goal Date: 71 | 72 | Description: 73 | 74 | As there is no way to automatically browse all the existing collectible types, we'll focus on individual support for any collectible DApps that Status currently features. 75 | 76 | - UX/UI for collectibles in wallet: 77 | - Browse collections (categories/types) 78 | - Browse collectibles 79 | - View individual collectible 80 | - Add wallet support for any ERC721 featured in Status Selected DApps: 81 | - CryptoFighters 82 | - CryptoKitties 83 | - CryptoPunks 84 | 85 | ### Iteration 1 86 | - Expand collectible support 87 | - Add profile showcase for users to display their collections 88 | - Purchase new collectibles via a marketplace 89 | 90 | ### Exit Criteria 91 | TK 92 | 93 | ### Success Metrics 94 | TK 95 | 96 | ## Supporting Role Communication 97 | 98 | ## Copyright 99 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 100 | -------------------------------------------------------------------------------- /ideas/120-swarm-process/permission-less-and-compensated-work.md: -------------------------------------------------------------------------------- 1 | ## Background 2 | This document outlines the development and participation of contributors to 3 | Status. In particular we have found: As an open source organisation, we should 4 | improve and further incentivize community involvement and development Status, 5 | where people feel comfortable working on whatever they want There are Core 6 | Contributors [CC] at Status who are paid salaries to solve particular problems. 7 | 8 | The purpose of the document is to help core contributors understand how Status 9 | currently organizes swarms (and their shortcomings) and steps towards improving 10 | this process. 11 | 12 | ## Swarms: permission-less and compensated work within Status 13 | 14 | Suppose Person A is undertaking a task, and Person B is funding it. Who should 15 | be evaluating Person A's work? 16 | 17 | Naturally it makes sense for Person B to, as they are assuming the risk, though 18 | they might choose to delegate this responsibility to a trusted person. 19 | 20 | ### Current Model 21 | 22 | In our case, Carl and Jarrad (major SNT holders) are to a large extent 23 | delegating funding of work through Nabil (COO) and, by further extension, Status 24 | core contributors. Decision making is done by core contributors. This makes up 25 | the 'main Status entity', which is currently a form of 'DAO 0.5'. 26 | 27 | So how do we currently want to evaluate work? As an entity, we can choose to 28 | delegate this evaluation to paid core contributors as swarm leads (trusted 29 | model). Additionally, we can choose to require PM/UX/Eng representation for 30 | user-facing swarms, as well as a minimum of three contributors per swarm. These 31 | are evaluation and funding mechanisms we can choose to adapt and formalize, 32 | where 'contributor time' is a form of funding mechanism, as salary compensation 33 | is decoupled from the swarm process. 34 | 35 | ### Shortcomings 36 | One shortcoming of this is it does not support funding from other SNT holder and 37 | the wider community. The evaluation and funding mechanism for this could be 38 | improved/adapted. Similarly, requiring specific roles or minimum contributor 39 | count is an arbitrary restriction that isn't desirable as a general compensation 40 | mechanism for getting work done. Example: lone hacker in middle of nowhere doing 41 | something that is a public good in Status and a funder believes they are able to 42 | execute on by themselves. Specifically what other forms of evaluation and 43 | funding mechanisms we want to make easy is something that we will find out as 44 | time goes on, largely through SOB and its experiments. 45 | 46 | What happens with work that doesn't fall neatly within existing categories?? It 47 | depends on the nature of it. It might be completely isolated from the core app, 48 | e.g. in the form of organizing meetups, writing content, developing a dapp that 49 | doesn't require coordination with main code base, etc. If it does involve 50 | changes in the core app, there's a selection mechanism where we can choose to 51 | accept or deny such work (example: pull requests in status-react). Since we are 52 | open source, in case of strong disagreement, one could imagine a fork and 53 | alternative app artifact being distributed. But in the 99% case it would be in 54 | the interest of the swarm, as well as its funder, that this work gets into the 55 | core app. One could look at Status Core Contributors as custodians of the core 56 | app, and this swarm would likely need to coordinate with CCs to ensure their 57 | work has impact. 58 | 59 | ### Where to go from here? 60 | 61 | 1. Acknowledge that: 62 | 63 | a) We will experiment with Swarm evaluation and funding mechanisms (both time 64 | and money) 65 | 66 | b) Swarms experiments won't be restricted by constraints outlined below in [2] 67 | 68 | c) To the extent experiments are successful, this might impact below constraints 69 | 70 | 2. Encode the following evaluation and funding mechanism for salaried core 71 | contributors: 72 | 73 | a) Delegate evaluation of swarm's performance to core contributors in a swarm 74 | (evaluation process still tbd) 75 | 76 | b) Require PM/UX/Eng contributors for user-facing swarms 77 | 78 | c) Require a minimum of three core contributors per swarm 79 | -------------------------------------------------------------------------------- /ideas/324-meritocracy.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: #324-meritocracy 3 | title: Meritocracy 4 | status: implementation 5 | lead-contributor: richard/jarrad 6 | contributors: jarrad, ceri, jb, rajanie 7 | 8 | budget: 9 | - actual: xxx 10 | - estimate: yyy 11 | - currency: ETH/USD/SNT 12 | --- 13 | 14 | # Swarm proposal 15 | 16 | ## Summary and Goal(s) 17 | Kudos DApp - an experiment with awarding kudos each week between Status contributors. Heavily inspired by Giveth’s awesome RewardDAO concept, the idea is that contributors get a weekly allowance of SNT which they can distribute amongst other contributors as they see fit. The awarded totals can be withdrawn by contributors who have earned kudos. 18 | 19 | More here: https://discuss.status.im/t/kudos-rewards-building-the-status-meritocracy/1019 20 | 21 | **Swarm goals** 22 | * Create DApp 23 | * Launch DApp 24 | * Encourage regular (weekly) CC interaction with DApp to recognise others 25 | 26 | ## Communication 27 | Channel: [#324-meritocracy](https://get.status.im/chat/public/324-meritocracy) 28 | 29 | Sync frequency: async via text 30 | 31 | ## Research 32 | * Influenced by Giveth's Reward DAC [concept](https://wiki.giveth.io/dac/contributors-guide//). 33 | * Initial proposal and discussion [here](https://docs.google.com/document/d/1QN2SZ8QO-7jfH8rAKLVDAB5LxuKvBScodWoiRfejFkM/edit#heading=h.tommnlxre23w). 34 | * Idea developed on Discuss [here](https://discuss.status.im/t/kudos-rewards-building-the-status-meritocracy/1019). 35 | * Collected sign-ups [here](@people-ops) - 42 people signed up 🎉 36 | 37 | 38 | ## Specification 39 | 40 | * DApp spec [here](https://github.com/status-im/meritocracy) courtesy of @jarrad 41 | 42 | ## Implementation 43 | 44 | **Timeline** 45 | [Mid-Feb - 5 April] 46 | - [x] Deploy DApp to Mainnet (@richard) 47 | - [ ] Add @jb and @rajanie as additional `Admins` if possible (@richard) - only the contract owner (richard) can add admins 48 | - [x] Seek help with adding Design to the UI (@richard/@people-ops) 49 | - [x] Test DApp and share feedback (@people-ops) 50 | - [x] Create budget and plan for transfer of SNT into contract (@people-ops / finance) 51 | - [x] Create People Ops site page / FAQ (@people-ops) - https://people-ops.status.im/meritocracy/ 52 | - [x] Draft launch post for Discuss (@people-ops) 53 | - [x] Launch on 5 April with post on Discuss (@people-ops) - delayed to 8 April 54 | - [x] Present/demo in TH (@richard / @people-ops) 55 | - [ ] Schedule weekly reminders to ping all contributors to let them know a new reward cycle has started (@people-ops) 56 | - [ ] Leaderboard UI 57 | 58 | **Updates** 59 | * 22 March - Added @ceri as admin in Ropsten testnet 60 | * 25 March - @richard and @ceri walkthrough to get admin role set up, before doing allocations in mainnet. 61 | * 26 March - pinged Finance about funding the wallet with SNT & ETH. Did another test run on Ropsten of the weekly allocation by admin of funds to the meritocracy contract. 62 | * DApp does not currently have leaderboard UI, but the contract can be queries for each individual's balance, so this info can be pulled manually if needed. 63 | * 28 March - Finance have transferred a small amount of ETH and SNT into @ceri's Metamask wallet ready for first cycle (equivalent to SNT 5 per participant). 64 | * 1 April - 5 SNT distributed to all participants. 65 | * 3 April - troubleshooting issues with Richard. Drafting launch comms 66 | * 8 April - launched with 10 SNT allocated. 67 | 68 | 69 | ## Maintenance 70 | 71 | * @ceri, @rajanie, and @jb will act as DApp `admin` to make the weekly allocation of SNTs. 72 | * Ask CCs to log any issues either in #324-meritocracy or creating an issue [here](https://github.com/status-im/meritocracy/issues). 73 | * Review quarterly (first review early July 2019) to review success of DApp: 74 | * Engagement - > 50% of core contributors (currently = 32 people) using the DApp regularly (at least once a month) 75 | * Functionality - all open issues closed and volume of problems reported reduced 76 | * Feedback - anecdotal feedback from users positive, do CCs enjoy and benefit from using the DApp? 77 | * Utility - does the data generated through the DApp accurately represent a Meritocracy, or are there any concerns/issues. 78 | 79 | ## Copyright 80 | 81 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 82 | -------------------------------------------------------------------------------- /ideas/121-swarm-compensation/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 121-swarm-compensation 3 | title: Swarm Compensation Experiments 4 | status: Aborted 5 | created: 2018-04-02 6 | category: openbounty 7 | lead-contributor: martinklepsch 8 | contributors: 9 | - martinklepsch 10 | - oskarth 11 | - carlbennetts 12 | - jason 13 | exit-criteria: yes 14 | success-metrics: yes 15 | clear-roles: yes 16 | future-iterations: yes 17 | --- 18 | 19 | ## Preamble 20 | 21 | Idea: 121-swarm-compensation 22 | Title: Swarm Compensation 23 | Status: In Progress 24 | Created: 2018-04-02 25 | Related: 120-swarm-process 26 | 27 | ## Summary 28 | Ultimately we would like Status to become a public good, owned, developed and ran by it's very own users. In order to achieve that we need to open up our processes for contributions from "the outside" and establish ways for users to propose & incentivise projects they see as important. 29 | 30 | Swarms are our current attempt at enabling this. They are ephemeral teams forming to achieve a specified goal and disbanding once achieved or failure becomes apparent. Their defined lifetime and -cycle encourage constant re-evaluation &. evolution. 31 | 32 | Compensating contributors for their work is an important component of this and where `120-swarm-process` focuses on establishing a baseline of processes that are open to everyone this idea will focus on experimentally devising compensation mechanisms. 33 | 34 | ## Swarm Participants 35 | 36 | - Lead Contributor: @martinklepsch 37 | - Contributor ('payment'): @jason / @carl 38 | - Contributor: @oskarth 39 | - Evaluation ('compensation criteria'): Voting mechanism among experiment participants (Polly survey) 40 | 41 | ## Product Overview 42 | 43 | This swarm will define **four** experimental compensation mechanisms and recruit upcoming swarms to participate in this experiment. 44 | 45 | The compensation mechanisms should be judged according to the following criteria: 46 | 47 | - **Fairness** — if we're not fair we will fail to retain contributors. While hopefully obvious employees of Status the company and community contributors should be treated equally. 48 | - **Ease of use** — we want to ship a new kind of platform, not get bogged down in "paperwork" 49 | - **More attractive than salary** — as outlined in `120-swarm-process` there are two types of swarms: 50 | - **`Type-1`** is the ideal, defined, ran and compensated by the community 51 | - **`Type-2`** is the currently predominant form. Defined, ran and compensated by employees of Status, the company. 52 | - While coming up with a nice model for `Type-1` swarms we also would like to encourage every Status employee to participate in similar ways as community contributors. 53 | 54 | ## Checkpoints 55 | 56 | #### Checkpoint 1 — `2018-04-13` 57 | 58 | - Define at least two compensation models 59 | - Get buy-in from major SNT holder to fund experiments 60 | - Talk to #peopleops how we can admin/structure this 61 | - Reach out to upcoming swarms and convince them to participate 62 | - Broadcast intention behind these experiments into community and encourage submission of ideas. (Medium post?) 63 | 64 | #### Checkpoint 2 — `2018-04-27` 65 | 66 | - Define two more compensation models 67 | - Again, reach out and convince upcoming swarms 68 | - If possible consider a community submitted idea/swarm 69 | 70 | #### Checkpoint 3 — `2018-05-31` 71 | 72 | - Summarize learnings and archive them in ideas repository. 73 | - Write up what these learnings mean for the OpenBounty project specifically and how they should affect the development of the product. 74 | 75 | ## Exit Criteria 76 | 77 | Conduct four experiments and evaluate them based on the criteria outlined above. Give recommendation on what kind of compensation mechanism should be enabled by Status OpenBounty. 78 | 79 | ## Metrics Affected 80 | 81 | ### OpenBounty Transaction Volume 82 | 83 | While these experimental compensation payouts won't happen through the OpenBounty platform these transactions could still be counted as part of OpenBounty as they will ultimately inform what compensation models will find their way into OpenBounty. 84 | 85 | ### SNT Utility 86 | 87 | Once these experiments translate to changes in the OpenBounty product SNT holders will be able to directly support changes they see as important. This will increase SNT utility and distribute ownership of the Status platform. 88 | 89 | ## Copyright 90 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 91 | -------------------------------------------------------------------------------- /ideas/090-branch-perf-stats.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 090-branch-perf-stats 3 | title: Make branch performance stats visible 4 | status: Draft 5 | created: 2018-03-12 6 | category: core 7 | lead-contributor: PombeirP 8 | contributors: 9 | - jason 10 | - adambabik 11 | exit-criteria: no 12 | success-metrics: no 13 | clear-roles: no 14 | future-iteration: no 15 | roles-needed: 16 | - DevOps 17 | - Go dev 18 | okrs: 19 | - "[P4]: Objective: Implement continuous delivery" 20 | - "[P0]: KR: >80% automated test coverage" 21 | --- 22 | 23 | ## Preamble 24 | 25 | Idea: 090 26 | Title: Make branch performance stats visible 27 | Status: Draft 28 | Created: 2018-03-12 29 | 30 | ## Summary 31 | 32 | Right now there is no visibility of how a PR impacts performance before it is merged to develop. It would be highly beneficial to have automated performance tests run and attach info to each Jenkins build, so that we can have historical records and compare current branch with parent branch. 33 | 34 | ## Swarm Participants 35 | 36 | - Lead Contributor: PombeirP 37 | - Contributor (Go): adambabik 38 | - Contributor (DevOps): jason 39 | 40 | ## Product Overview 41 | 42 | Right now, we run end-to-end tests but we don’t collect performance metrics on them. That’s throwing away a lot of valuable information that can inform discussions and decisions down the road. It’s important to have metrics on every PR branch and not just on develop, so that contributors have visibility into how their changes will potentially be affecting the stable branch. 43 | 44 | ### User Stories 45 | 46 | Adding measurements like CPU, memory and network usage to each build would allow having a better idea of a branch performance quality, as well as the long term trend. This would serve to inform decisions, pull request reviews, and potentially have a single source of truth in terms of low-level performance tests. 47 | 48 | ### Requirements & Dependencies 49 | 50 | Defining the best option in terms of CI/CD platform. Although this swarm doesn't technically require a particular platform, some lend themselves better to exposing and surfacing this type of information. 51 | 52 | ### Security and Privacy Implications 53 | 54 | N/A 55 | 56 | ## Dates 57 | 58 | > Description of deliverables at a given date, for example each Town Hall (default). 59 | > Add more iterations as required. 60 | > 61 | > Evaluator accepts responsbility to checkin at Goal dates, forces discussion to 62 | > continue implementation or recommend disband and post-mortem. 63 | > 64 | > Upcoming Town Halls this quarter: 65 | > 2018-04-23, 2018-05-07, 2018-05-21, 2018-06-04, 2018-06-18 66 | 67 | ### Minimum Viable Product 68 | 69 | > Mandatory, completes the Idea in the fastest route possible, can be hacky, 70 | > needed to feel progress. See https://imgur.com/a/HVlw3 71 | 72 | Goal Date: 73 | 74 | Description: 75 | 76 | A PoC would start with the lowest level (status-go) to guarantee that the building blocks are sound. This would add a report to the CI build artifacts containing the results for one representative use case (e.g. creating 2 accounts and sending 100 1:1 chat messages to each other sequentially), measuring only time taken and network traffic for the PoC. Report would be potentially consist of a CSV file and an HTML report file. The absolute requirement is that one of the files lends itself well to automated processing, including e.g. pasting to a Google Sheets file for further processing. 77 | 78 | **NOTE**: TeamCity allows collecting custom statistical values from each build (just by outputting a value in a special format to the console) and then aggregating in a time-series graph: 79 | 80 | ![graph](https://user-images.githubusercontent.com/138074/37280336-c04ad1c6-25ed-11e8-8064-1dd4a01c4882.png) 81 | 82 | ### Iteration 1 83 | 84 | Goal Date: 85 | 86 | Description: 87 | 88 | ## Success Metrics 89 | 90 | - More than 66% of developers surveyed think that they can rely on the CI system to easily compare the measured properties of each build between to branches. 91 | - Builds with a lower quality (network consumption, etc) fail automatically. 92 | 93 | ## Exit criteria 94 | 95 | - status-go and status-react builds are handled and success metrics are fulfilled for those two teams. 96 | 97 | ## Supporting Role Communication 98 | 99 | N/A 100 | 101 | ## Copyright 102 | 103 | Copyright and related rights waived 104 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 105 | -------------------------------------------------------------------------------- /ideas/003-erc20-token-support.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 003-er20-token-support 3 | title: ERC20 Token Support 4 | status: Done 5 | created: 2017-11-08 6 | category: core 7 | lead-contributor: jeluard 8 | contributors: 9 | - jeluard 10 | - goranjovic 11 | - 3esmit 12 | - asemiankevich 13 | exit-criteria: no 14 | success-metrics: no 15 | clear-roles: yes 16 | future-iterations: yes 17 | --- 18 | 19 | ## Preamble 20 | 21 | Idea code: DEV#003 22 | Status: Done 23 | Created: 2017-11-08 24 | Started: 2017-11-14 25 | Ended: 2018-01-04 26 | 27 | ## Summary 28 | 29 | Add ERC20 support 30 | 31 | ## Idea proposal 32 | 33 | As a user I want my [ERC20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md) tokens to be first class citizen. 34 | 35 | ## Swarm Participants 36 | 37 | * Lead Contributor: @jeluard 38 | * Contributor: @goranjovic 39 | * Support: @3esmit 40 | * Tester: @asemiankevich 41 | 42 | Swarm channel: **3-erc20** 43 | 44 | ## Requirements 45 | 46 | A user should be able to manage its ERC20 tokens pretty much the same way as ETH. 47 | In particular `wallet` and `send` command must support ERC20 tokens. 48 | 49 | 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). 50 | 51 | ERC20 extensions might also be considered: [ERC223](https://github.com/ethereum/EIPs/issues/223), [Minime](https://github.com/Giveth/minime) ([SNT](https://etherscan.io/token/StatusNetwork) itself is a Minime token). 52 | 53 | ## Zeplin references 54 | 55 | * Assets https://zpl.io/blwD8ka 56 | * wallet main screen (with list of assets shown + managin assets) https://zpl.io/b6d1eNV 57 | 58 | ## Board 59 | https://github.com/status-im/status-react/projects/4 60 | 61 | ## Goals & Implementation Plan 62 | 63 | Following features should be considered: 64 | 65 | * list wallet tokens 66 | * provide default token 67 | * send tokens to a contact 68 | * request token from a contact 69 | * get current price 70 | * get historical price 71 | * get token details (historical price, market cap, # tokens, volume, crowdsale) 72 | * list historical transactions 73 | * add gas and data support when sending transaction 74 | * chart graphs 75 | 76 | Can be split in 4 categories: 77 | 78 | * wallet token details (access and management) 79 | * token details (static and dynamic data) 80 | * token price details 81 | * token transactions 82 | 83 | Token details will require some metadata currently not available in ethereum. 84 | Token price details can be provided by `cryptocompare`. 85 | 86 | ### Minimum Viable Product 87 | 88 | List user tokens and display token details 89 | 90 | Goal Date: 2017-12-01 91 | Started: 2017-11-15 92 | Completed: 2017-12-05 93 | Description: token list and details 94 | 95 | ### Iteration 1 96 | 97 | Allow sending and requesting tokens. 98 | Show token historical data and update percentage info 99 | 100 | Goal Date: 2017-12-15 101 | Started: 2017-12-06 102 | Completed: 2018-01-04 103 | Description: send/request tokens 104 | 105 | ### Post Mortem 106 | 107 | #### What could be improved 108 | 109 | [App structure refinement](#61) was defined during the first iteration and significantly impacted the scope of this iteration. Specifically @goranjovic work around asset details had to be removed. 110 | 111 | A number of technical elements has been discovered and added to the todo list during development. It appears primordial to spend some time during the first days to have a detailed understanding of what's to be done and technical impacts. It appears our decentralized nature makes some usually simple things harder to implement. 112 | 113 | Finally we discovered pretty late some technical limitations that prevented us to implement some features (e.g. token transaction history). 114 | 115 | #### What went well 116 | 117 | Overall implementation went smoothly and we had fast test cycle thanks to @asemiankevich . 118 | 119 | ## Appendix: archive of future work 120 | 121 | ### Known limitations 122 | 123 | Due to technical constraints some features have been left out and will be addressed after prerequisites have been implemented. 124 | 125 | * no token transaction history (etherscan API doesn't support that) 126 | * send command: no token support (requires upgrade to API, support for deep linking) 127 | * request disabled for tokens (requires upgrade to API) 128 | 129 | ## Copyright 130 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 131 | -------------------------------------------------------------------------------- /ideas/058-mainnet.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 058-mainnet 3 | title: Use Mainnet as the default network 4 | status: Done 5 | created: 2017-12-08 6 | category: core 7 | lead-contributor: adambabik 8 | contributors: 9 | - adambabik 10 | - annadanchenko 11 | - themue 12 | - rasom 13 | - chadyj 14 | exit-criteria: yes 15 | success-metrics: yes 16 | clear-roles: yes 17 | future-iterations: yes 18 | roles-needed: 19 | - Clojure dev 20 | okrs: 21 | - "[P1]: Objective: Beta is launched successfully" 22 | - "[P0]: KR: 5k daily active users" 23 | --- 24 | 25 | ## Preamble 26 | 27 | Idea: 58-mainnet-default 28 | Title: Use Mainnet as the default network 29 | Status: In progress 30 | Created: 2017-12-08 31 | 32 | 33 | ## Summary 34 | Alpha builds of Status should default to Mainnet. We should be using Status in a real-world environment. 35 | 36 | ## Swarm Participants 37 | 38 | - Lead Contributor: adambabik 39 | - Testing & Evaluation: annadanchenko 40 | - Contributor: themue 41 | - Contributor: roman (supportive role; still in need of one Clojure dev) 42 | - PM: chadyj 43 | 44 | ## Product Overview 45 | 46 | Currently the Status alpha builds use testnet, but using Mainnet is a key milestone for the public launch of Status. There will be potentially major performance and security implications so the goal is to surface these issues early enough by testing the app in a real-world environment. 47 | 48 | From a users perspective, Mainnet should be a default network as it is required by most popular DApps, and is needed for real transactions, so the full potential of Status can't be seen until we switch. The other networks will continue to be available, e.g. for developers and tests. 49 | 50 | ## Product Description 51 | 52 | This is a default setting change, so there aren't any user facing options. The other networks are still visible. 53 | 54 | Some users, such as DApp creators may want to test their app on testnet (or some other use case), so they will be able to toggle networks as can be done currently. 55 | 56 | ## Requirements & Dependancies 57 | 58 | Security and performance should should be discussed and considered. 59 | 60 | Also, several DApps should be tested. 61 | 62 | ## Minimum Viable Product 63 | 64 | **This MVP does not mean that after it's finished we release the app with Mainnet enabled by default but defines prerequisites that should be done before we consider doing so.** 65 | 66 | Goal Date: 2018-04-14 67 | 68 | 1. [X] Development of required components is done. The work is tracked here: https://github.com/orgs/status-im/projects/15, 69 | 1. [X] There is a Status App build with mainnet available, 70 | 1. [X] All components have been tested by the Test Team, 71 | 1. [X] Mainnet is default in dev/nightly builds. 72 | 73 | ## Audit iteration 74 | 75 | Goal Date: 2018-05-31 76 | 77 | 1. [x] Security audit is finished by an independent company, 78 | 1. [x] The final report is available, 79 | 1. [x] All reported security issues and recommendations are evaluated and finished. 80 | 81 | ### Updates 82 | 83 | #### 2018-04-26 84 | 85 | - security audit got extended to May 7th, 86 | - security issues are tracked with `security` label in [status-react](https://github.com/status-im/status-react/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity) and [status-go](https://github.com/status-im/status-go/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity), 87 | - [a feature request](https://github.com/status-im/status-react/issues/3994) to allow custom upstream address was created 88 | 89 | #### 2018-06-05 90 | 91 | - the final readout took place on May 7th, 92 | - there were no new issues reported, 93 | - all issues were fixed; there are still recommendations that we decided to implement but they are not blockers for beta. Moreover, more issues were identified during Risk Management meetings. 94 | 95 | ## Status App Bug Bounty iteration ~~(CANCELED)~~ 96 | 97 | ~~**This iteration got canceled as we do not plan to announce Status App Bug Bounty for the time being.**~~ 98 | 99 | Goal Date: 2018-04-?? 100 | 101 | 1. [ ] Status App Bug Bounty program is announced and will last for at least X weeks. 102 | 103 | ### Updates 104 | 105 | #### 2018-06-05 106 | 107 | We actually decided to run Status App But Bounty in June. The blog post should appear this week. 108 | 109 | ## Success and exit criteria 110 | 111 | 1. Mainnet is operational just like testnets and availalbe in dev/nightly builds, 112 | 1. The audit is completed and there are no low, medium, high or critical issues. 113 | 114 | ## Copyright 115 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 116 | -------------------------------------------------------------------------------- /ideas/120-swarm-process/town-hall-7-survey-results.md: -------------------------------------------------------------------------------- 1 | # Raw data from survey after Town Hall 7 2 | 3 | ## 1. It is clear to me when a swarm starts 4 | 5 | (sent to #general) 6 | 7 | Strongly Agree 12% (6) 8 | Agree 54% (28) 9 | Neutral 25% (13) 10 | Disagree 10% (5) 11 | Strongly Disagree 12 | 13 | Average: 3.7 14 | Total Votes: 52 15 | 16 | ### Comments 17 | 18 | > Neutral: WHere are they announced, who validates and create the slack channel?, 19 | > 20 | > Disagree: Sometimes the lines between in progress & draft seems to be a bit blurred ( some work is done before is officially in progress for example). 21 | > 22 | > Agree: Oskar's work on that site (and the fact I have had to review a lot of stuff there for bounties) has left me with great insight into the process. 23 | > 24 | > Neutral: I'm not sure how swarms officially start. Some seem to start without an idea and others seem to stay in draft. 25 | > 26 | > Neutral: Well, it's like clear, but i'd add some global notification (maybe in core channel) like '@channel - this is official start of the swarm #XXXX, join the respective channel!' 27 | > 28 | > Neutral: Start of work and formal establishment of the swarm may overlap. 29 | > 30 | > Agree: I *think* it's when a PR has been requested., 31 | > 32 | > Agree: It seems that swarms can start even when they are in draft mode - or is that not the case. I guess hence the relative clarity 33 | > 34 | > Disagree: If a swarm lead is not super clear about when the swarm actually starts, then it's not clear when one starts. 35 | > 36 | > Disagree: There is a certain amount of work required to get the swarm started in the first place - defining scope and all that. So, what is the difference between the moment this prep work starts and the moment when actual swarm starts?, 37 | > 38 | 39 | ## 2. It is clear to me when a swarm ends 40 | 41 | (sent to #general) 42 | 43 | Strongly Agree 16% (8) 44 | Agree 49 (28) 45 | Neutral 29% (15) 46 | Disagree 6% (3) 47 | Strongly Disagree 48 | 49 | Average: 3.7 50 | Total Votes: 51 51 | 52 | ### Comments 53 | 54 | > Agree: Scope is done, milestones achieved, 55 | > 56 | > Agree: Highly depends on swarm, 57 | > 58 | > Neutral: not enough data to answer this, it is clear on paper (when exit criteria are met) but I would like to see it before in action. 59 | > 60 | > Strongly Agree: OKRs and clear exit criteria make this much easier and we seem to be developing an org shorthand (P0, P1 etc) that allows us to talk about complex things quickly and simply enough for everyone to get a handle on things. This should be strongly encouraged. 61 | > 62 | > Agree: It requires checking after a while whether it hasn't been re-activated, but the concept is clear. 63 | > 64 | > Neutral: Who validates the success metrics? 65 | > 66 | > Agree: All OKRs and exit criteria have been met., 67 | > 68 | > Neutral: Feels a little less clear and seems as though some swarms with remaining iterations get overshadowed by new swarms or ideas. 69 | > 70 | > Neutral: Depends on how clear is exit criteria 71 | > 72 | > Disagree: The whole point of a swarm is to be somewhat eternal and yet somewhat ephemeral. To say when a swarm ends is kind of... non sequiter? Would that be the correct word? In any case, it never really ends when started up imv. 73 | > 74 | 75 | ## 3. It is clear to me what it means for a swarm to be well-defined 76 | 77 | (sent to #general) 78 | 79 | Strongly Agree 10% (5) 80 | Agree 61% (31) 81 | Neutral 25% (13) 82 | Disagree 4% (2) 83 | Strongly Disagree 84 | 85 | Average: 3.8 86 | Total Votes: 51 87 | 88 | ### Comments 89 | 90 | > Disagree: I dont know how is this well-defined right now but it may be my personal view. In terms of scope mostly. Like all swarms (almost) are some kind of feature-based (like fast-status for ex) but scope is not well defined, like it is not only the issues fixing to me but it is achieving some UX cases that we can check with real users (in 90 % cases). So personally i think this could be improved and stated more clearly, like which scenarios (UX cases / user stories / whatever ) we want to achieve in terms of particular swarm (team) and separate them to iterations according to the workload and capacity 91 | > 92 | > Agree: Must have a specific set of _achievable_ OKRs and exit criteria and resources that can dedicate some time. 93 | 94 | ## 4. It is clear to me what is expected of a swarm lead 95 | 96 | (sent to #swarms) 97 | 98 | Strongly Agree 15% (4) 99 | Agree 63% (17) 100 | Neutral 15% (4) 101 | Disagree 7% (2) 102 | Strongly Disagree 103 | 104 | Average: 3.9 105 | Total votes: 27 106 | Agree or strongly agree: 78% 107 | 108 | ### Comments 109 | 110 | No comments. 111 | -------------------------------------------------------------------------------- /ideas/280-discoverable-trusted-server-nodes/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 280-discoverable-trusted-server-nodes 3 | title: Discoverable And Trusted Server Nodes 4 | status: Active 5 | created: 2018-06-07 6 | category: core 7 | lead-contributor: adambabik 8 | contributors: 9 | - "Richard Ramos (@richard-ramos), Smart Contract Developer" 10 | - "Andrea Maria Piana (@cammellos), Clojure Developer" 11 | - "Adrià Cidre (@adriacidre), Go Developer" 12 | exit-criteria: yes 13 | success-metrics: yes 14 | clear-roles: no 15 | future-iterations: yes 16 | roles-needed: 17 | okrs: 18 | - "[PO]: Objective: Messaging is reliable" 19 | - "[P2]: KR: Cluster can handle 500 concurrent users" 20 | --- 21 | 22 | Project Board: https://github.com/orgs/status-im/projects/35 23 | 24 | ## Summary 25 | The idea here is to provide a way to make Mail Server nodes discoverable and trusted. This should work seamlessly for the end user. 26 | 27 | ## Product Overview 28 | Currently, Mail Servers (and other planned server nodes like Push Notification servers) need to be hardcoded in the app code. It's possible to provide your own Mail Server in the app settings but that's not a scalable solution and it does not solve all issues. 29 | 30 | The outcome of this swarm are decentralized and discoverable Mail Servers which will initially be managed and trusted by Status. The client will still accept user's custom Mail Servers. 31 | 32 | In the next iterations, we may work on a solution to allow external providers to submit their own Mail Servers into the cluster and allow end users to accept these resources as trusted. The list of providers and their resource could be managed by [Token-Curated Registries](https://docs.google.com/document/d/1BWWC__-Kmso9b7yCI_R7ysoGFIT9D_sfjH3axQsmB6E), for instance. 33 | 34 | ## Product Description 35 | The work in this swarm can be divided into three areas: 36 | - (Infra) making Mail servers discoverable, 37 | - (Smart Contract) writing a smart contract to keep track of trusted Mail Servers, 38 | - (Client) mechanism of verifying whether a discovered Mail Server is trusted. 39 | 40 | The smart contract should implement the complete interface that will allow managing providers and their resources. The client will have an option to decide which providers it trusts. Status will be a default provider and by default the app will trust it. 41 | 42 | Due to the fact that all Mail Servers are supposed to be equal and independent (in other words, they should store the same messages, possibly in different order though), we will be able to remove all hardcoded Mail Server addresses from the client and rely only on discovered Mail Servers. This will allow Status to dynamically scale number of resources depending on the usage. 43 | 44 | **Note** Important thing is that this solution should be flexible for other server nodes. It should be easy to introduce new resources, as long as a particular group of servers is discoverable, the client verifies them using a smart contract and can choose arbitrary one to continue. 45 | 46 | ## Requirements & Dependancies 47 | 1. (Optional) Before this swarm starts, https://github.com/status-im/status-go/issues/1006 should be resolved in order to avoid working on the same piece of code. 48 | 49 | ## Minimum Viable Product 50 | 51 | Goal Date: 2018-07-22 52 | 53 | 1. [ ] A smart contract that keeps track of providers and Mail Servers, 54 | 1. [ ] Discoverable Mail Servers, 55 | 1. [ ] Requests for messages are securely encrypted to provide confidentiality, 56 | * As devp2p packets are encrypted and this is P2P communication, the question is should we additionally encrypt Whisper messages with a Mail Server's public key? 57 | 1. [ ] Client requests for Mail Servers and server finds them and verifies if they are trusted using the smart contract. Verified Mail Servers are sent to the client and a random one is selected to use. 58 | * We keep the option to add user's own Mail Server addresses. 59 | 1. [ ] Make sure this solution is flexible and can work with other server nodes. 60 | 61 | ## Iteration 1 (Optional, TBD) 62 | 63 | Goal Date: TBD 64 | 65 | 1. [ ] Allow custom providers to register their Mail Servers (Status as a curator?), 66 | 1. [ ] Allow users of the app to select trusted providers 67 | * [ ] A new design of a screen needed. 68 | 69 | ## Success and exit criteria 70 | 71 | 1. Mail Servers are not hardcoded in the client but are discovered using Discovery V5 protocol and verified using a smart contract, 72 | 1. (Optional) External Mail Server providers can register themselves and users can decide if they trust their resources (a list of providers is curated by Status). 73 | 74 | ## Copyright 75 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 76 | -------------------------------------------------------------------------------- /ideas/086-push-notif-v2/1to1.dot: -------------------------------------------------------------------------------- 1 | digraph ladder { 2 | ranksep="0.5"; nodesep="0.5"; splines="line"; ratio="0.5"; 3 | 4 | node [shape=point fontsize=10 fontname="Helvetica"]; 5 | edge [dir=none fontsize=10 fontname="Helvetica"]; 6 | 7 | // Column labels 8 | a [shape=Square label="Contact A" style=filled color=lightblue]; 9 | w1 [shape=Square label="Arbitrary\nNotification Server"]; 10 | p [shape=Square label="Notification platform\n(e.g. FCM, Pushy)" style=filled color=lightgray]; 11 | b [shape=Square label="Contact B" style=filled color=lightgreen]; 12 | 13 | // Draw the 3 column headings, no line 14 | { rank=same; edge[style=invis] a -> w1 -> b -> p } 15 | 16 | // Force rows to stay aligned 17 | { rank=same; edge[style=invis] a2 -> w1_2 -> b2 -> p2 } 18 | { rank=same; edge[style=invis] a3 -> w1_3 -> b3 -> p3 } 19 | 20 | // Draw the columns 21 | a -> a1 [style=dotted weight=1000]; 22 | w1 -> w1_1 [style=dotted weight=1000]; 23 | p -> p1 [style=dotted weight=1000]; 24 | b -> b1 [style=dotted weight=1000]; 25 | 26 | // Draw the vertical lines 27 | a1 -> a2 -> a3 [weight=1000] a3 -> a4 -> a5 -> a6 [style=dotted weight=1000] a6 -> a7 -> a8 -> a9 -> a10 -> a11 [weight=1000] a11 -> amax [style=dotted weight=1000]; 28 | w1_1 -> w1_2 [weight=1000] w1_3 -> w1_4 -> w1_5 -> w1_6 [style=dotted weight=1000] w1_6 -> w1_7 -> w1_8 -> w1_9 -> w1_10 -> w1_11 [weight=1000] w1_11 -> w1_max [style=dotted weight=1000]; 29 | p1 -> p2 -> p3 -> p4 -> p5 -> p6 -> p7 -> p8 -> p9 -> p10 [style=dotted weight=1000] p10 -> p11 [weight=1000] p11 -> pmax [style=dotted weight=1000]; 30 | b1 -> b2 [style=dotted weight=1000] b2 -> b3 -> b4 -> b5 -> b6 [style=dotted weight=1000] b6 -> b7 -> b8 -> b9 -> b10 -> b11 [weight=1000] b11 -> bmax [style=dotted weight=1000 label=" App retrieves historic messages\nand matches ID"]; 31 | amax, w1_max, pmax, bmax [style=invis] 32 | 33 | // Hide unused points 34 | a5, b1, b2, b3, b4, b5, w1_5, p1, p2, p3, p4, p5, p6, p7, p8, p9 [style=invis height=0]; 35 | 36 | // Now each step in the ladder 37 | { rank=same; a1 -> w1_1 [dir=back label="Broadcasts availability to serve\nas notification server (1)"] } 38 | { rank=same; w1_1 -> b1 [dir=forward label="Broadcasts availability to serve\nas notification server (1)"] } 39 | 40 | a2 -> w1_2 [dir=forward label="Sends anonymous Whisper message for registration request,\npassing device registration token and secure channel (SK1) (2)"]; 41 | 42 | w1_2 -> w1_3 [label=" Stores data for Contact A\n (device registration token, SK1)\nCreates AK2" weight=1000]; 43 | a3 -> w1_3 [dir=back label="Sends message over SK1 channel\naccepting request, and passing pubkey of AK2"] 44 | 45 | a4 [label="" shape=none width=0 height=0 xlabel="Stores pubkey of AK2.\nAt this point Contact A and\n Arbitrary Notification Server #1 \ncan communicate securely,\nusing keys exchanged with server "]; 46 | { rank=same; w1_4 -> b4 [dir=both label="Negotiation with PN servers,\nsame process as above for Contact A (...)"] } 47 | 48 | a6 [xlabel="Contact A starts chat \nwith Contact B"]; 49 | { rank=same; a6 -> b6 [dir=forward label="[NewContactKey]: Sends a contact request\nin the discovery topic, using B's public key for encryption\nand passing the new symkey that will be used for further comms.\nNEW: contains A's AK2 pubkey"] } 50 | 51 | { rank=same; a7 -> b7 [dir=back label="[ContactRequestConfirmed]: Responds to contact request.\nNEW: response contains B's AK2 pubkey"] } 52 | 53 | a8 [xlabel="Contact A wants\nto send a message \nto Contact B"]; 54 | { rank=same; 55 | a8 -> b8 [dir=forward label="Sends message using common random topic"] } 56 | 57 | { rank=same; 58 | a9 -> w1_9 [dir=forward label="Sends message over SK1 requesting a notification\nto Contact B passing B's AK2 pubkey over pre-defined topic"] } 59 | 60 | { rank=same; 61 | w1_10 -> p10 [dir=forward label="Requests notification to be sent to Contact B's device\nusing stored device registration token"] } 62 | 63 | { rank=same; 64 | b11 -> p11 [dir=back label="Sends a data push notification to Contact B's device\ncontaining hash of message payload as an ID"] } 65 | 66 | // Add empty space at the bottom before legend 67 | amax -> legend [style=invis weight=1000]; 68 | 69 | // Legend 70 | { legend [shape=plaintext label=< 71 | 72 | 73 | 75 |
(1) Communication is done over a discovery topic provided by Status to the PN providers.
Message includes pubkey of server's encryption key (AK1).
(2) Channel = random symmetric key + topic to have encrypted communication between peers 74 | .
>] } 76 | } -------------------------------------------------------------------------------- /ideas/173-documentation.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 173-documentation 3 | title: Status Documentation 4 | status: draft 5 | created: 2018-05-31 6 | category: core 7 | lead-contributor: 8 | contributors: 9 | - 10 | - 11 | - 12 | exit-criteria: yes 13 | success-metrics: yes 14 | clear-roles: no 15 | future-iteration: yes 16 | roles-needed: 17 | - QA 18 | - UXR 19 | - Clojure dev 20 | - Designer 21 | - Community 22 | okrs: 23 | - 24 | - 25 | --- 26 | 27 | ## Preamble 28 | 29 | Idea: 173-documentation 30 | Title: Status Documentation 31 | Status: Draft 32 | Created: 2018-05-31 33 | Requires (*optional): 34 | 35 | ## Summary 36 | 37 | A new-and-improved home for Status documentation, with fresh information and a plan for continuous maintenance. 38 | 39 | ## Swarm Participants 40 | 41 | - Lead Contributor: 42 | - Contributor: 43 | - Contributor: 44 | - QA: 45 | - PM (required for user-facing): 46 | - UX(R) (required for user-facing swarms): 47 | 48 | 49 | ## Product Overview 50 | 51 | The Status wiki is collecting cobwebs. Much of the information is out-of-date and further, the wiki hasn't gained traction as a resource. 52 | 53 | The goal of the wiki is to share knowledge and make it easy for developers to get involved with Status. This swarm aims to better fulfill that need by: 54 | 55 | 1. Updating existing content and proposing additional, if appropriate 56 | 2. Building a static site to host our documentation (reference [Embark](https://embark.status.im/docs/)) 57 | 3. Forming a strategy to keep documentation up-to-date in the future 58 | 59 | **Update existing content and propose additional** 60 | - A team of contributors will review the existing wiki and mark content as `irrelevant`, `relevant/outdated`, or `relevant/current`. 61 | - Swarm will gather a list of additional documentation that should be written or included by working with teams across the organization. 62 | - Additional documentation is not required for the completion of this swarm; the main emphasis is on migrating the wiki materials and creating a process for future docs. 63 | 64 | **Build static site to host documentation** 65 | - During a [discussion on Slack](https://status-im.slack.com/archives/CAB6WB38X/p1525340980000332), it was agreed that a static site which contributors can write to in markdown is a happy solution for now. 66 | - Swarm will decide on a potential architecture of information for the documentation site. 67 | - Site to be hosted on Github Pages, same as Embark and ethprize.io. 68 | - Swarm will decide on a static site generator to use, or to build from scratch. 69 | 70 | **Strategy to keep documentation up-to-date** 71 | - Swarm will propose a workflow that teams can follow to keep documentation up-to-date. 72 | - Swarm will get feedback and buy-in on the strategy. 73 | 74 | ### User Stories 75 | 76 | - A developer follows the quick start to build Status on their device and begin working on a status-react issue. 77 | - A developer learns about Status’ handling of push notifications, mail servers and messaging by reading the docs. 78 | - A developer follows the extensions documentation to build a native integration for their DApp. [future scenario] 79 | 80 | ### Requirements & Dependencies 81 | 82 | Participation from Core teams to create and edit documentation. 83 | 84 | ### Security and Privacy Implications 85 | 86 | 87 | ## Dates 88 | 89 | TBD once swarm participants are identified. 90 | 91 | 92 | ### Minimum Viable Product 93 | 94 | Goal Date: 2018-06-08 95 | 96 | Description: 97 | - Wiki content is reviewed 98 | - New content proposed—should we include Readmes? *New content is not a requirement* 99 | - v1 content architecture agreed upon 100 | - Website generator, if using, agreed upon—[Gatsby](https://www.gatsbyjs.org/), [Jekyll](https://jekyllrb.com/)? 101 | 102 | ### Iteration 1 103 | 104 | Goal Date: 105 | 106 | Description: 107 | - Existing wiki content is updated 108 | - Any new content in progress 109 | - Design assets for site prepared 110 | 111 | ### Iteration 2 112 | 113 | Goal Date: 114 | 115 | Description: 116 | - Website created, content migrated 117 | - Plan for maintaining documentation proposed 118 | 119 | Note: translatiosn can also be considered at this stage. 120 | 121 | ## Success Metrics 122 | 123 | - A developer can complete a set of required tasks by following the Status documentation. 124 | - Community feedback is positive. 125 | 126 | ## Exit criteria 127 | 128 | - New Status documentation website is live 129 | - Organization-wide buy-in for maintaining documentation 130 | 131 | ## Supporting Role Communication 132 | 133 | Sync with marketing, Embark and community teams 134 | 135 | ## Copyright 136 | 137 | Copyright and related rights waived 138 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 139 | -------------------------------------------------------------------------------- /ideas/229-hardware-wallet-pro.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 229-hardware-wallet-pro 3 | title: Hardware Wallet Pro 4 | status: Active 5 | created: 2018-05-01 6 | category: core 7 | lead-contributor: bitgamma 8 | contributors: 9 | jarradh 10 | naghdy 11 | exit-criteria: true 12 | success-metrics: true 13 | clear-roles: true 14 | future-iteration: true 15 | roles-needed: 16 | - QA 17 | - UXR 18 | --- 19 | 20 | ## Preamble 21 | 22 | Idea: 229-hardware-wallet-pro 23 | Title: Hardware Wallet Pro 24 | Status: In Progress 25 | Created: 2018-05-01 26 | 27 | ## Summary 28 | 29 | We currently have a Javacard based hardware wallet implementation. This is a simple and inexpensive hardware wallet with good security. The main limitations of this solution are 30 | 31 | 1. Requires a SmartCard reader on the host 32 | 2. Transaction data (amount, address) is displayed on the possibly compromised host device, the card has no screen 33 | 3. The seed is currently partially generated off-card because of JavaCard limitations 34 | 4. Limited API does not allow much room in terms of additional features. We already stretch the limit of what JavaCard can do by a far amount with our hardware wallet, which means that clever tricks and workarounds had to be implemented in a few cases. 35 | 36 | The proposal is to create a Pro version of the hardware wallet not based on the JavaCard platform and removing these limitations. This Pro version will have a significantly higher cost that then JavaCard one, since it will be a more complex device. 37 | 38 | ## Swarm Participants 39 | 40 | - Lead Contributor: @bitgamma 41 | - Contributor: @jarradh 42 | - Contributor: @naghdy 43 | - QA: TBD 44 | - UX: TBD 45 | - PM:@guylouis 46 | 47 | ## Product Overview 48 | The product will be a HD hardware wallet with its own screen and input buttons used to display and confirm transactions. The seed will be generated on card and mnemonics will be displayed on the card screen as to never reach the mobile device. Communication with mobile/desktop clients will happen through BLE. The device will be powered by its own rechargeable battery (inductive charger). Ideally, the physical size will match that of a standard smart card. 49 | 50 | ### Security and Privacy Implications 51 | As with any hardware wallet security is a prime concern. The device must be engineered to cope at least with the following threats 52 | 53 | 1. Data sniffing - this can be solved by encrypting the communication with the client device 54 | 2. Data injection - communication with the client device must be authenticated 55 | 3. User impersonation - beside possessing the card, the user must be authenticated by a PIN (the "something you know" factor) 56 | 4. Tampering of the software - Firmware must be either non-upgradable (less flexible, makes it impossible to fix existing bugs) or the upgrade procedure must be implemented in a secure way 57 | 5. Tampering of the hardware - It should be cost prohibitive to tamper with the hardware to read data or write malicious data. With the correct production techniques the device will be destroyed by disassembling. 58 | 59 | ## Success Metrics 60 | 61 | The project is composed o 4 major steps. Although these are described sequentially, at some point it might be possible to run some of them in parallel. Phase 3 especially can be started when the software is still being finalized but there is a solid understanding of which components are needed and how they are to be wired. 62 | 63 | ### Phase 1 64 | Goal Date: Start of Q4 2018 65 | Description: A prototype should be built using an STM32 Nucleo development board with a Bluetooth shield. This will allow writing most of the firmware. During this phase the UI must be designed. This means the design of a custom segment-based LCD and the design of how the user will interact with the device. 66 | 67 | ### Phase 2 68 | Goal Date: End Q4 2018 69 | 70 | Description: At the beginning of Q4, the new STM32WB chip will be available. This component integrates a bluetooth stack and a STM32L4 core in a single chip while also providing hw-accelerated encryption and key management. The firmware must be ported to this platform, which will be the platform used by the actual product 71 | 72 | ### Phase 3 73 | Goal Date: end of Q1 to middle of Q2 2019 74 | 75 | Description: In this phase the final product design, PCB design and BOM must be finalized and a manufacturer must be chosen and contracted. 76 | 77 | ### Phase 4 78 | Goal Date: TBD 79 | 80 | Description: Stock, distribution and launch. It is early to define a date because it very much depends from the manufacturer lead times and commercial strategy (we might want to tie product launch might to a specific conference or event) 81 | 82 | ## Exit criteria 83 | 84 | This swarm will be deemed successful and be closed after reaching Phase 4. 85 | 86 | ## Copyright 87 | 88 | Copyright and related rights waived 89 | via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 90 | -------------------------------------------------------------------------------- /ideas/140-sob-improve-onboarding/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 140-sob-improve-onboarding 3 | title: OpenBounty Improved Onboarding 4 | status: Aborted 5 | created: 2018-04-04 6 | category: openbounty 7 | lead-contributor: martinklepsch 8 | contributors: 9 | - martinklepsch 10 | - Churik 11 | - EugeOrtiz 12 | - arash009 13 | - rcullito 14 | exit-criteria: yes 15 | success-metrics: yes 16 | clear-roles: yes 17 | future-iterations: yes 18 | --- 19 | 20 | ## Preamble 21 | 22 | Idea: #XX-sob-improve-onboarding 23 | Title: OpenBounty Improved Onboarding 24 | Status: In progress 25 | Created: 2018-04-04 26 | 27 | ## Summary 28 | 29 | Currently users wanting to publish a bounty need to go through various manual steps, including us whitelisting them for using the platform. This step forces users to wait for us and might make them drop out of the process even if they were committed to create a bounty. 30 | 31 | This swarm aims to remove the need for whitelisting users and revamp the onboarding flow at the same time. 32 | 33 | ## Swarm Participants 34 | 35 | - Lead Contributor: @martinklepsch (10hr for MVP, 30hr+ from MVP onwards) 36 | - Testing & Evaluation: @Churik 37 | - UX Contributor: @EugeOrtiz 38 | - Dev Contributor: @siphuel or @rcullito 39 | - Contracts Contributor: @3esmit (need not fully clear) 40 | - Product Manager Contributor: @arash009 41 | 42 | ## Product Description 43 | 44 | Currently all users wanting to issue a bounty need to go through a whitelisting process. This is required because we currently pay the gas for deploying the bounty contract. In order to make it easier for users to get started we should remove this whitelisting requirement, allowing users to onboard at their own speed. 45 | 46 | There are multiple ways the need for whitelisting could be removed: 47 | 48 | - Allow (or force) users to pay gas for contract deployment themselves 49 | - Pay gas for new users but implement some rate-limiting or similar guards to protect from bad actors 50 | 51 | These and other alternatives will be evaluated as part of this swarm, whatever decision is taken will be documented in a [Decision Record](https://github.com/status-im/open-bounty/blob/develop/doc/decisions/0001-record-decisions.md). 52 | 53 | ## Iterations 54 | 55 | ### Iteration 1 — Concept/Design (MVP) `2018-04-20` 56 | 57 | - Design (wireframes) onboarding and bounty-issuing flow that properly accounts for the removed need to get whitelisted and guides users through the creation of their first bounty. 58 | - Decide on the best way to eliminate whitelisting requirement for immediate future. 59 | 60 | **Artifacts:** 61 | 62 | - [ ] mockup of onboarding flow for bounty issuers 63 | - [ ] mockup of onboarding flow for bounty hunters 64 | - [ ] Updated welcome email text for both 65 | - [ ] Decision Record for removal of whitelisting requirement 66 | 67 | ### Iteration 2 — Implementation `2018-05-10` 68 | 69 | Implement the UI for the new flows and make it functional. Once `122-sob-metrics` has laid 70 | the necessary groundwork, start integrating some metrics using the tools defined by that 71 | swarm. 72 | 73 | **Artifacts:** 74 | 75 | - [ ] Functioning onboarding UI and bounty issuing flow that does not require getting whitelisted. 76 | - [ ] Emails that are sent to new users are updated 77 | 78 | ### Iteration 3 — Cleanup `2018-05-30` 79 | 80 | Devise steps to fully migrate to new onboarding flow, refactor relevant code, delete code, clean up UI. 81 | 82 | ## Exit Criteria 83 | - Whitelisting barrier has been removed 84 | - Any user can sign up to SOB and publish a bounty on a repository they own 85 | - The onboarding experience (UI, Emails, etc) has been revised to match the new process 86 | 87 | ## Success Metrics 88 | We don't have proper metrics for Open Bounty yet but this should affect the following: 89 | 90 | - Value transacted through SOB 91 | - Increase number of bounty issuers 92 | - Increase number of bounties issued 93 | - Overall conversion/funnel improvements 94 | 95 | ## Appendix / Notes 96 | 97 | ### Token Whitelisting 98 | 99 | Swarm Compensation Experimentse previously had issues with tokens being added to bounty contracts that have no value/are spam. While not explicitly the goal of this swarm this would be worth solving as well if it turns out to be low-hanging fruit. 100 | 101 | ### `repository.user_id` column 102 | 103 | Currently when users sign up and install the OpenBounty app into their repo their GitHub `user_id` is stored as `repository.user_id`. This ID is later used to look up which address should be able to confirm a payout (specified at bounty deployment). 104 | 105 | This is later often referred to as `repo_owner`. This concept of a `repo_owner` is insufficient as it does not reflect the realities of GitHub. Multiple people should be able to publish/pay out bounties on the same repo — as they can add bounty labels. 106 | 107 | -------------------------------------------------------------------------------- /ideas/088-dapp-experience.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 088-dapp-experience 3 | title: DApp Experience 4 | status: Draft 5 | created: 2018-03-12 6 | category: core 7 | lead-contributor: goranjovic 8 | contributors: 9 | - goranjovic 10 | - asemiankevich 11 | - lukaszfryc 12 | - rachelhamlin 13 | exit-criteria: yes 14 | success-metrics: yes 15 | clear-roles: yes 16 | future-iterations: no 17 | --- 18 | 19 | ## Preamble 20 | 21 | Idea: 88 22 | Title: DApp Experience 23 | Status: Draft 24 | Created: 2018-03-12 25 | 26 | ## Summary 27 | 28 | Interacting with DApps is in the very core of Status. In fact, the shortest description we have for Status is *Mobile Ethereum OS (or Browser)*. 29 | 30 | The problem is that new users do not really get a chance to see this aspect of Status, simply because there are very few DApps accessible directly through Status. The only way to find new DApps is on external web sites or search engines. Having to use an external app to access a core feature of our app is bad UX. Furthermore, users who are completely new to these technologies and generally unfamiliar with the concept of DApps might not even think to look for them and would only use Status as a messenger or possibly a wallet. 31 | 32 | Briefly put, the minimum we need to provide is a nice selection of DApps so that our users could use our Browser feature. 33 | 34 | We had two brainstorming sessions during the Bangkok offsite. The notes from there are on the link below, please do not hesitate to comment: 35 | 36 | https://docs.google.com/document/d/11MRsAO8GdIKVB0bk-osld-cYMMWDOVxB012QHPkQ6_k/edit?usp=sharing 37 | 38 | ## Swarm Participants 39 | 40 | - Lead Contributor: @goranjovic 41 | - Testing & Evaluation: @asemiankevich 42 | - Contributor: @lukaszfryc 43 | - Contributor: 44 | - PM: @rachelhamlin 45 | - UX (if relevant): 46 | 47 | ## Product Overview 48 | 49 | Objectives: 50 | 51 | 1. Provide a definition of decentralized apps 52 | 2. Provide clear inclusion criteria that dapps need to conform with in order to be listed in our catalog 53 | 3. Perform some research o existing dapps for better understanding. For ex https://dappradar.com/ 54 | 4. Create the initial catalog 55 | 5. Provide a transparent and simple process for inclusion of new entries 56 | 57 | Key results: 58 | 59 | 1. Users are able to easily use Status as a browser, having access to a nice and representative list of dapps. 60 | 2. New users are introduced to the concept o dapps and why decentralization matters 61 | 3. Developers who want to list their dapp in our catalog have a simple and fair process to do so and clear criteria their dapp needs to meet. 62 | 63 | Additional notes: 64 | 65 | - We may want to add some kind of user rating to allow users to help each other in dapp selection. This is completely independent from the review criteria that a dapp needs to meet in order to be included in the catalog. 66 | - Inclusion criteria should not contain any subjective criteria such as UX or matters of taste. These concerns should be left to end users to decide. 67 | - We may use Status Open Bounty for the review process. The catalog could be a repository with a list of dapps, new entries could be submitted as pull requests and then reviewers would allow or decline based on the criteria. The exact incentivization strategy remains to be decided (e.g. dapp authors could stake some amount of money, reviewers would be rewarded, etc.) 68 | - We can use a separate repo for the catalog. In fact, DApp Catalog itself could be a dapp. 69 | 70 | 71 | 72 | ### Product Description 73 | 74 | 75 | 76 | ### Requirements & Dependencies 77 | 78 | 79 | ### Minimum Viable Product 80 | 81 | MVP for this is a fixed initial DApp Catalog 82 | 83 | Description: Currently we have 4 Ropsten dapp suggestions in the hardcoded list under Open DApp. This list should be expanded to include 12 DApps total. 84 | These dapps should be verified to work reasonably well (i.e. at all) and the selection should depend on currently selected network (only 85 | Mainnet and Ropsten in scope for this MVP). 86 | 87 | ## Dates 88 | ### Goal Date: 2018-04-18 89 | 90 | Description: Initial DApp Catalog 91 | 92 | Exit Criteria: 93 | - Define criteria for inclusion of DApps in initial catalog 94 | - Update Selected DApps to include 12 DApps that meet these criteria 95 | - Include a description for each 96 | 97 | ## Success Metrics 98 | 99 | - N dapps available out of the box in Status dapp catalog 100 | - X users opening a dapp from the catalog per day 101 | - Y users opening a dapp by URL 102 | - M new dapps submitted, reviewed and added to the catalog each month 103 | 104 | ## Supporting Role Communication 105 | 106 | 107 | ## Copyright 108 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 109 | -------------------------------------------------------------------------------- /ideas/142-wallet-compatibility/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: 142-wallet-compatibility 3 | title: Wallet Compatibility 4 | status: Completed 5 | created: 2018-04-04 6 | category: core 7 | lead-contributor: pilu 8 | contributors: 9 | - pilu 10 | - antdanchenko 11 | - asemiankevich 12 | - flexsurfer 13 | - chadyj 14 | - jpbowen 15 | exit-criteria: yes 16 | success-metrics: yes 17 | clear-roles: yes 18 | future-iterations: yes 19 | roles-needed: 20 | --- 21 | 22 | ## Meta 23 | 24 | Idea: #142 25 | Title: Wallet Compatibility 26 | Status: Active 27 | Created: 2018-04-04 28 | Replaces (*optional): #94 29 | 30 | ## Summary 31 | 32 | Users should be able to use `dapps` on their browser and continue to use them with the same account in Status, and vice versa. 33 | 34 | ## Swarm Participants 35 | 36 | - Lead Contributor: @pilu 37 | - Testing & Evaluation: @antdanchenko 38 | - Testing & Evaluation: @asemiankevich 39 | - Contributor: @flexsurfer 40 | - Contributor: 41 | - PM: @chadyj 42 | - UX (if relevant): @jpbowen 43 | 44 | 45 | ## Product Overview 46 | 47 | Other wallets used to interact with dapps, like MetaMask, Toshi, Cipher, etc., implements BIPs 39/32/44 like Status, and so they derive the keys starting from 12 mnemonic words. 48 | 49 | Given that they use the same standards, users can start playing with a `dapp` with one of those apps, and continue with another one without problems. They can open one of the other apps, and use the same 12 mnemonic words to import their existing account (keys). 50 | 51 | In Status, we implement the same standards to derive the keys starting from the 12 mnemonic words but using different parameters, and we use the password added as an extra entropy in the generation of the seed. 52 | 53 | This means that users can click on "Add existing account" and successfully "import" an account with the 12 mnemonic words that they generated in a different wallet software. 54 | But this process ends up generating different keys and addresses. 55 | Since the generation of the key is different, the account and address are not the ones that the user expected to import. 56 | Users won't be able to log in to `dapps` with the same account they used previously, and won't be able to see the value and collectables they actually have in their wallet. 57 | 58 | To fix this problem, in the Technical Overview we describe the changes that make the generation of the keys compatible with those other wallets. 59 | 60 | Impacts Ideas #58-mainnet and #80-onboarding. 61 | 62 | ### Technical overview 63 | 64 | The changes have been already implemented in [PR 858](https://github.com/status-im/status-go/pull/858), and they already went through the security audit. 65 | 66 | **Changes:** 67 | 68 | * update the BIP39 seed generation to use the salt `"mnemonic"` instead of `"status-im"` following [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#from-mnemonic-to-seed). 69 | 70 | * update the master key generation using the constant `"Bitcoin seed"` instead of `"status-im"`, following [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation). 71 | 72 | * remove the use of the password in the salt during the BIP39 seed generation (password is not removed from the app in general, and it's still required to encrypt the keys on the device). 73 | 74 | ### Relevant reading 75 | 76 | * [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) 77 | * [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 78 | * [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) 79 | 80 | ### User stories 81 | 82 | * As a user, I want to be able to use a `dapp` in Status, and then open the same `dapp` with the same account in a different Wallet Software, using the 12 mnemonic words. 83 | 84 | * As a user, I want to be able to use a `dapp` in an external app, and then using it in Status with the same account imported using the 12 mnemonic words. 85 | 86 | ### Security and Privacy Implications 87 | 88 | The changes went already through the security audit. 89 | 90 | ### Minimum Viable Product 91 | 92 | Goal Date: 2018-05-18 93 | 94 | Description: users can import and export an account to and from Status. 95 | 96 | Testing Days required: 97 | 98 | ## Success Metrics 99 | 100 | * 5k daily active users (OKR 2.1 of Q2) 101 | * 20% of users send a transaction (OKR 2.4 of Q2) 102 | 103 | ## Exit criteria 104 | 105 | Users can use a single account/address for `dapps` and use it both in external apps and in Status. 106 | 107 | ## Supporting Role Communication 108 | 109 | Once deployed, the generation of the keys will change. 110 | It will be impossible to re-import an account created previously. 111 | 112 | ## Copyright 113 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 114 | --------------------------------------------------------------------------------