Merge branch 'master' into 172-topic-democracy

.github/ISSUE_TEMPLATE.md

@@ -1,76 +1 @@
-# Meta
+For ideas, please submit a PR with TEMPLATE.md filled in.
-
-Please submit a PR with the following template filled in. See README.md for more info. 
-
-<!-- Please Review https://docs.google.com/document/d/1CaFM2ZXGOKf05_LXMPJeNNy5qJOdAq91EF2Gn2QUBFI/edit# for more details -->
-<!-- in PR the document should be named as`DEV#1-title.md` -->
-
-## Preamble
-
-    Idea: <to be assigned>
-    Title: <title>
-    Status: <Draft | In Progress | Closed >
-    Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
-    Requires (*optional): <Idea number(s)>
-    Replaces (*optional): <Idea number(s)>
-
-
-## Summary
-<!-- "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the Idea. -->
-
-## Swarm Participants
-<!-- Each contributor pledges to the idea with their FOCUS value. (hours per week) -->
-<!-- Here all roles in swarm are defined and filled, one of the contributors should responsibility of the Idea as Lead. -->
-
-<!-- Testing/Evaluation support role is also mandatory to check in on specified Goal dates or earlier. -->
-
-<!-- Lead Contributor is the Owner of the Idea. If required, they can get support from a PM, but should be responsible for end to end execution of the Idea. This includes ensuring appropriate resources are allocated, setting realistic timelines and milestones, and any post-launch metrics or bug fixes that are attributed to the Idea -->
-<!-- A swarm requires at minimum 3 contributors and 1 evaluator/tester -->
-<!-- 'Contributor' should be replaced with a descriptive role type. -->
-- Lead Contributor: <!-- @username -->
-- Testing & Evaluation: <!-- @username -->
-- Contributor: <!-- @username -->
-- Contributor: <!-- @username -->
-- PM: <!--- @username -->
-- UX (if relevant): <!-- @username -->
-<!-- - Contributor: @username -->
-
-## Product Overview
-<!-- A short (~200 word) description and motivation of the Idea. Without clear explanation the Idea should not proceed. Can include User Stories -->
-<!-- Testing/Evaluation role accepts responsbility to checkin at Goal dates, -->
-<!-- forces discussion to continue implementation or recommend disband and post-mortem. -->
-
-### Product Description
-<!-- What functionality are you adding? What will this look like from a user perspective? Why is this important? -->
-
-### Requirements & Dependencies
-<!-- Are there bugs or feature requests in other repositories that are part of this Idea? -->
-<!-- There is no approval unless the idea requires to be reviewed by supporting organelles (Financial, Hiring, or Design). -->
-<!-- The Swarm must develop a fully fleshed out Requirements document for the idea to proceed, to the satisfaction of participants. -->
-
-### Minimum Viable Product
-<!-- Mandatory, completes the Idea in the fastest route possible, can be hacky, needed to feel progress. See https://imgur.com/a/HVlw3 -->
-Goal Date: <!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --> 
-
-Description: <!-- Description of Deliverables-->
-
-## Dates
-Goal Date: <!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --> 
-
-Description: <!-- Description of Deliverables-->
-
-Testing Days required: <!-- Days required at the end of development for testing -->
-
-## Success Metrics
-<!-- Assuming the idea ships, what would success look like? What are the most important metrics that you would move? -->
-
-<!-- Example: Onboarding conversion rate. Target >30% full funnel -->
-
-## Exit criteria
-<!-- Launch new onboarding UI flow -->
-
-## Supporting Role Communication
-<!-- Once Requirements and Goals are fleshed out, then it should be communicated to supporting organelles if required -->
-
-## Copyright
-Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

.github/github-bot.yml

@@ -0,0 +1 @@
+_extends: probot-settings

.gitignore

@@ -2,3 +2,6 @@
 !.github
 !.gitignore
 !*.md
+_site
+.sass-cache
+.jekyll-metadata

CNAME

@@ -0,0 +1 @@
+ideas.status.im

Gemfile

@@ -0,0 +1,30 @@
+source "https://rubygems.org"
+
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+#     bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+gem "jekyll", "~> 3.7.3"
+
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.0"
+
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+  gem "jekyll-feed", "~> 0.6"
+end
+
+# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
+gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
+
+# Performance-booster for watching directories on Windows
+gem "wdm", "~> 0.1.0" if Gem.win_platform?
+

MANUAL.md

@@ -55,9 +55,9 @@ As a swarm lead, you are responsible for:
 
 #### Being in an interface to the rest of the world.
 
--   Reporting the status of the Swarm at the bi-weekly Town Hall using the report template
+- Reporting the status of the Swarm at the bi-weekly Town Hall using the report template.
 
--   Update Github Issue with this status (simple copy/paste)
+- Update Github Issue with this status (simple copy/paste).
 
 - Interact with other swarm leads to ensure integration points are dealt with.
 
@@ -131,11 +131,42 @@ It’s up to you! It's often useful to keep a public Google Doc with meeting not
 
 Another idea is to record decisions more formally, a la Architecture Recording Decisions.
 
+### Who can merge an idea?
+
+Anyone, as soon as they feel the idea has gone through sufficient review by the
+relevant people.
+
+### What does it mean for an idea to be approved and merged as a draft?
+
+It just means an initial draft looks good enough to continue working on. It
+doesn't mean the idea is necessarily ready to start yet.
+
+### When does an idea turn into progress?
+
+Once the idea is well-defined, create an updated PR that reflects this state
+change and get buy-in from relevant peers. This depends on the specifics of the
+idea.
+
+For user facing swarms, this means PM/UX(R)/Eng consensus.
+
+### Who is the evaluator?
+
+For core contributors: by default, swarm lead acts as the evaluator.
+
+This role is evolving, especially in the context of #121.
+
+### How can we ensure PRs don't drag out and stay open for too long?
+
+General policy: 5-7 days means it is time to either merge or close a PR.
+
+Lazy consensus mechanism: If reviewers come with feedback that isn't addressed
+within a reasonable time frame, the PR can be closed. E.g.: feedback (48h) ping
+(48h) => close PR.
+
 ### I have more questions / feedback
 
 => #swarms in Slack.
 
-
 ## Additional reading
 
 - Organizational design: [https://wiki.status.im/Status\_Organisational\_Design](https://wiki.status.im/Status_Organisational_Design)

README.md

@@ -5,111 +5,8 @@ A space for our ideas - our current, past and future efforts.
 ## Contributing
 
 First review [Status Organizational Design](https://wiki.status.im/Status_Organisational_Design) and
-[Status Swarm Manual](MANUAL.md).
+[Status Swarm Manual](MANUAL.md).  Then submit a Pull Request in this repository.
-Then submit a Pull Request in this repository.
 
-## Classifieds :loudspeaker:
+See (ideas registry)[https://ideas.status.im/all] and (people
-
+registry)[https://ideas.status.im/people] (classifieds and commitment
-Ideas looking for people
+registry).
-
-
-| Idea | Looking for | Swarm lead | In progress? | OKR prios |
-|------|-------------|------------|--------------|-----------|
-| #58  | Clojure dev | Adam       | Yes          | p1: p0    |
-| #145 | PM          | Ricardo    | No           |           |
-| #145 | UX          | Ricardo    | No           |           |
-| #151 | Clojure dev | Ricardo    | No           | p2: p0    |
-
-
-## Idea Registry
-
-An idea can be in the following states: draft, in progress, completed, or
-aborted. Additionally, it can be in limbo which is when it isn't clear what
-state it is in. An idea that has been in limbo for more than a week or so gets
-aborted.
-
-## In Progress :walking_man:
-
-| Idea                                                                | State                     | Success metrics?       | Exit criteria?         | Clear roles?           | Future iteration?      |
-|---------------------------------------------------------------------|---------------------------|------------------------|------------------------|------------------------|------------------------|
-| [127-sob-testing](ideas/127-SOB-testing-process.md)                 | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [120-swarm-process](ideas/120-swarm-process.md)                     | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [121-swarm-compensation](ideas/121-swarm-compensation/)             | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [92-disc-v5-research](ideas/92-disc-v5-research.md)                 | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [87-new-protocol](ideas/87-new-protocol.md)                         | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [83-energy-efficient](ideas/83-energy-efficient.md)                 | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [80-onboarding](ideas/80-onboarding.md)                             | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [68-core-metrics](ideas/68-core-metrics.md)                         | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [63-refactor-geth-packages](ideas/63-refactor-geth-packages.md)     | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [58-mainnet](ideas/58-mainnet.md)                                   | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [34-react-native-qt](ideas/34-react-native-qt.md)                   | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [140-sob-improve-onboarding](ideas/140-sob-improve-onboarding/)     | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [122-sob-metrics](ideas/122-sob-metrics.md)                         | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-| [154-support-web3.js-library](ideas/154-support-web3.js-library.md) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes |
-
-## Draft :seedling: and limbo :question:
-| Idea                                                              | State            | Success metrics?       | Exit criteria?         | Clear roles?           | Future iteration?        |
-|-------------------------------------------------------------------|------------------|------------------------|------------------------|------------------------|--------------------------|
-| [150-gas-abstraction](ideas/150-gas-abstraction.md)               | :seedling: Draft | :white_check_mark: Yes | :x: No                 | :x: No                 | - :white_check_mark: Yes |
-| [027-username-ens-subdomain](ideas/027-username-ens-subdomain.md) | :seedling: Draft | :x: No                 | :white_check_mark: Yes | :x: No                 | - :white_check_mark: Yes |
-| [145-identity](ideas/145-identity.md)                             | :seedling: Draft | :x: No                 | :white_check_mark: Yes | :x: No                 | - :white_check_mark: Yes |
-| [94-wallet-compatibility](ideas/94-wallet-compatibility.md)       | :seedling: Draft | :x: No                 | :white_check_mark: Yes | :white_check_mark: Yes | - :x: No                 |
-| [134-seamless-login](ideas/134-seamless-login.md)                 | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes   |
-| [117-message-ordering](ideas/117-message-ordering.md)             | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :x: No                 | :x: No                   |
-| [99-confidence](ideas/99-confidence.md)                           | :seedling: Draft | :x: no                 | :x: no                 | :x: no                 | :x: no                   |
-| [95-les-service-model](ideas/095-les-service-model/)              | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :x: no                   |
-| [86-push-notif-v2](ideas/86-push-notif-v2.md)                     | :seedling: Draft | :x: no                 | :x: no                 | :x: no                 | :x: no                   |
-| [146-status-go-sdk](ideas/146-status-go-sdk/)                     | :seedling: Draft | :white_check_mark: yes | :white_check_mark: yes | :x: no                 | :x: no                   |
-| [101-extensions](ideas/101-extensions)                            | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | -                        |
-| [142-recovery-compatibility](ideas/142-recovery-compatibility)    | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :x: No                 | -                        |
-
-## Completed :champagne: and aborted :dagger:
-
-| Idea                                                                | State                 | Success metrics?       | Exit criteria?         | Clear roles?           | Future iteration?  |
-|---------------------------------------------------------------------|-----------------------|------------------------|------------------------|------------------------|--------------------|
-| [76-smooth-ui](ideas/smooth-ui.md)                                  | :dagger: aborted      | :white_check_mark: Yes | :x: No                 | :x: No                 | :white_check_mark: |
-| [71-low-traffic](ideas/71-low-traffic.md)                           | :dagger: aborted      | :white_check_mark: Yes | :x: No                 | :x: No                 | :white_check_mark: |
-| [64-release](ideas/64-release.md)                                   | :dagger: Aborted      | :white_check_mark: Yes | :x: No                 | :white_check_mark: Yes | -                  |
-| [61-app-structure-refinement](ideas/61-app-structure-refinement.md) | :champagne: Completed | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | -                  |
-| [3-erc20-token-support](ideas/3-erc20-token-support.md)             | :champagne: Completed | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | -                  |
-| [1-offline-inboxing](ideas/1-offline-inboxing.md)                   | :champagne: Completed | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | -                  |
-
-## Commitment Registry
-
-Over any given iteration, individuals can be committed to 0..N ideas. This
-registry captures this. It is only applied for In Progress swarms. This means it
-is reset for each person per iteration, unless a swarm lead marks it as in
-progress again. This ensures the registry is kept up to date.
-
-| Contributor   |  Ideas |
-|---------------|--------|
-| @anna         |     58, 80, 87, 127 |
-| @adriacidre   | 63, 146     |
-| @andmironov   | 68, 80, 134 |
-| @adambabik    | 58, 63, 68, 92 |
-| @alwx    | 134 |
-| @asemiankevich | 87, 127, 134 |
-| @cammellos    |     87 |
-| @chadyj       | 68, 80, 87, 99, 134 |
-| @churik       |140, 127 |
-| @dshulyak     |     63, 92 |
-| @feuGeneA     |     83 |
-| @flexsurfer   | 34, 80 |
-| @hester       |     80, 134 |
-| @janherich    |     87 |
-| @jeluard      | 68, 101 |
-| @lukaszfryc   | 68, 83 |
-| @mandrigin    |     83 |
-| @martin       |    120 |
-| @MaxRis       |     34 |
-| @naghdy       |     120 |
-| @oskarth      |    120, 121 |
-| @serhy        | 87     |
-| @themue       | 58, 92 |
-| @vkjr         |     34 |
-| @yenda        |     87 |
-| @yevh-berdnyk |     80 |
-| @martinklepsch | 140, 121 |
-| @rcullito | 140 |
-| @EugeOrtiz | 140 |
-| @arash009 | 120, 122, 140 |

TEMPLATE.md

@@ -0,0 +1,134 @@
+---
+id: 000-template
+title: Swarm Template
+status: draft
+created: YYYY-MM-DD
+category: core
+lead-contributor:
+contributors:
+    -
+    -
+    -
+exit-criteria: no
+success-metrics: no
+clear-roles: no
+future-iteration: no
+roles-needed:
+    - QA
+    - PM
+    - UXR
+    - Clojure dev
+    - Go dev
+    - Contracts dev
+    - Designer
+    - Community
+okrs:
+    -
+    -
+---
+
+## Preamble
+
+    Idea: <to be assigned>
+    Title: <title>
+    Status: <Draft | In Progress | Closed >
+    Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
+    Requires (*optional): <Idea number(s)>
+    Replaces (*optional): <Idea number(s)>
+
+## Summary
+
+> "If you can't explain it simply, you don't understand it well enough." Provide
+> a simplified and layman-accessible explanation of the Idea.
+
+## Swarm Participants
+
+> Here all roles in swarm are defined and filled, one of the contributors should
+> responsibility of the Idea as Lead.
+>
+> Lead Contributor is the Owner of the Idea. If required, they can get support
+> from a PM, but should be responsible for end to end execution of the Idea.
+> This includes ensuring appropriate resources are allocated, setting realistic
+> timelines and milestones, and any post-launch metrics or bug fixes that are
+> attributed to the Idea
+>
+> A swarm requires at minimum 3 contributors. For user-facing swarms
+> PM/UX(R)/Eng functions have to be present.
+>
+> For swarms lead by core contributors, swarm lead is evaluator by default.
+>
+> 'Contributor' should be replaced with a descriptive role type.
+
+- Lead Contributor:
+- Evaluator (defaults to lead contributor):
+- Contributor:
+- Contributor:
+- QA:
+- PM (required for user-facing):
+- UX(R) (required for user-facing swarms):
+
+## Product Overview
+
+> A short (~200 word) description and motivation of the Idea. Without clear
+> explanation the Idea should not proceed.
+
+### User Stories
+
+> What user stories are you solving?
+
+### Requirements & Dependencies
+
+> Are there bugs or feature requests in other repositories that are part of this
+> Idea?
+
+### Security and Privacy Implications
+
+> If the security and privacy implications of the idea are non-trivial,
+> elaborate on the problem space and a plan for resolving it here.
+
+## Dates
+
+> Description of deliverables at a given date, for example each Town Hall (default).
+> Add more iterations as required.
+>
+> Evaluator accepts responsbility to checkin at Goal dates, forces discussion to
+> continue implementation or recommend disband and post-mortem.
+>
+> Upcoming Town Halls this quarter:
+> 2018-04-23, 2018-05-07, 2018-05-21, 2018-06-04, 2018-06-18
+
+### Minimum Viable Product
+
+> Mandatory, completes the Idea in the fastest route possible, can be hacky,
+> needed to feel progress. See https://imgur.com/a/HVlw3
+
+Goal Date:
+
+Description:
+
+### Iteration 1
+
+Goal Date:
+
+Description:
+
+## Success Metrics
+
+> Assuming the idea ships, what would success look like? What are the most
+> important metrics that you would move?
+>
+> Example: Onboarding conversion rate. Target >30% full funnel
+
+## Exit criteria
+
+> Example: Launch new onboarding UI flow
+
+## Supporting Role Communication
+
+> Once Requirements and Goals are fleshed out, then it should be communicated to
+> supporting organelles if required
+
+## Copyright
+
+Copyright and related rights waived
+via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

_config.yml

@@ -0,0 +1,48 @@
+# Welcome to Jekyll!
+#
+# This config file is meant for settings that affect your whole blog, values
+# which you are expected to set up once and rarely edit after that. If you find
+# yourself editing this file very often, consider using Jekyll's data files
+# feature for the data you need to update frequently.
+#
+# For technical reasons, this file is *NOT* reloaded automatically when you use
+# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
+
+# Site settings
+# These are used to personalize your new site. If you look in the HTML files,
+# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
+# You can create any custom variable you would like, and they will be accessible
+# in the templates via {{ site.myvariable }}.
+title: Status - Ideas
+email: support@status.im
+description: >- # this means to ignore newlines until "baseurl:"
+  Swarm Home. New, completed and in-progress features for Status.
+twitter_username: ethstatus
+github_username:  status-im
+header_pages:
+  - all.html
+  - people.html
+  - core.html
+  - sob.html
+  - research.html
+  - meta.html
+
+# Build settings
+markdown: kramdown
+theme: minima
+plugins:
+  - jekyll-feed
+
+permalink: /:slug
+
+# Exclude from processing.
+# The following items will not be processed, by default. Create a custom list
+# to override the default setting.
+# exclude:
+#   - Gemfile
+#   - Gemfile.lock
+#   - node_modules
+#   - vendor/bundle/
+#   - vendor/cache/
+#   - vendor/gems/
+#   - vendor/ruby/

_data/contributors.yaml

@@ -0,0 +1,40 @@
+- annadanchenko
+- adambabik
+- adriacidre
+- alwx
+- andmironov
+- antdanchenko
+- arash009
+- asemiankevich
+- cammellos
+- carlbennetts
+- chadyj
+- churik
+- dmitryn
+- dshulyak
+- EugeOrtiz
+- flexsurfer
+- hesterbruikman
+- janherich
+- jason
+- jarradh
+- jeluard
+- jpbowen
+- lukaszfryc
+- mandrigin
+- martinklepsch
+- MaxRis
+- naghdy
+- nastya
+- nikitalukianov
+- oskarth
+- pilu
+- PombeirP
+- rasom
+- rachelhamlin
+- rcullito
+- serhy
+- themue
+- vkjr
+- yenda
+- yevh-berdnyk

_data/statuses.yaml

@@ -0,0 +1,5 @@
+- Draft
+- Active
+- Limbo
+- Completed
+- Aborted

_includes/ideastable.html

@@ -0,0 +1,32 @@
+{% for status in site.data.statuses %}
+  {% assign ideas = include.ideas | where:"status", status%}
+  {% assign count = ideas|size %}
+  {% if count > 0 %}
+    <h2>{{status}}</h2>
+    <table class="ideastable">
+      <thead>
+        <tr>
+          <th class="id">Idea</th>
+          <th class="title">Title</th>
+          <th class="categ">Category</th>
+          <th class="success_metrics">Success metrics?</th>
+          <th class="exit_criteria">Exit criteria?</th>
+          <th class="clear_roles">Clear roles?</th>
+          <th class="future_iterations">Future iterations?</th>
+        </tr>
+      </thead>
+      {% for page in ideas %}
+        <tr>
+          <td class="id"><a href="{{page.url|relative_url}}">{{page.id|xml_escape}}</a></td>
+          <td class="title">{{page.title|xml_escape}}</td>
+          <td class="categ">{{page.category|xml_escape}}</td>
+          <td class="success-metrics">{% if page.success-metrics %}✅ {% else %}❌{% endif %}</td>
+          <td class="exit-criteria">{% if page.exit-criteria %}✅{% else %}❌{% endif %}</td>
+          <td class="clear-roles">{% if page.clear-roles %}✅{% else %}❌{% endif %}</td>
+          <td class="future-iterations">{% if page.future-iterations %}✅{% else %}❌{% endif %}</td>
+        </tr>
+      {% endfor %}
+    </table>
+  {% endif %}
+{% endfor %}
+

_includes/peoplestable.html

@@ -0,0 +1,68 @@
+<h2> Classifieds </h2>
+
+<table class="ideastable">
+  <thead>
+    <tr>
+      <th class="idea">Idea</th>
+      <th class="role_need">Looking for</th>
+      <th class="status">Idea status</th>
+      <th class="okr_prio">OKRs</th>
+    </tr>
+  </thead>
+
+
+  {% assign ideas = include.ideas %}
+  {% assign count = ideas|size %}
+
+  {% for page in ideas %}
+  {% assign count = page.roles-needed|size %}
+  {% if count > 0 %}
+    <tr>
+
+      <td class="idea">
+        <a href="{{page.url|relative_url}}">{{page.id|xml_escape}}</a>
+      </td>
+      <td class="role-needed">
+        {% for role in page.roles-needed %}
+          {{ role }}
+        {% endfor %}
+      </td>
+     <td class="status"> {{ page.status }} </td>
+     <td class="okr">
+       {% for okr in page.okrs %}
+       {{ okr }}<br>
+       {% endfor %}
+
+     </td>
+    </tr>
+    {% endif %}
+  {% endfor %}
+
+</table>
+
+<h2> Commitment registry </h2>
+
+<table class="ideastable">
+  <thead>
+    <tr>
+      <th class="contributor">contributor</th>
+      <th class="ideas">Ideas</th>
+    </tr>
+  </thead>
+
+  {% for contributor in site.data.contributors %}
+  {% assign ideas = include.ideas|where:"status","Active" %}
+
+    <tr>
+      <td class="contributor">{{contributor|xml_escape}}</td>
+      <td class="ideas">
+        {% for page in ideas %}
+        {% if page.contributors contains contributor %}
+          <a href="{{page.url|relative_url}}">{{page.id|xml_escape}}</a>
+        {% endif %}
+        {% endfor %}
+      </td>
+    </tr>
+  {% endfor %}
+</table>
+

all.html

@@ -0,0 +1,6 @@
+---
+layout: page
+title: Ideas
+---
+
+{% include ideastable.html ideas=site.pages %}

ideas/034-react-native-qt/README.md

@@ -1,8 +1,31 @@
+---
+id: 34-react-native-qt
+title: Extend react-native-desktop to support status-react Desktop functionality
+status: Active
+created: 2017-11-22
+category: core
+lead-contributor: MaxRis
+contributors:
+    - MaxRis
+    - vkjr
+    - flexsurfer
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+    - PM
+okrs:
+    - "[P3] Objective: Status is used everyday internally"
+    - "[P0] KR: 80% of core contributors use Status (mobile or desktop) every workday"
+    - "[P3] KR: 10% more usage of Status Desktop than Slack"
+---
+
 ## Preamble
 
     Idea: #34-react-native-qt
     Title: Extend react-native-desktop to support status-react Desktop functionality
-    Status: Draft
+    Status: In-Progress
     Created: 2017-11-22
 
 
@@ -35,7 +58,6 @@ Goal Date: 2017-12-15 (Done)
 Description: Login screen rendering and functionality
 
 ### Iteration 1
-
 Goal Date: 2018-04-09
 Description:
 1. Upgrade react-native-desktop to react-native v.0.53.3 (since latest status-react expects  v.0.53.3 as well) (2018-04-09 update: Done)
@@ -44,9 +66,16 @@ Description:
 
 ### Iteration 2
 Goal Date: 2018-04-23
-1. react-native-desktop running with integrated JavaScriptCore engine instead Node.js on Ubuntu (continuation of Goal 2 from Iteration 1)
+1. react-native-desktop running with integrated JavaScriptCore engine instead Node.js on Ubuntu (continuation of Goal 2 from Iteration 1) (2018-04-23 update: Done)
-2. Porting latest status-react to run on top of react-native-desktop. Work-in-progress. Resolve messages receiving and sending issues.
+2. Porting latest status-react to run on top of react-native-desktop. Work-in-progress. Resolve messages receiving and sending issues. (2018-04-23 update: Done)
-3. Create runnable react-native-desktop app distribution (status-electron MVP based) for Ububntu, OS X and Windows.
+3. Create runnable react-native-desktop app distribution (status-electron MVP based) for Ububntu, OS X and Windows. (2018-04-23 update: Not started)
+
+### Iteration 3
+Goal Date: 2018-05-07
+1. Build status-react Desktop in production
+2. OS X bundle distribution for status-react Desktop
+3. Realm native module support by r-n-d and JavaScriptCore
+4. Ubuntu distribution build of old status-electron for Desktop based on react-native-desktop and JavaScriptCore
 
 Goal Date: TODO
 Description: Integrate react-native-desktop into latest status-react sources with desktops screens available.

ideas/034-react-native-qt/log.md

@@ -1,6 +1,12 @@
 ## Logfile
 
-### 2018-04-10
+### 2018-04-20
+- Known crashes of StatusDesktop are fixed. (Volodymyr)
+- JavaScriptCore is integrated with react-native-desktop and is working on Ubuntu. Changes are not yet merged. (Max)
 
+### 2018-04-14
+- status-react Desktop is running on top of react-native-desktop. Messages sending and receiving working. (Volodymyr)
+
+### 2018-04-10
 - Moved single idea file into swarm directory
 - Added logfile

ideas/086-push-notif-v2/1to1.dot

@@ -0,0 +1,76 @@
+digraph ladder {
+  ranksep="0.5"; nodesep="0.5"; splines="line"; ratio="0.5";
+
+  node [shape=point fontsize=10 fontname="Helvetica"];
+  edge [dir=none fontsize=10 fontname="Helvetica"];
+
+  // Column labels
+  a [shape=Square label="Contact A" style=filled color=lightblue];
+  w1 [shape=Square label="Arbitrary\nNotification Server"];
+  p [shape=Square label="Notification platform\n(e.g. FCM, Pushy)" style=filled color=lightgray];
+  b [shape=Square label="Contact B" style=filled color=lightgreen];
+
+  // Draw the 3 column headings, no line
+  { rank=same; edge[style=invis] a -> w1 -> b -> p   }
+
+  // Force rows to stay aligned
+  { rank=same; edge[style=invis] a2 -> w1_2 -> b2 -> p2   }
+  { rank=same; edge[style=invis] a3 -> w1_3 -> b3 -> p3   }
+
+  // Draw the columns
+  a -> a1 [style=dotted weight=1000];
+  w1 -> w1_1 [style=dotted weight=1000];
+  p -> p1 [style=dotted weight=1000];
+  b -> b1 [style=dotted weight=1000];
+
+  // Draw the vertical lines
+  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];
+  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];
+  p1 -> p2 -> p3 -> p4 -> p5 -> p6 -> p7 -> p8 -> p9 -> p10 [style=dotted weight=1000] p10 -> p11 [weight=1000] p11 -> pmax [style=dotted weight=1000];
+  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"];
+  amax, w1_max, pmax, bmax [style=invis]
+
+  // Hide unused points
+  a5, b1, b2, b3, b4, b5, w1_5, p1, p2, p3, p4, p5, p6, p7, p8, p9 [style=invis height=0];
+
+  // Now each step in the ladder
+  { rank=same; a1 -> w1_1 [dir=back label="Broadcasts availability to serve\nas notification server (1)"]  }
+  { rank=same; w1_1 -> b1 [dir=forward label="Broadcasts availability to serve\nas notification server (1)"]  }
+
+  a2 -> w1_2 [dir=forward label="Sends anonymous Whisper message for registration request,\npassing device registration token and secure channel (SK1) (2)"];
+
+  w1_2 -> w1_3 [label="   Stores data for Contact A\n   (device registration token, SK1)\nCreates AK2" weight=1000];
+  a3 -> w1_3 [dir=back label="Sends message over SK1 channel\naccepting request, and passing pubkey of AK2"]
+
+  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   "];
+  { rank=same; w1_4 -> b4 [dir=both label="Negotiation with PN servers,\nsame process as above for Contact A (...)"]  }
+
+  a6 [xlabel="Contact A starts chat  \nwith Contact B"];
+  { 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"]  }
+
+  { rank=same; a7 -> b7 [dir=back label="[ContactRequestConfirmed]: Responds to contact request.\nNEW: response contains B's AK2 pubkey"]  }
+
+  a8 [xlabel="Contact A wants\nto send a message  \nto Contact B"];
+  { rank=same;
+    a8 -> b8 [dir=forward label="Sends message using common random topic"]  }
+
+  { rank=same;
+    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"] }
+
+  { rank=same;
+    w1_10 -> p10 [dir=forward label="Requests notification to be sent to Contact B's device\nusing stored device registration token"] }
+
+  { rank=same;
+    b11 -> p11 [dir=back label="Sends a data push notification to Contact B's device\ncontaining hash of message payload as an ID"] }
+
+  // Add empty space at the bottom before legend
+  amax -> legend [style=invis weight=1000];
+
+  // Legend
+  { legend [shape=plaintext label=<
+  <table border="0" cellborder="0" cellspacing="0">
+    <tr><td align="left">(1) Communication is done over a discovery topic provided by Status to the PN providers.<br align="left"/>       Message includes pubkey of server's encryption key (AK1).<br align="left"/></td></tr>
+    <tr><td align="left">(2) Channel = random symmetric key + topic to have encrypted communication between peers
+.<br align="left"/></td></tr>
+  </table>>] }
+ }

ideas/086-push-notif-v2/README.md

@@ -1,10 +1,33 @@
-## Preamble
+---
+id: 86-push-notif-v2
+title: Push Notifications v2
+status: Active
+created: 2018-03-01
+category: core
+lead-contributor: PombeirP
+contributors:
+    - PombeirP
+    - nastya
+    - adriacidre
+    - yenda
+    - chad
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+okrs:
+   - "[P0]: Objective: Messaging is reliable"
+   - "[P0]: KR: >95% of 20+ people surveyed trust Status for messaging"
+---
+
+# Meta
 
     Idea: 086
     Title: Push Notifications v2
-    Status: Draft
+    Status: In Progress
     Created: 2018-03-01
-    Q2 Objective: 1.2
+    Q2 Objective: #core 1.2
 
 ## Summary
 
@@ -15,8 +38,8 @@ The [current push notification system](https://docs.google.com/document/d/1OgjnY
 - Lead Contributor: @PombeirP (~20h/week)
 - Testing & Evaluation: @nastya
 - Contributor (Go): @adriacidre (24h/week)
-- Contributor (Clojure): @yenda
+- Contributor (Clojure): @yenda (20h/week)
-- Contributor (QA): @nastya
+- PM: @chad
 
 ## Product Overview
 
@@ -43,9 +66,11 @@ We want to end up with a notification system which works on as many devices as p
 
 We also want a solution that doesn’t involve talking directly to the notification provider, as that would require keeping authentication elements embedded in the app (currently the case), and might expose us to quota theft.
 
-### Flow Diagram
+### Flow Diagram (1:1 chat)
 
-![Alt text](https://g.gravizo.com/source/svg?https%3A%2F%2Fraw.githubusercontent.com%2Fstatus-im%2Fideas%2Fmaster%2Fideas%2F086-push-notif-v2%2Fdiagram.dot)
+![Alt text](https://g.gravizo.com/source/svg?https%3A%2F%2Fraw.githubusercontent.com%2Fstatus-im%2Fideas%2Fmaster%2Fideas%2F086-push-notif-v2%2F1to1.dot)
+
+For group chats, the flow is similar, but it's the chat admin which ensures that each chat member gets a notification channel for every other chat member. Notifications from chat members who left/were removed should be ignored.
 
 ### Goals
 
@@ -69,10 +94,14 @@ At a high-level, we want to move up the current solution a notch regarding some
 
 ### Requirements & Dependencies
 
-- [status-im/ideas#87](https://github.com/status-im/ideas/issues/87): In order to build on a stable foundation, we should make sure we start addressing this after the new communication protocol has landed.
+- [#143-Seamless Login](../143-seamless-login)
 - [status-im/status-react#3451](https://github.com/status-im/status-react/issues/3451): Preview notifications using background app refresh.
-- [status-im/status-react#3488](https://github.com/status-im/status-react/issues/3488): Clicking message notification does not open the chat
+- [status-im/status-react#3488](https://github.com/status-im/status-react/issues/3488): Clicking message notification does not open the chat.
-- [status-im/status-react#3487](https://github.com/status-im/status-react/issues/3487): Notifications about previous messages should disappear when chat is opened
+- [status-im/status-react#3487](https://github.com/status-im/status-react/issues/3487): Notifications about previous messages should disappear when chat is opened.
+
+### Security and Privacy Implications
+
+- It is possible for a third-party to easily exhaust the capacity of a Push Notification server by organizing a distributed attack to consume all the available slots. This should be resolved with paid notification servers.
 
 ## Exit criteria
 
@@ -89,23 +118,45 @@ KRs:
 - 100% of the messages that should generate a notification on the receiving device do so within 15 seconds, under different network conditions (i.e. Wi-Fi, cellular).
 - Network and battery consumption values are same or less than current values.
 
-## MVP(s)
+## Dates
+
+### Minimum Viable Product
+
+Goal Date: 2018-05-07
+
+Description: Show more information on notification
 
-- Single notification provider phase:
-  - Iteration 1: Show more information on notification (date: Beginning Of Work/BOW + 2w)
 - Send only envelope hash on PN to destination device so that it knows to refresh messages and to match them to the notification.
-    - Update message body from retrieved Whisper message.
+- Update message body from retrieved Whisper message ([status-im/status-react#3451](https://github.com/status-im/status-react/issues/3451)).
-  - Iteration 2: Implement notification server mode on `statusd` (date: BOW + 4w)
+
+### Iteration 1
+
+Goal Date: 2018-05-21
+
+Description: Implement notification server mode on `statusd`
+
 - Connects to FCM, only 1 instance, no load-balancing.
 - Add logic to statusd (accept special P2P messages from clients, and trigger notifications in response).
 - Deploy service with Ansible.
 - Change client so that it communicates with notification server to send notifications indirectly to contact.
-  - Iteration 3: Support simple deep-linking (date: BOW + 6w)
+- Address [status-im/status-react#3488](https://github.com/status-im/status-react/issues/3488) and [status-im/status-react#3487](https://github.com/status-im/status-react/issues/3487).
+
+### Iteration 2
+
+Goal Date: 2018-06-04
+
+Description: Support simple deep-linking
+
 - Open respective chat when taping on a notification.
 - Hide notification when the user views the respective message in chat.
-  - Iteration X: TBD
+
-- "Multiple notification provider" phase:
+### Iteration 3
-  - TBD
+
+Goal Date: TBD
+
+Description: TBD
+
+<!-- "Multiple notification provider" phase -->
 
 ## Supporting Role Communication
 

ideas/086-push-notif-v2/diagram.dot

@@ -1,33 +0,0 @@
- digraph ladder {
-  ranksep=".5"; nodesep="1"; splines="line";
-
-  node [shape=point fontsize=10];
-  edge [dir=none fontsize=10];
-
-  // Column labels
-  a [shape=Square label="Contact A"];
-  w [shape=Square label="Notification Server"];
-  b [shape=Square label="Contact B"];
-
-  // Draw the 3 column headings, no line
-  { rank=same; edge[style=invis] a -> w -> b   }
-
-  // Draw the columns
-  a -> a1 [style=dotted weight=1000];
-  w -> w1 [style=dotted];
-  b -> b1 [style=dotted weight=1000];
-
-  a1 -> a2 -> a3 -> a4 -> a5 [weight=1000];
-  a3 [xlabel="Contact A wants\nto send a message\nto Contact B" weight=1000];
-  w1 -> w2 -> w3 -> w4 -> w5 [weight=1000];
-  b1 -> b2 -> b3 -> b4 -> b5 [weight=1000];
-
-  // Now each step in the ladder
-  { rank=same; a1 -> w1 [dir=forward label="Requests topic\nfor notifications\nto Contact B"]  }
-  { rank=same; a2 -> w2 [dir=back label="Replies with its Whisper topic"]  }
-  { rank=same;
-    w3 [shape=none style=invis width=0 height=0 label=""]
-    a3 -> w3;
-    w3 -> b3 [dir=forward label="Sends message\nwith agreed topic"]  }
-  { rank=same; a4 -> w4 [dir=forward label="Sends message using topic received"]  }
- }

ideas/095-les-improvement/README.md

@@ -0,0 +1,115 @@
+---
+id: 095-les-improvement
+title: Improvement of LES
+status: Active
+created: 2018-03-20
+category: research
+contributors:
+    - themue
+    - jeka
+    - b00ris
+    - zsfelfoldi (external)
+exit-criteria: yes
+success-metrics: no
+clear-roles: yes
+future-iterations: yes
+---
+
+## Preamble
+
+    Idea: #095-les-improvement
+    Title: Improvement of LES
+    Status: In progress
+    Created: 2018-03-20
+
+## Summary
+
+Current LES is not yet optimized for ultra-light devices like mobile phones. So in the first step introduce
+the ULC addressing this kind of clients.
+
+Later add the LES Service Model where clients can subscribe to higher quality services. Different payment
+models will be available, negotiation between client and full node is done via auctions based on demands and
+capacity. This way full node service provide are able to monetize the services they provide. LES will make the
+beginning, Whisper and Swarm may follow.
+
+## Swarm Participants
+
+- Lead Contributor: @themue
+- Testing & Evaluation: TBD
+- Contributor: @jeka
+- Contributor: @b00ris
+- PM: @zsfelfoldi (external)
+- UX (if relevant):
+
+## Product Overview
+
+Current LES is not optimized for usage on mobile phones. So Status is using Infura with all its assets and
+drawbacks. ULC is addressing ultra-light clients and distribution without dependency to central providers.
+Instead a network of trusted LES nodes acts as counterpart for the protocol.
+
+So Status is supporting the development and testing of ULC to accelerate integration into *geth*.
+
+Als right now all light clients are treated equal by the full nodes they connect. A future service model will
+introduce the separation between free and payed services. As outlined by Felföldi Zsolt:
+
+- LES will be available either as free or paid service,
+- paid service can guarantee availability and short response times,
+- client bandwidth demand fluctuates with time, good service quality requires reserve capacity,
+- for-profit LES servers can still give away their extra capacity for free (with lower priority than paid service),
+- free service is a good indicator of high bandwidth capacity and therefore the capability to provide good service, and
+- paying clients will prefer servers which already gave them free service so free service can act as an advertisement.
+
+Here Status also supports the development and testing to make the service model become a part of *geth* and be
+integrated into Status.
+
+### Remark
+
+For Status it also could become interesting to become a service provider offering payed full node services not only
+for own clients. This business case should be evaluated in an own swarm.
+
+### Product Description
+
+Parts of ULC and the LES Service Model introduction are:
+
+- research, definition, and implementation of ULC,
+- research, definition, and implementation of connection management system of paying clients for full nodes,
+- research, definition, and implementation of auctioning,
+- research, definition, and implementation of payment methods and models,
+- documentation.
+
+### Minimum Viable Product
+
+Goal Date: 2018-06-30
+
+Description:
+
+- [ ] New Ultra Light Client mode is added to LES
+- [ ] Integrate ULC with `status-go`
+- [ ] Collect metrics (CPU, mem, disk, network I/O) when starting with a branch new install and after 1h of inactivity
+- [ ] Keep battery and network consumption at least as low as today with Infura
+
+### Iteration 1
+
+Goal Date: TBD
+
+Description:
+
+- [ ] Auctioning protocol between client and full node is defined
+- [ ] Payment methods and interfaces are defined
+- [ ] Initial implementation validates auctioning and micropayment in automated tests
+
+## Artifacts
+
+- [Information about Micropayment](micropayment.md)
+- [Logfile](log.md)
+- [Links](links.md)
+
+## Success Metrics
+
+LES of `go-ethereum` is extended to use ULC and provide micropayed services with a higher quality
+level as well as free services depending on capacity and configuration.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+

ideas/095-les-improvement/log.md

@@ -1,5 +1,12 @@
 ## Logfile
 
+### 2018-04-26
+
+- ULC has higher priority to become independend of Infura asap
+- Swarm has been renamed to #095-les-improvement
+- MVP is now ULC integration
+- Iteration 1 is initial development of LES service model
+
 ### 2018-04-12
 
 - Exchange about observer chain/chain filters and sharding

ideas/095-les-service-model/README.md

@@ -1,83 +0,0 @@
-## Preamble
-
-    Idea: #095-les-service-model
-    Title: Introduce LES Service Model
-    Status: Draft
-    Created: 2018-03-20
-
-## Summary
-
-Introduce the LES Service Model where LES clients can subscribe to higher quality services. Different
-payment models will be available, negotiation between client and full node is done via auctions based
-on demands and capacity.
-
-This way full node service provide are able to monetize the services they provide. LES will make the
-beginning, Whisper and Swarm may follow.
-
-## Swarm Participants
-
-- Lead Contributor: @themue
-- Testing & Evaluation:
-- Contributor: @jeka
-- Contributor: @b00ris
-- PM: @zsfelfoldi (external)
-- UX (if relevant):
-
-## Product Overview
-
-Today all light clients are treated equal by the full nodes they connect. A future service model will introduce
-the separation between free and payed services. As outlined by Felföldi Zsolt:
-
-- LES will be available either as free or paid service,
-- paid service can guarantee availability and short response times,
-- client bandwidth demand fluctuates with time, good service quality requires reserve capacity,
-- for-profit LES servers can still give away their extra capacity for free (with lower priority than paid service),
-- free service is a good indicator of high bandwidth capacity and therefore the capability to provide good service, and
-- paying clients will prefer servers which already gave them free service so free service can act as an advertisement.
-
-Once the service model is introduced changes to Status app are needed:
-
-- Migration from Infura to ULC
-- Choice between free and paid LES service
-- In case of paid LES service definition of demands for auction
-
-### Remark
-
-For Status it also could become interesting to become a service provider offering payed full node services not only
-for own clients. This business case should be evaluated in an own swarm.
-
-### Product Description
-
-Parts of the introduction of the LES Service Model are:
-
-- research, definition, and implementation of connection management system of paying clients for full nodes,
-- research, definition, and implementation of auctioning,
-- research, definition, and implementation of payment methods and models,
-- documentation.
-
-### Minimum Viable Product
-
-Goal Date: TBD (before end of Q2/2018)
-
-Description:
-
-- [ ] New Ultra Light Client Mode is added to LES
-- [ ] Auctioning protocol between client and full node is defined
-- [ ] Payment methods or interfaces are defined
-- [ ] Initial implementation validates auctioning and micropayment in automated tests
-
-## Artifacts
-
-- [Information about Micropayment](micropayment.md)
-- [Logfile](log.md)
-- [Links](links.md)
-
-## Success Metrics
-
-LES of `go-ethereum` is extended to provide micropayed services with a higher quality
-level as well as free services depending on capacity and configuration.
-
-## Copyright
-
-Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
-

ideas/1-offline-inboxing.md

@@ -1,3 +1,26 @@
+---
+id: 001
+title: Offline inboxing and persistent messaging
+status: Completed
+created: 2017-10-25
+category: core
+lead-contributor: oskarth
+contributors:
+    - oskarth
+    - annadanchenko
+    - adambabik
+    - naghdy
+    - denis-sharypin
+    - b00ris
+    - JekaMas
+    - dmitryn
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: no
+roles-needed:
+---
+
 ## Preamble
 
     Idea: DEV#001

ideas/101-extensions.md

@@ -1,8 +1,28 @@
-## Preamble
+---
+id: 101-extensions
+title: Extensions
+status: Active
+created: 2018-03-26
+category: core
+lead-contributor: jeluard
+contributors:
+    - asemiankevich
+    - janherich
+    - cammellos
+    - andytudhope
+    - denis-sharypin
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
+## Meta
 
     Idea: 101
     Title: Status extensions
-    Status: Draft
+    Status: In Progress
     Created: 2018-03-26
 
 ## Summary
@@ -12,8 +32,8 @@ A set of extension points so that external developers can enhance status
 ## Swarm Participants
 
 - Lead Contributor: @jeluard
-- Testing & Evaluation: ??
+- Testing & Evaluation: @asemiankevich
-- Contributor: ??
+- Contributor: @cammellos, @janherich
 - PM: @andytudhope
 - UX: @denis-sharypin
 
@@ -31,7 +51,7 @@ There won't be any distinction between those extensions and status itself (it wi
 
 None
 
-### Minimum Viable Product
+### Research
 
 * document existing working features offered by status [API](https://docs.status.im/)
 * list (potential) new types of extensions
@@ -52,11 +72,75 @@ First status hackathon is also a good starting point. [Feedback](https://github.
 
 Note that idea #96 might be the first guinea pig of extensions.
 
-Goal Date: 3 weeks after beginning
+*Started*: 2018-26-03
+*Goal Date*: 3 weeks after beginning
+*Completed*: 2018-20-04
 
 ## Dates
 
-Iterations will be defined based on specification and team feedback.
+### Pre-MVP
+
+Validate technical feasibility.
+
+* general mechanism (UI, conditionals, queries, events)
+* HTML based
+* stored in ipfs (via gateway)
+* entry point: QR code scanner
+* no concept of extension points
+* no custom code
+* extension are activated when loaded and cannot be deactivated
+* simplified app-db
+
+*Started* 2018-04-24
+*Goal Date* 2018-05-09
+
+### MVP
+
+Pre-MVP integrated in Status.
+
+*Duration* 1 week
+
+### Iteration 1
+
+Migrate old commands to extensions.
+
+* implement extension points logic and proposed extension points
+* isolated data per extension
+* migrate existing commands send / request (message-type, update message)
+* detail plan for persistent extensions
+
+*Duration* 2 weeks
+
+### Iteration 2
+
+Add custom code support.
+
+* implement security mechanism
+* remote code loading
+* JavaScript API
+
+*Duration* 2 weeks
+
+### Iteration 3
+
+Persistent extensions.
+
+* implement data persistency
+* implement extension lifecycle
+* extensions can be deactivated
+* add extension registry UI
+
+*Duration* 2 weeks
+
+### Iteration 4
+
+Support dependencies.
+
+* add versioning support
+* extensions can depend on others extensions
+* implement WhoPays
+
+*Duration* 2 weeks
 
 ## Exit criteria
 
@@ -67,8 +151,9 @@ Iterations will be defined based on specification and team feedback.
 
 ## Success Metrics
 
-- 2 internal extensions shipped 
+* 2 internal extensions shipped 
-- 3 external extensions shipped
+* 3 external extensions shipped
-- quality of documentation recognized: few support request related to extensions
+* positive feedback (API, documentation) from 3 external ethereum projects
+* quality of documentation recognized: few support request related to extensions
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/117-message-ordering.md

@@ -1,41 +0,0 @@
-## Preamble
-
-    Idea: #117-message-ordering
-    Title: Message ordering
-    Status: Draft
-    Created: 2018-03-29
-
-## Summary
-
-Addresses point 2 and 3 of https://github.com/status-im/ideas/issues/99 .
-
-Define, document and implement message ordering for 1-to-1, group and public chats so that we can give the best UX experience to the end user.
-
-## Swarm Participants
-
-- Lead & PM: @cammellos
-- Testing & Evaluation: 
-- UX/Design: 
-
-## Product Overview
-
-Because status is a fully decentralized app, message ordering is non-trivial and needs careful thinking in terms of UX, as some constrainsts needs to be taken into consideration.
-
-Currently message ordering in the chat is by the time the message has been received which results in out-of-order messages and potentially different order on different devices.
-
-The primary aim of this swarm is to define which message ordering gives users the best UX experience and implement the changes necessary (if any).
-
-**Goals**
-- Define, document and implement ordering of messages for 1-to-1/group/public chats
-
-### Exit criteria
-
-- Message ordering is clearly defined and documented, including the rationale behind the choices made
-- Code reflecting the choice made is written and released
-- Message ordering implementation is covered by integration tests (at least 80% coverage, as per OKR)
-
-### Success metrics
-
-- A/B testing of different implementations clearly shows a preference for the chosen ordering
-- Ordering of messages can be understood by the end-user through documentation (survey)
-- Implementation of ordering can be understood by developers just by reading the code/tests (survey)

ideas/120-swarm-process/README.md

@@ -1,8 +1,26 @@
+---
+id: 120-swarm-process
+title: Formalize swarm process
+status: Completed
+created: 2018-04-02
+ended: 2018-05-01
+category: meta
+contributors:
+    - martinklepsch
+    - oskarth
+    - naghdy
+    - arash009
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+---
+
 ## Preamble
 
     Idea: 120-swarm-process
     Title: Formalize swarm process
-    Status: In Progress
+    Status: Completed
     Created: 2018-03-30
     Requires (*optional):
     Replaces (*optional):
@@ -36,6 +54,9 @@ this.
 - Possibly UX for communicating things during Town Hall, etc.
 
 ## Product Overview
+
+**UPDATE: Our thinking on this matter has evolved, see [Permission-less and compensated work at Status](permission-less-and-compensated-work.md) for more**
+
 There are two constraints that govern how this structure is designed and
 cultivated. One is that Status the company wants to ship a product, and the
 other is creating a decentralized autonomous organization. Since we are moving
@@ -124,12 +145,16 @@ Description:
 - iii. Town Hall presentation outlining lifecycle, well-definition and roles.
 - iv. Send out survey through Polly.
 
-### Iteration 3
+Town Hall Update: 2017-04-23
-(Buffer)
 
-Possibly something related to Type-1 swarms and communication thereof, but to me
+Progress last two weeks: Update manual and template, clarify swarm’s role in
-once success metric 3 is achieved this is a slightly different focus and thus
+org; static site index; ongoing support and knowledge spreading. 80% of Core
-ideally a different swarm.
+OKRs covered!
+
+Goals for next two weeks: Retainer. Start to wind down swarm. Bounty up
+outstanding issues. Ongoing support.
+
+Lessons learned so far: Updating manual README index is terrible UX.
 
 ## Success Metrics
 
@@ -142,7 +167,6 @@ Three primary success metrics.
 - 1.2. It is clear to me when a swarm ends
 - 1.3. It is clear to me what it means for a swarm to be well-defined
 - 1.4. It is clear to me what is expected of a swarm lead
-- 1.5. It is clear to me what is expected of an evaluator
 
 ### 2. CORE SWARM/OKR COVERAGE.
 80% of Core OKRs are explicit covered by well-defined, in progress swarms.
@@ -160,6 +184,30 @@ future experimentation and compensation tied to it:
 This swarm will be time-boxed to one month and marked as completed May 1 OR when
 success metrics have been met.
 
+## Mini-post mortem
+
+Success metric 2 and 3 achieved. Success metric 1 ended up at 3.7 / 3.7 / 3.9 /
+3.9 respectively, whereas we were aiming for 4.5/5. for this one. So still some
+work to be done there (see section below). Also got a static site index as a bonus at (ideas.status.im)[https://ideas.status.im/].
+
+Will require ongoing support to make sure we follow through, but this can be
+done outside of swarm model, similar to code review etc.
+
+### A few survey take-aways
+
+See raw results in (survey-results)[town-hall-7-survey-results.md].
+
+- Swarm start clarity: global notifications on when swarms start
+
+- Swarm start clarity: some work done in draft/prep mode, line blurry
+> Comment: If in-progress event was tied to compensation being unlocked this would be very clear -- Oskar
+
+- Swarm end clarity: success criteria validation? exit criteria still not clear
+> Comment: Hopefully this will become more clear as more and more swarms finish. -- Oskar
+
+- Swarm well-defined clarity: can be stated more clearly in terms of user stories
+> Comment: In TEMPLATE now https://github.com/status-im/ideas/blob/master/TEMPLATE.md#user-stories - something UXR can assist with too -- Oskar
+
 ## Supporting Role Communication
 
 ## Copyright

ideas/120-swarm-process/permission-less-and-compensated-work.md

@@ -0,0 +1,78 @@
+## Background
+This document outlines the development and participation of contributors to
+Status. In particular we have found: As an open source organisation, we should
+improve and further incentivize community involvement and development Status,
+where people feel comfortable working on whatever they want There are Core
+Contributors [CC] at Status who are paid salaries to solve particular problems.
+
+The purpose of the document is to help core contributors understand how Status
+currently organizes swarms (and their shortcomings) and steps towards improving
+this process.
+
+## Swarms: permission-less and compensated work within Status
+
+Suppose Person A is undertaking a task, and Person B is funding it. Who should
+be evaluating Person A's work?
+
+Naturally it makes sense for Person B to, as they are assuming the risk, though
+they might choose to delegate this responsibility to a trusted person.
+
+### Current Model
+
+In our case, Carl and Jarrad (major SNT holders) are to a large extent
+delegating funding of work through Nabil (COO) and, by further extension, Status
+core contributors. Decision making is done by core contributors. This makes up
+the 'main Status entity', which is currently a form of 'DAO 0.5'.
+
+So how do we currently want to evaluate work? As an entity, we can choose to
+delegate this evaluation to paid core contributors as swarm leads (trusted
+model). Additionally, we can choose to require PM/UX/Eng representation for
+user-facing swarms, as well as a minimum of three contributors per swarm. These
+are evaluation and funding mechanisms we can choose to adapt and formalize,
+where 'contributor time' is a form of funding mechanism, as salary compensation
+is decoupled from the swarm process.
+
+### Shortcomings
+One shortcoming of this is it does not support funding from other SNT holder and
+the wider community. The evaluation and funding mechanism for this could be
+improved/adapted. Similarly, requiring specific roles or minimum contributor
+count is an arbitrary restriction that isn't desirable as a general compensation
+mechanism for getting work done. Example: lone hacker in middle of nowhere doing
+something that is a public good in Status and a funder believes they are able to
+execute on by themselves. Specifically what other forms of evaluation and
+funding mechanisms we want to make easy is something that we will find out as
+time goes on, largely through SOB and its experiments.
+
+What happens with work that doesn't fall neatly within existing categories?? It
+depends on the nature of it. It might be completely isolated from the core app,
+e.g. in the form of organizing meetups, writing content, developing a dapp that
+doesn't require coordination with main code base, etc. If it does involve
+changes in the core app, there's a selection mechanism where we can choose to
+accept or deny such work (example: pull requests in status-react). Since we are
+open source, in case of strong disagreement, one could imagine a fork and
+alternative app artifact being distributed. But in the 99% case it would be in
+the interest of the swarm, as well as its funder, that this work gets into the
+core app. One could look at Status Core Contributors as custodians of the core
+app, and this swarm would likely need to coordinate with CCs to ensure their
+work has impact.
+
+### Where to go from here?
+
+1. Acknowledge that:
+
+a) We will experiment with Swarm evaluation and funding mechanisms (both time
+and money)
+
+b) Swarms experiments won't be restricted by constraints outlined below in [2]
+
+c) To the extent experiments are successful, this might impact below constraints
+
+2. Encode the following evaluation and funding mechanism for salaried core
+contributors:
+
+a) Delegate evaluation of swarm's performance to core contributors in a swarm
+(evaluation process still tbd)
+
+b) Require PM/UX/Eng contributors for user-facing swarms
+
+c) Require a minimum of three core contributors per swarm

ideas/120-swarm-process/town-hall-7-survey-results.md

@@ -0,0 +1,110 @@
+# Raw data from survey after Town Hall 7
+
+## 1. It is clear to me when a swarm starts
+
+(sent to #general)
+
+Strongly Agree 12% (6)
+Agree 54% (28)
+Neutral 25% (13)
+Disagree 10% (5)
+Strongly Disagree
+
+Average: 3.7
+Total Votes: 52
+
+### Comments
+
+> Neutral: WHere are they announced, who validates and create the slack channel?,
+> 
+> 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).
+> 
+> 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.
+> 
+> Neutral: I'm not sure how swarms officially start. Some seem to start without an idea and others seem to stay in draft.
+> 
+> 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!'
+> 
+> Neutral: Start of work and formal establishment of the swarm may overlap.
+> 
+> Agree: I *think* it's when a PR has been requested.,
+> 
+> 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
+> 
+> Disagree: If a swarm lead is not super clear about when the swarm actually starts, then it's not clear when one starts.
+> 
+> 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?,
+> 
+
+## 2. It is clear to me when a swarm ends
+
+(sent to #general)
+
+Strongly Agree 16% (8)
+Agree 49 (28)
+Neutral 29% (15)
+Disagree 6% (3)
+Strongly Disagree
+
+Average: 3.7
+Total Votes: 51
+
+### Comments
+
+> Agree: Scope is done, milestones achieved,
+> 
+> Agree: Highly depends on swarm,
+> 
+> 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.
+> 
+> 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.
+> 
+> Agree: It requires checking after a while whether it hasn't been re-activated, but the concept is clear.
+> 
+> Neutral: Who validates the success metrics?
+> 
+> Agree: All OKRs and exit criteria have been met.,
+> 
+> Neutral: Feels a little less clear and seems as though some swarms with remaining iterations get overshadowed by new swarms or ideas. 
+> 
+> Neutral: Depends on how clear is exit criteria
+> 
+> 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.
+> 
+
+## 3. It is clear to me what it means for a swarm to be well-defined 
+
+(sent to #general)
+
+Strongly Agree 10% (5)
+Agree 61% (31)
+Neutral 25% (13)
+Disagree 4% (2)
+Strongly Disagree
+
+Average: 3.8
+Total Votes: 51
+
+### Comments
+
+> 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
+> 
+> Agree: Must have a specific set of _achievable_ OKRs and exit criteria and resources that can dedicate some time. 
+
+## 4. It is clear to me what is expected of a swarm lead
+
+(sent to #swarms)
+
+Strongly Agree 15% (4)
+Agree 63% (17)
+Neutral 15% (4)
+Disagree 7% (2)
+Strongly Disagree
+
+Average: 3.9
+Total votes: 27
+Agree or strongly agree: 78%
+
+### Comments
+
+No comments.

ideas/121-swarm-compensation/README.md

@@ -1,11 +1,18 @@
 ---
 id: 121-swarm-compensation
 title: Swarm Compensation Experiments
-status: in-progress
+status: Limbo
 created: 2018-04-02
+category: openbounty
 contributors:
     - martinklepsch
     - oskarth
+    - carlbennetts
+    - jason
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
 ---
 
 ## Preamble

ideas/122-sob-metrics.md

@@ -1,3 +1,20 @@
+---
+id: 122-sob-metrics
+title: Open Bounty - Platform Usage Metrics
+status: Active
+created: 2018-04-04
+category: openbounty
+lead-contributor: arash009
+ontributors:
+    - arash009
+    - siphiuel
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
 ## Preamble
 
     Idea: 122-sob-metrics
@@ -40,33 +57,17 @@ The collection of these metrics is to be automated, however their reporting and
 - Effort estimate and high-level schedule established
 
 #### Milestone 2 - '27 April 2018'
-- Report on the metric of Value transacted built
+- All reports have been built and tested
-- Report is testing and bug free
-- Manual reporting mechanism to share the results established
 
 #### Milestone 3 - '11 May 2018'
-- Report on the metric of Active bounty creators built
+- Graphical reports that represent the above metrics over time built and tested
-- Report is testing and bug free
-- Manual reporting mechanism to share the results established
 
 #### Milestone 4 - '25 May 2018'
-- Report on the metric of Active bounty hunters built
+- Create above reports to be made available to bounty creators for their repositories
-- Report is testing and bug free
-- Manual reporting mechanism to share the results established
-
-#### Milestone 5 - '8 June 2018'
-- Report on the metric of Unique pageviews built
-- Report is testing and bug free
-- Manual reporting mechanism to share the results established
-
-#### Milestone 6 - '22 June 2018'
-- Report on the metric of Activation built
-- Report is testing and bug free
-- Manual reporting mechanism to share the results established
 
 ## Exit Criteria
 
-This swarm will be deemed successful and be closed upon the delivery of the above 6 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. 
+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. 
 
 ## Success Metrics
 

ideas/127-SOB-testing-process.md

@@ -1,3 +1,18 @@
+---
+id: 121-sob-testing-process
+title: Improve OpenBounty Testing and make it easy to contribute
+status: Active
+created: 2018-04-02
+category: openbounty
+contributors:
+    - churik
+    - annadanchenko
+    - asemiankevich
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+---
 
 ## Preamble
 

ideas/134-seamless-login.md

@@ -1,70 +0,0 @@
-## Preamble
-
-    Idea: 132
-    Title: Seamless Login
-    Status: Draft
-    Created: 2018-05-04
-
-
-## Summary
-
-When a user opens Status or taps on a push notification they should be able to start using the app quickly without any interruptions, and also have control over authentication preferences.
-
-## Swarm Participants
-- Lead Contributor: @alwx
-- Testing & Evaluation: @asemiankevich
-- PM: @chadyj
-- UX: @andmironov @jpbowen @hesterbruikman
-
-
-## Product Overview
-
-Status frequently logs out users when the app is in the background and forces users to log in again when opening the app. Being repeatedly and unexpectedly logged out has led to frustration and complaints (see Instabug and internal reports) which negatively impact the user experience and potentially contributes to churn. Also, users are encouraged to have complex passwords but this can be cumbersome to enter.
-
-By reducing friction around the critical point of returning to the app users can spend more time in Status which will help DAU and retention (Q2 OKR).
-
-This idea seeks to make logging in seamless through both technical and UX methods.
-
-
-### Product Description
-
-From a users perspective, the user will not repeatedly be logged out when using Status. This will be the default behavior. Since authentication preference is personal, there will be security/login settings so that a user can customize their desired level of control. For example, a user can specify never to be logged out, or choose to log in every time.
-
-When we do ask users to login we want this to be as smooth as possible, and this can be achieved with the (optional) use of device security features such as Touch ID or a pin code. Instead of a password prompt, a user can simply use their fingerprint or look into the phone. This will be set up during onboarding and toggled in settings.
-
-Note, that all transactions require authentication, so even if the phone was lost or stolen a third party couldn’t transfer funds. This idea does not cover the transaction flow.
-
-
-### Iteration 1
-
-During onboarding give users the option to setup seamless authentication (if their device supports it) and use the device/OS conventions to enable, or skip. There will be a setting to manage this preference.
-
-## Iteration 2
-
-Goal Date:
-
-Take seamless login further and fix the root cause of the log outs by restoring from crashes. See [#2869](https://github.com/status-im/status-react/issues/2869#issuecomment-376098196) for some preliminary exploration.
-
-This iteration is completed when users don’t have to type their password after a crash.
-
-
-## Success Metrics
-
-- A user does not need to login after several hours of intermittent use on Android and iOS, as well as logins persistent across upgrades (can it be automated in tests?)
-- UXR validates workflow on real devices with real users
-- 90% of surveyed users are satisfied with the frequency of login requests from Status app
-- 0 password related issues in Instabug
-
-
-## Exit criteria
-
-When Iteration 1 and 2 are complete the success metrics should be evaluated. If the results are successful this swarm can be closed. If work is needed a third iteration can be done to address shortcomings.
-
-## Supporting Role Communication
-
-- Core
-- Marketing
-- Test team
-
-## Copyright
-Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/140-sob-improve-onboarding/README.md

@@ -1,14 +1,19 @@
 ---
 id: 140-sob-improve-onboarding
 title: OpenBounty Improved Onboarding
-status: in-progress
+status: Limbo
 created: 2018-04-04
+category: openbounty
 contributors:
     - martinklepsch
     - Churik
     - EugeOrtiz
     - arash009
     - rcullito
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
 ---
 
 ## Preamble

ideas/142-recovery-compatibility/README.md

@@ -1,4 +1,25 @@
-## Preamble
+---
+id: 142-recovery-compatibility
+title: Wallet Recovery Compatibility
+status: Active
+created: 2018-04-04
+category: core
+lead-contributor: pilu
+contributors:
+    - pilu
+    - antdanchenko
+    - asemiankevich
+    - flexsurfer
+    - chadyj
+    - jpbowen
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
+## Meta
 
     Idea: #142
     Title: Wallet Recovery Compatibility

ideas/143-seamless-login.md

@@ -0,0 +1,113 @@
+---
+id: 143-seamless-login
+title: Seamless Login
+status: Active
+created: 2018-05-04
+category: core
+contributors:
+    - alwx
+    - asemiankevich
+    - chadyj
+    - rasom
+    - andmironov
+    - jpbowen
+    - hesterbruikman
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+okrs:
+   - "[P1]: Objective: Beta is launched successfully"
+   - "[P0]: KR: 5k daily active users"
+---
+
+## Preamble
+
+    Idea: 143
+    Title: Seamless Login
+    Status: In Progress
+    Created: 2018-05-04
+
+
+## Summary
+
+When a user opens Status or taps on a push notification they should be able to start using the app securely, quickly and without any interruptions.
+
+## Swarm Participants
+- Lead Contributor: @alwx
+- Testing & Evaluation: @asemiankevich
+- PM: @chadyj
+- UX: @andmironov
+- UXR: @jpbowen @hesterbruikman
+
+
+## Product Overview
+
+Status frequently logs out users when the app is in the background and forces users to log in again when opening the app. Being repeatedly and unexpectedly logged out has led to frustration and complaints (see Instabug and internal reports) which negatively impact the user experience and potentially contributes to churn. Also, users are encouraged to have complex passwords but this can be cumbersome to enter.
+
+By reducing friction around the critical point of returning to the app users can spend more time in Status which will help DAU and retention (Q2 OKR).
+
+This idea seeks to make logging in seamless through both technical and UX methods.
+
+
+### Product Description
+
+The Status login process should smooth as possible, and this can be achieved with the (optional) use of device security features such as Touch ID or a pin code. In addition to the password prompt, a user can choose to securely use their fingerprint. This will be set up during onboarding and toggled in settings.
+
+Note, all transactions require authentication, so even if the phone was lost or stolen a third party couldn’t transfer funds. This idea does not cover the transaction flow.
+
+For future iterations, this swarm will research the security implications and explore enhancements around logging in, logging out, and recovering from crashes.
+
+### Security and Privacy Implications
+
+Potentially, both Touch ID ("fingerprint authentication") and Face ID can improve security by allowing users to have stronger passwords (the current experience encourages to have a weak password). Of course, it has some disadvantages, but we're going to require passwords anyway for important operations, so the goal is to improve security anyway.
+Moreover, options like "Require authentication every time I open the application" will improve both security and privacy for sure – right now we ask password only in the case user was accidentally logged out.  
+
+Of course, there are some open questions:
+1) We should discuss options like requiring passwords to log in once in a while even if biometrical authentication is used;
+2) Screens like "Settings" or "Backup your Seed Phrase" should be protected by a password?;
+3) We need to discuss the "level of freedom" – what should be the options? 
+4) How can we encrypt/decrypt Realm in the situation when we don't have a password?
+
+Answers to all these question will affect the possible security and privacy implications, but the first iteration will be dedicated to discussions about this topic.
+
+### Iteration 1
+
+Perform some research:
+1) Think more of security and privacy implications; dicuss what exactly needs to be implemented and how;
+2) Discuss different technical aspects like encryption of Realm (look at react-native-keychain and PR [#3829](https://github.com/status-im/status-react/pulls/3829)) and libraries for biometric authentication;
+3) Think of possible restrictions of biometric authentication;
+4) Think of UX: Do we need any special onboarding screen or not? What exactly needs to be added to Settings and how should it look like?
+
+### Iteration 2
+
+1) Implement biometric authentication;
+2) Make all required changes to onboarding flow and Settings;
+3) Perform usability tests;
+4) Perform security analysis.
+
+## Iteration 3
+
+1) Research crashes, logouts, and other related issues. Some exploration has started [here#2869](https://github.com/status-im/status-react/issues/2869#issuecomment-376098196).
+2) Propose fixes that improve both security and usability.
+
+
+## Success Metrics
+
+- UXR validates workflow on real devices with real users
+- 90% of surveyed users are satisfied with loggging in
+- 0 password related issues in Instabug
+
+
+## Exit criteria
+
+When iterations are complete the success metrics should be evaluated. If the results are successful this swarm can be closed. If work is needed an additional iteration can be done to address shortcomings.
+
+## Supporting Role Communication
+
+- Core
+- Marketing
+- Test team
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/146-status-go-sdk/README.md

@@ -1,8 +1,26 @@
+---
+id: 146-status-go-sdk
+title: Status-go-sdk
+status: Active
+created: 2018-04-03
+category: core
+lead-contributor: adriacidre
+contributors:
+    - pilu
+    - lukaszfryc
+    - rachelhamlin
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iteration: no
+okrs:
+---
+
 ## Preamble
 
     Idea: 146-status-go-sdk
     Title: Status GO-SDK
-    Status: Draft
+    Status: In Progress
     Created: 2018-04-03
 
 
@@ -14,7 +32,7 @@ Provide an easy to use GO-SDK library to allow community developers easily inter
 ## Swarm Participants
 - Lead Contributor: [@adriacidre](https://github.com/adriacidre)
 - Contributor: [@pilu](https://github.com/pilu)
-- Contributor:
+- PM: [@rachelhamlin](https://github.com/rachelhamlin)
 - Testing & Evaluation: [@lukaszfryc](https://github.com/lukaszfryc)
 
 
@@ -105,7 +123,7 @@ Testing Days required: TBD
 
 ## Success Metrics
 
-#### Milestone 1: [Status messaging basic interaction](BasicSDK.md)
+#### Milestone 1: [Status messaging basic interaction](BasicSDK.md) (2018-05-07)
   - [ ] [Setup a new connection](BasicSDK.md#setup-a-new-connection)
   - [ ] [Ability to close a specific connection](BasicSDK.md#ability-to-close-a-specific-connection)
   - [ ] [Ability to change connection configuration](BasicSDK.md#ability-to-change-connection-configuration)
@@ -113,7 +131,7 @@ Testing Days required: TBD
   - [ ] [Ability to login as a specific account](BasicSDK.md#ability-to-login-as-a-specific-account)
   - [ ] [Documented API for basic sdk interaction](BasicSDK.md#documented-api-for-basic-sdk-interaction)
 
-#### Milestone 2: [Public channels interaction](PublicChannels.md)
+#### Milestone 2: [Public channels interaction](PublicChannels.md) (2018-05-14)
   - [ ] [Ability to join public channels](PublicChannels.md#ability-to-join-public-channels)
   - [ ] [Ability to publish messages on public channels](PublicChannels.md#ability-to-publish-messages-on-public-channels)
   - [ ] [Ability to subscribe to public channels](PublicChannels.md#ability-to-subscribe-to-publc-channels)
@@ -121,26 +139,26 @@ Testing Days required: TBD
   - [ ] [Documented API for public channels interaction](PublicChannels.md#documented-api-for-public-channels-interaction)
   - [ ] [Working examples for public channel interaction](PublicChannels.md#working-examples-for-public-channel-interaction)
 
-### Milestone 3: [Contact management](ContactManagement.md)
+### Milestone 3: [Contact management](ContactManagement.md) (2018-05-21)
   - [ ] [Invite new contact](ContactManagement.md#invite-new-contact)
   - [ ] [Accept a contact request](ContactManagement.md#accept-contact-request)
 
 
-#### Milestone 4: [1 to 1 messages interaction](1to1Channels.md)
+#### Milestone 4: [1 to 1 messages interaction](1to1Channels.md) (2018-05-28)
   - [ ] TBD : [Ability to send 1 to 1 conversation](1to1Channels.md#ability-to-send-1-to-1-conversation)
   - [ ] TBD : [Ability to subscribe to 1 to 1 conversation](1to1Channels.md#ability-to-subscribe-1-to-1-conversation)
   - [ ] TBD : [Ability to unsubscribe from a 1 to 1 conversation](1to1Channels.md#ability-to-unsubscribe-1-to-1-conversation)
   - [ ] TBD : [Documented API for 1 to 1 conversation](1to1Channels.md#documented-api-for-1-to-1-conversations)
   - [ ] TBD : [Working examples for 1 to 1 conversations](1to1Channels.md#working-examples-for-1-to-1-conversations)
 
-#### Milestone 5: [Private groups interaction](PrivateChannels.md)
+#### Milestone 5: [Private groups interaction](PrivateChannels.md) (2018-06-04)
   - [ ] TBD : [Ability to publish messages on private groups](PrivateChannels.md#ability-to-publish-messages-on-private-groups)
   - [ ] TBD : [Ability to subscribe to private groups](PrivateChannels.md#ability-to-subscribe-to-private-groups)
   - [ ] TBD : [Ability to unsubscribe from a private groups](PrivateChannels.md#ability-to-unsubscribe-to-private-groups)
   - [ ] TBD : [Documented API for private groups interaction](PrivateChannels.md#documented-api-for-private-groups)
   - [ ] TBD : [Working examples for private groups interaction](PrivateChannels.md#working-examples-for-private-groups-interaction)
 
-#### Milestone 6: Extra methods
+#### Milestone 6: Extra methods (2018-06-11)
   - [ ] Ability to recover your account
   - [ ] Ability to log out.
   - [ ] ...

ideas/154-support-web3.js-library.md

@@ -1,3 +1,23 @@
+---
+id: 154
+title: Support web3.js library
+status: Active
+created: 2018-04-09
+category: core
+lead-contributor: flexsurfer
+contributors:
+    - flexsurfer
+    - dmitryn
+    - mandrigin
+    - dshulyak
+    - rachelhamlin
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
 ## Preamble
 
     Idea: 154
@@ -36,18 +56,16 @@ Users can load, log in to, and transact inside any DApp using the Status browser
 
 ### Requirements & Dependencies
 
-- [ ] [#3174](https://github.com/status-im/status-react/issues/3174): Some Android devices can't find web3 library
+- [X] [#3174](https://github.com/status-im/status-react/issues/3174): Some Android devices can't find web3 library
+
+- [X] [#2704](https://github.com/status-im/status-react/issues/2704): Personal sign message support (CryptoKitties blocker)
 
 - [ ] [#784](https://github.com/status-im/status-go/issues/784): Contract handler not called after contract deployment
 
-- [ ] [#2479](https://github.com/status-im/status-react/issues/2479): web3 filters don't work with Status chat bot
-
-- [ ] [#2704](https://github.com/status-im/status-react/issues/2704): Personal sign message support (CryptoKitties blocker)
-
-- [ ] [#3131](https://github.com/status-im/status-react/issues/3131): Scrolling glitch in ERC dEX
-
 - [ ] [#3823](https://github.com/status-im/status-react/issues/3823): Sync calls are not supported in Status 
 
+- [ ] [#2479](https://github.com/status-im/status-react/issues/2479): web3 filters don't work with Status chat bot
+
 - [ ] [#3824](https://github.com/status-im/status-react/issues/3824): [Blockchain Cuties](https://blockchaincuties.co ) does not load inside Status
 
 ### Minimum Viable Product

ideas/167-extended-automated-testing-for-continuous-delivery/README.md

@@ -0,0 +1,81 @@
+---
+id: 167-automated-testing
+title: Functional automated testing as a part of Continuous Delivery process
+status: Active
+created: 2018-04-12
+category: core
+lead-contributor: antdanchenko
+contributors:
+    - antdanchenko
+    - yevh-berdnyk
+    - lukaszfryc
+    - Serhy
+    - asemiankevich
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
+## Preamble
+
+    Idea: 167
+    Title: Functional automated testing as a part of Continuous Delivery process
+    Status: In Progress
+    Created: 2018-04-12
+
+## Summary
+For automated testing to be a part of CD process we need to:
+- increase coverage
+- increase reliability
+- provide visible results on daily basis
+
+## Swarm Participants
+- Lead Contributor: @antdanchenko
+- Testing & Evaluation: @antdanchenko
+- Contributor: @yevh-berdnyk
+- Contributor: @lukaszfryc
+- Contributor: @Serhy
+- Contributor: @asemiankevich
+- PM:
+
+## Product Overview
+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
+As result during nightly build testing a tester should execute only those tests which are not covered by automation in the same TestRun
+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)
+Actual sanity test case which is running against each PR will keep running without changes
+
+
+### Product Description
+- Each automated test suite should be based on existing set of cases from TestRail for tracking percents of functional test coverage
+- Each automated test should be the reflection of a test case from TestRail
+- Results of each automated test from a build should be provided via TestRun in TestRail and linked to the appropriate case
+- An option to review results should be added for each test via adding 4 statuses to TestRail:
+  - feature changed (for changed product behavior)
+  - known bug (link to the issue)
+  - false failure (bug in test)
+  - infrastructure issue
+
+### Minimum Viable Product
+Goal Date: 2018-05-01
+
+- New test suite is add to TestRail (`Functional tests for Nightly Build`)
+- 80% of test cases for nightly build test suite from TestRail are covered by automated tests
+- Extended set of automated tests is running against each nightly build
+- Detailed test results are provided in TestRail via TestRuns + short summary via Slack notification
+
+Testing Days required: 10
+
+## Success Metrics
+- 80% of functional test cases in `Functional tests for Nightly Build` are covered
+- not more than 10% of tests are failing due to an issue with a test
+- results are visible and understandable for all status-react team members
+
+## Exit criteria
+Extended set of automated tests covers 80% of functional nightly test cases from TestRail
+The set is running against each nightly build
+Results are visible in TestRail as TestRuns, also summary is visible in Slack notifications
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/168-paid-master-nodes/README.md

@@ -0,0 +1,260 @@
+---
+id: 168-paid-master-nodes
+title: Paid master nodes
+status: Active
+created: 2018-04-13
+lead-contributor: oskarth
+contributors:
+    - oskarth
+    - rachelhamlin
+    - jpbowen
+    - andytudhope
+    - pilu
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+    - Clojure dev
+    - QA
+    - Designer
+---
+
+## Preamble
+
+    Idea: 168-paid-master-node
+    Title: Paid master nodes
+    Status: In Progress
+    Created: 2018-04-13
+
+## Summary
+In Status, users are stakeholders. This means we pay and get paid based on
+services provided. This includes high-connectivity nodes, aka master node, which
+are used for things like offline inboxing. We choose to let users pay other
+peers for this service, as opposed to providing it for free and selling our
+users.
+
+## Swarm Participants
+
+- Lead Contributor: @oskarth
+- QA: TBD
+- Evaluation: @oskarth
+- Clojure Contributor: TBD
+- Go Contributor: @pilu
+- PM: @rachelhamlin
+- UX(R): @jpbowen
+- Designer: TBD
+- Community: @andytudhope
+
+Risk:
+- Not enough Go and Clojure resources available
+
+Counteract:
+- Create clear issues as bounties
+- Oskar start initial spiking out, be OK with slow progress
+- Proactively reach out to individual devs to try to free up resources
+
+## Product Overview
+
+This idea takes off where
+https://github.com/status-im/ideas/blob/master/ideas/1-offline-inboxing.md
+ended. It provides an SNT payment layer for usage of master nodes.
+
+Users want basic services such as offline inboxing to just work, while at the
+same time paying for the resources they are using, as opposed to being a product
+sold to other businesses. Users also want to make SNT so they can use it in the
+app.
+
+Currently offline inboxing is a free resource, subsidised and run by us. This is
+sub-optimal for many reasons, and goes against our vision of letting users pay
+for things they use, as well as incentivizing this capability to be
+decentralized.
+
+Offline inboxing is run on mail server aka master nodes. In the scope of e.g.
+86-push-notifications push notifications will likely be served through that as
+well.
+
+### User stories
+
+User story 1: Bobby Blockchain runs a master node and gets paid by peers in SNT for services provided.
+
+User story 2: Alice pays SNT to a master node in order to get offline inboxing for some period of time.
+
+Out of scope for this idea:
+
+- (User story 3: Decentralized discovery mechanism for master nodes)
+
+- (User story 4: Onboarding mechanism to seed closed beta users with SNT)
+
+User story 4 is sufficiently different in focus to warrant a separate swarm.
+Since it might be a pre-requsite from a UX point of view, the behavior in user
+story 1 and 2 should be toggle-able with a flag. I.e. we make sure we can still
+provide free service for the time being.
+
+In addition to these defined user-stories, additional ones might be carved out,
+such as communication of quality of service and price discovery mechanisms. It
+is unlikely these will be relevant until user story 1 and 2 are solved, but this
+swarm will decide if it makes sense to continue working to solve additional user
+stories after 1 and 2 are done.
+
+### Product Description
+
+Currently we have a screen that shows mail servers available. Each mail server
+will have a basic monthly fee attached to it. This can start off as static but
+evolve to being dynamically communicated through our application protocol. In
+auction terms, this is an, initially static, bid process.
+
+> Comment from review: Are there any selection criteria for to show users other
+> than price? Eg users/transaction, ratings, reviews, quality?
+
+As a user picks a mail server they are asked to sign a transaction in order to
+pay for offline inboxing for 1..N months. Sending this transaction counts as
+paying for this mail server. This is similar to paying for an app or service in
+the Apple store.
+
+Mail server needs to be able to process this transaction and have logic for
+whitelisting this user's enode for some period of time.
+
+How renewal will happen is not specified yet.
+
+> Comment from review: May be out of scope for this idea but perhaps we'll want
+> to experiment with different payment models for time - e.g. Alice pays until
+> she runs out of SNT OR N offline messages OR set period of time.
+
+Solving the initial user stories doesn't require any proof of message delivery
+or quality of service.
+
+How reputable a given mail server is will thus be communicated outside of the
+app, at least initially. That is, instead of having the equivalent of an App
+Store rating system, or seed ratio on a Torrent site, this can be communicated
+through other means. For example: Riot, Reddit, public status channels, etc.
+
+#### Note on Status Desktop
+
+Status Desktop isn't a requirement for this idea as a user can run a mail server
+from the command line. It is an additional user story that shouldn't be too
+difficult to implement, but it isn't clear how desirable it is, assuming that
+high availabity of mail servers is a requirement.
+
+#### Terminology
+
+Mail server / wnode / master node are used interchangably. Master mode is the
+"soft" user term (invented by the community!), mail server and wnode are
+technical terms on status-go side.
+
+#### Relevant reading
+
+- https://status.im/whitepaper.pdf
+- http://nakamotoinstitute.org/static/docs/micropayments-and-mental-transaction-costs.pdf
+
+### Requirements & Dependencies
+
+(Lack of consensus on this point: Possibly onboarding SNT give-away logistics.)
+
+### Pre MVP - initial investigation and spec
+
+Goal Date: 2018-05-07
+
+Description:
+- [ ] Recruit additional roles: Designer, Clojure dev (yenda?), QA
+- [ ] Spec out rough UX(R) track (jpbowen)
+- [ ] Spike out technical requirements:
+      - [x] deny requests to mail server as a function of peer and envelope
+      - [x] send STT payments and get basic proof
+      - [/] later: inspect basic proof (tx id initially)
+      - [ ] inspect envelope in what format for basic proof of payment?
+- [ ] Create issues (and bounties) necessary for MVP
+- [ ] Communicate proof of payment / accept/deny thinking at kick off call
+
+Probably not enough time: (- [ ] Understand changes to requestMessage envelope required)
+
+Initial investigation to understand how to scope MVP (WIP):
+- https://github.com/status-im/status-react/commit/2a1678ef8724702cee547fdc3ba1f5f03681714a
+- https://github.com/status-im/status-go/commit/a4820285bdb16789477efc06d832bfbd51753ca4
+- [Local mailserver HOWTO](local-mailserver.md)
+- [Getting and sending STT, proof of payment](stt-payment-testing.md)
+
+
+Project board: https://github.com/orgs/status-im/projects/28
+
+Also see:
+- https://github.com/status-im/status-react/issues/4003
+
+### Minimum Viable Product
+Goal Date: 2018-05-21
+
+Description: Spike out most basic proof of concept possible for payment / service on or off in Clojure and Go, using SNT test token (STT) on Ropsten.
+
+Maybe: signing of txid with address.
+
+## Dates
+Separate tracks:
+- UX(R) / design
+- Go dealing with app protocol / payment
+
+Goal Date:
+
+Description:
+
+Testing Days required:
+
+## Success Metrics
+
+- Users running mail servers and transacting. Target: 10
+
+- Users paying for a mail server. Target: 50% of D7 retained users, or 20% of all users.
+
+- Daily Transacting Users. Target: 35 ((5000 DAU TARGET*0.2 TX%)/30 PAY-MONTHLY).
+
+OKRs:
+2.4: >20% of users send a transaction (P1:P3)
+3.1: 2x launched SNT use cases (P2:P0)
+
+## Exit criteria
+
+Solving the two initial user stories. If the swarm deems it useful to continue,
+new specific user stories will be specified and inform the exit criteria.
+
+## Supporting Role Communication
+
+- Community for recruiting users to run mail server.
+
+- Finance for SNT utility approval.
+
+- Marketing for 'you are not the product' rationale communication.
+
+## Appendix: Constraints / objections
+
+- No one will pay for it.
+
+This is a free resource. If we want to subsidise it and the concern is people
+  not wanting to stay / top up to use basic funcrtionality we can solve it by
+  giving free SNT as part of SNT onboarding.
+  
+- Free SNT?!
+
+Yes. For a closed beta limited to 40k people, we can limit the free amount to 5
+SNT per person, which limits the downside risk this to 200k SNT ($20k at the
+time of this writing).
+
+- What about fraud?
+
+We can use already collected emails as identity and dedup by it. Max downside
+per email (pre-signed up) is 5 SNT, and to get it out would still be a
+transaction, as well as a signal to us.
+
+- How does this scale?
+
+For open beta we can figure out how to deal with SNT onboarding by e.g. using
+trustlines.
+
+---
+
+For more on rationale of SNT utility, see the whitepaper. Providing onboarding
+SNT also furthers distribution of tokens as well as transactions on their own, a
+good.
+
+This is a hypothesis, but this is the whole basis of Status.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/168-paid-master-nodes/local-mailserver.md

@@ -0,0 +1,49 @@
+# How to run and use mail server locally
+
+## status-go
+
+Just some notes:
+
+```
+make statusgo
+./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
+```
+
+Verify peers are connected separately:
+
+```
+geth attach ~/git/status-go/paid-data-mailserver/geth.ipc
+admin.peers
+```
+
+## Clojure side
+
+Add local mail server to `constants.cljs` where address is RLPx in print out above, e.g:
+
+```
+"paid" {:id      "paid"
+        :name    "Status testnet mailserver paid, experimental"
+        :address
+        "enode://9f0a55f116aedb40d4036d9a385d505d9c183fd708ef1aa2f883895df97864f758eee911c26c86732ae13a57664a076de2527189f983ee24dda2a4cb5f5db777@127.0.0.1:30303"}
+```
+
+Connect to it, might need to switch networks and login/logout etc to trigger
+requestMessages`. Make sure networks match. Check logs for `offline inbox` to
+see flow. Can switch offline server in advanced settings.
+
+If there are issues with peers, and mail server has peers, then going into CLJS repl and:
+
+```
+(require 'status-im.transport.inbox)
+(status-im.transport.inbox/add-peer "enode://987c40d5761678f030d80de13a2f8a0150da651e5d2c430b96e4f8c2c544389918c7bd820d2d6a5610afb96dcedf8ebb0b941859a0cdbd7dddbbd13994dcbe52@[::]:30303" println println)
+(status-im.transport.inbox/fetch-peers println println)
+```
+
+can help with debugging.
+
+## Notes
+
+Note that this above flow only modifies the 'server' side of mail server and UI
+side of client. If you want to modify status-go node on client side you need to
+make sure status-go is built and linked properly in the app. See
+https://github.com/status-im/status-react/blob/develop/scripts/bundle-status-go.sh

ideas/168-paid-master-nodes/stt-payment-testing.md

@@ -0,0 +1,47 @@
+# Getting and sending STT, proof of payment
+
+Some notes for initial payment MVP and testing thereof.
+
+## How do I get STT?
+
+- Be on Ropsten
+- Advanced settings -> Development mode
+- Chat with console and use `/faucet <StatusFaucet>` to get ETH
+- > 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))
+- You should have 1000 STT
+
+## Sending and getting proof of payment
+
+Send STT tx to <some address> (friend, mail server) with default gas and:
+:status-im.ui.screens.wallet.send.events/transaction-completed
+:response -> :id/:hash => 0x1734f4ff6840ec92b589ca7fc2adbee3c8bcb16b4bffe9954496e00f9d27eeb1
+
+Shows up here: https://ropsten.etherscan.io/tx/0x1734f4ff6840ec92b589ca7fc2adbee3c8bcb16b4bffe9954496e00f9d27eeb1
+
+Can probably be queried in a more trustless way, but requires further
+investigation. Depends on what services are running on mail server.
+
+## Requesting funds?
+Limitation: can't currently request funds in STT. Also coupled with chat, etc.
+Easier to just pop up tx screen. Prefilled.
+
+## Payment for MVP
+
+Navigate to `:wallet-send-transaction` with:
+- recipient
+- STT
+- amount
+- gas price filled in / default
+
+You send it, and once you get tx completed you have hash id. This can be sent to
+mail server who can verify it and accept it. This means you paid and it is up to
+mail server to respect in a way. You send this tx id to mail server. It responds
+with some OK message.
+
+(Ideally funds are locked so you don't send payment and it doesn't respect it,
+but this is a later iteration).
+
+## Problem re proof of payment
+
+If you send tx id, you have enode, but this should be verified with address. So
+ideally you'd sign tx with your account. Iteration 1? Separate dock.

ideas/170-wallet-improvements.md

@@ -0,0 +1,125 @@
+---
+id: 170-wallet-improvements
+title: Wallet Improvements
+status: Active
+created: 2018-04-13
+category: core
+contributors:
+    - goranjovic
+    - asemiankevich
+    - chadyj
+    - denis-sharypin
+    - hesterbruikman
+    - jpbowen
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+okrs:
+   - "[P0]: Objective: Beta is launched successfully"
+   - "[P3]: >20% of users send a transaction"
+---
+
+## Preamble
+
+    Idea: 170
+    Title: Wallet Improvements
+    Status: In Progress
+    Created: 2018-04-13
+    
+## Summary
+
+Status Wallet does not fully support ERC20 tokens (requesting and transaction history not available)
+and generally the transactions UX is different between Chat and Wallet. The intention of this swarm
+is to wrap up those inconsistencies and study and improve wallet and transaction UX problems and
+limitations to make the wallet experience great.
+
+## Swarm Participants
+- Lead Contributor: [@goranjovic](https://github.com/goranjovic)
+- Contributor: 
+- Testing & Evaluation: [@asemiankevich](https://github.com/asemiankevich)
+- PM: [@chadyj](https://github.com/chadyj)
+- UX: [@denis-sharypin](https://github.com/denis-sharypin)
+- UX: [@hesterbruikman](https://github.com/hesterbruikman)
+
+## Product Overview & Description
+
+Add native support for all ERC20 token operations and rudimentary support for ERC721 tokens.
+
+## Use Cases
+
+ - As a user I want to see my ERC20 transactions in history of transactions (Wallet -> Transaction History).
+ - As a user I want to distinguish my ERC20 transactions easily in History of transactions.
+ - As a user I want to understand clearly whom i sent transaction to (ERC20, ETH, etc).
+ - As a user I want to request erc20 tokens in 1x1 chat.
+ - As a user I want to send erc20 tokens in 1x1 chat by responding to appropriate request.
+ - As a user I want to send erc 20 tokens in a group chat.
+ - As a user I want to send erc20 tokens in a group chat by responding to appropriate request.
+
+
+### Requirements & Dependencies
+
+- Possibly depends on extensions swarm for integrations with Chat 
+- Related to #163 - support ERC721 tokens 
+
+
+### Minimum Viable Product
+
+Goal Date: 2018-05-12
+
+Description: 
+
+- Support for ERC20 transaction history in Wallet. 
+- UX improvements derived from UXR sessions
+
+### Iteration 1 
+
+Goal Date: 2018-05-04
+
+Description: 
+
+- Wallet spring cleanup - triage, fix or remove reported bugs so far - https://github.com/orgs/status-im/projects/24
+- Compile UX insights into design decisions for the next iterations 
+- Update the subsequent iterations accordingly
+ 
+### Iteration 2
+
+Goal Date:
+
+Description: 
+- Support for ERC20 tokens in `/send` and `/request` chat command API. 
+This iteration covers the prerequisites on the Command API side.
+- UXR sessions and recommendations 
+ 
+### Iteration 3
+
+Goal Date:
+
+Description: Integration of Send and Request operations between Wallet and Chat.
+
+ 
+### Iteration 4
+
+Goal Date: 
+
+Description: ERC721 support in Wallet
+
+Testing days required:
+
+## Exit Criteria
+
+- Display ERC20 token transfers in transaction history
+- Send ERC20 tokens from chat
+- Request ERC20 tokens from wallet and chat
+- Unified Chat/Wallet transaction UX
+- ERC721 support in Wallet
+
+## Success Metrics
+
+- All exit criteria met
+- UXR retested with measurable improvements
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+

ideas/58-mainnet.md

@@ -1,3 +1,26 @@
+---
+id: 58-mainnet
+title: Use Mainnet as the default network
+status: In Progress
+created: 2017-12-08
+category: core
+contributors:
+    - adambabik
+    - annadanchenko
+    - themue
+    - rasom
+    - chadyj
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+    - Clojure dev
+okrs:
+   - "[P1]: Objective: Beta is launched successfully"
+   - "[P0]: KR: 5k daily active users"
+---
+
 ## Preamble
 
     Idea: 58-mainnet-default
@@ -11,11 +34,11 @@ Alpha builds of Status should default to Mainnet. We should be using Status in a
 
 ## Swarm Participants
 
-- Lead Contributor: @adambabik
+- Lead Contributor: adambabik
-- Testing & Evaluation: @annadanchenko
+- Testing & Evaluation: annadanchenko
-- Contributor: @themue
+- Contributor: themue
-- Contributor: @roman (supportive role; still in need of one Clojure dev)
+- Contributor: roman (supportive role; still in need of one Clojure dev)
-- PM: @chadyj
+- PM: chadyj
 
 ## Product Overview
 
@@ -39,20 +62,28 @@ Also, several DApps should be tested.
 
 **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.**
 
-Goal Date: 2018-04-06
+Goal Date: 2018-04-14
 
-1. [ ] Development of required components is done. The work is tracked here: https://github.com/orgs/status-im/projects/15,
+1. [X] Development of required components is done. The work is tracked here: https://github.com/orgs/status-im/projects/15,
-1. [ ] There is a Status App build with mainnet available,
+1. [X] There is a Status App build with mainnet available,
-1. [ ] All components have been tested by the Test Team,
+1. [X] All components have been tested by the Test Team,
-1. [ ] Mainnet is default in dev/nightly builds.
+1. [X] Mainnet is default in dev/nightly builds.
 
 ## Audit iteration
 
-Goal Date: 2018-04-23
+Goal Date: 2018-05-31
 
 1. [ ] Security audit is finished by an independent company,
 1. [ ] The final report is available,
-1. [ ] All reported security issues are evaluated and fixed.
+1. [ ] All reported security issues and recommendations are evaluated and finished.
+
+### Updates
+
+#### 2018-04-26
+
+- security audit got extended to May 7th,
+- 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),
+- [a feature request](https://github.com/status-im/status-react/issues/3994) to allow custom upstream address was created
 
 ## Status App Bug Bounty iteration (CANCELED)
 
@@ -69,4 +100,3 @@ Goal Date: 2018-04-??
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
-

ideas/63-refactor-geth-packages.md

@@ -1,8 +1,8 @@
 ## Preamble
 
     Idea: 63-refactor-geth-packages
-    Title: Refactor status-go node package
+    Title: Refactor status-go geth packages
-    Status: In Progress
+    Status: Done
     Created: 2017-12-20
 
 ## Summary
@@ -91,5 +91,9 @@ A PR in status-react is created with updated status-go version.
 1. All iterations are done. There is no threat that they can't be finished.
 1. New version of status-go is merged into `status-react` develop branch.
 
+## Summary after finish
+
+The first and second success metrics have been achieved. We managed to reduce dependencies between packages and get rid of `common` package. No change did negatively impact tests reliability and all tests pass properly. With regard to the third metric, we haven't implemented automated race condition checks yet so it's hard to tell but there are no race condition issues reported so far.
+
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/64-release.md

@@ -1,3 +1,33 @@
+---
+id: 64
+title: Release swarm for continuous delivery
+status: Aborted
+created: 2017-12-27
+category: core
+lead-contributor: oskarth
+contributors:
+    - oskarth
+    - annadanchenko
+    - asemiankevich
+    - rasom
+    - adambabik
+    - andytudhope
+    - pablanopete
+    - chadyj
+    - jeluard
+    - yenda
+    - sergii
+    - flexsurfer
+    - goran
+    - lukaszfryc 
+    - churik
+exit-criteria: no
+success-metrics: yes
+clear-roles: yes
+future-iterations: no
+roles-needed:
+---
+
 ## Preamble
 
     Idea: PROC064

ideas/68-core-metrics.md

@@ -1,3 +1,20 @@
+---
+id: 68-core-metrics
+title: Core Metrics
+status: Active
+created: 2018-01-10
+category: core
+contributors:
+    - chadyj
+    - lukaszfryc
+    - jeluard
+    - adambabik
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
 
 ## Preamble
 
@@ -100,7 +117,9 @@ Description: Track basic product events to start measuring engagement
 * [x] [Add Mixpanel client library](https://github.com/status-im/status-react/issues/3537)
 * [x] [Track engagement events](https://github.com/status-im/status-react/issues/3545)
 * [x] Opt-in screen during signup
-* [ ] [Opt-in toggle in settings](https://github.com/status-im/status-react/issues/3538)
+* [x] [Opt-in toggle in settings](https://github.com/status-im/status-react/issues/3538)
+* [ ] [Improve opt-in screen](https://github.com/status-im/status-react/issues/3944)
+* [ ] [Tweaks and improvements](https://github.com/status-im/status-react/issues/3732)
 
 
 ### Success metrics

ideas/80-onboarding.md

@@ -1,3 +1,24 @@
+---
+id: 80-onboarding
+title: Onboarding
+status: Limbo
+created: 2018-01-25
+category: core
+contributors:
+    - andmironov
+    - flexsurfer
+    - annadanchenko
+    - yevh-berdnyk
+    - chadyj
+    - hester
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
+
 ## Preamble
 
     Idea: 80

ideas/83-energy-efficient.md

@@ -1,3 +1,23 @@
+---
+id: 83-energy-efficient
+title: Energy Efficient Status
+status: Active
+created: 2018-02-19
+category: core
+contributors:
+    - mandrigin
+    - lukaszfryc
+    - janherich
+    - yenda
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+okrs:
+   - "[P4] Objective: Performance significantly improves"
+   - "[P0] KR: Reduce power consumption to <120% of Telegram/Skype"
+---
+
 ## Preamble
 
     Idea: 83
@@ -12,7 +32,8 @@ A specific issue about the energy efficiency of different parts of Status (`stat
 
 ## Swarm Participants
 - Lead Contributor: @mandrigin (~25h)
-- Contributor (Go): @feuGeneA 
+- Contributor (Clojure): @janerich
+- Contributor (Clojure): @yenda
 - Contributor (QA): @lukaszfryc (~10h/week)
 
 ## Product Overview
@@ -35,9 +56,9 @@ https://github.com/orgs/status-im/projects/17
 
 
 ## Exit criteria
-- We have test cases and tools to check the energy efficiency of `status-go` and `status-react` independently;
+- [x] We have test cases and tools to check the energy efficiency of `status-go` and `status-react` independently;
-- We can notice regressions/improvements caused, e.g. by updating the version of `go-ethereum` or new features of Status;
+- [x] We can notice regressions/improvements caused, e.g. by updating the version of `go-ethereum` or new features of Status;
-- Top energy draining issues are identified and fixed.
+- [ ] Top energy draining issues are identified and fixed.
 
 ## Success Metrics
 KR: 
@@ -46,8 +67,7 @@ KR:
 
 
 ## MVP(s)
-MVP1 (docs & process): Create and integrate energy efficiency testing as a part of the release process (date: *Mar, 30*)
+MVP (development): Identify top issues with CPU hogging in Status for Android
-MVP2 (development): Create a low-power background mode for status-go (date: *Mar, 30*)
 
 
 ## Supporting Role Communication

ideas/87-new-protocol.md

@@ -1,3 +1,23 @@
+---
+id: 87-new-protocol
+title: New Status App communication protocol
+status: Active
+created: 2018-03-08
+category: core
+contributors:
+    - yenda
+    - asemiankevich
+    - serhy
+    - janherich
+    - cammellos
+    - chadyj
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
 ## Preamble
 
     Idea: 087-new-protocol
@@ -43,26 +63,56 @@ Reasons for that are following:
 - Contributor: @cammellos
 - PM: @chadyj
 
-### Requirements & Dependencies
+
+## Current status of the Swarm
+
+- Weekly sync call on Fridays (contact eric@status.im if you want to join)
+- Focus on solving issues, particularly this one https://github.com/status-im/status-react/issues/4034
+
+## Requirements & Dependencies
 * Describe the new protocol code in a clear and easy to understand way ("birdview" with just each distinct message type and what they represent in term of actions explained)
 * Describe each message type in detail, including all the information encapsulated in it (update whenever new features requiring protocol version inc are added)
 * Describe security mechanism of the new protocol, where the sym/asym keys are used, how they are updated/refreshed, how do we choose whisper topics, etc.
 * Deliver working code for testing, if we desire we can do that in 2 steps and first implement only contact exchange + 1-1 chats via new protocol, with old protocol code handling private + public group chats, and the second and final step will implement that + erase all obsolete old protocol code.
 
-### Minimum Viable Product
+## Minimum Viable Product
 Goal Date: 2018-04-10
 
-Description: The new protocol is merged and supports 1-1 and public group chats. Documentation is finalized in the document https://docs.google.com/document/d/1Qh2h07T_qepzEJ7IytmxwIdQAOsGHrvhXwZxuZtbwgc/edit
+### Description
 
-### Iteration 1
+The new protocol is merged and supports 1-1 and public group chats. Documentation is finalized in the document https://docs.google.com/document/d/1Qh2h07T_qepzEJ7IytmxwIdQAOsGHrvhXwZxuZtbwgc/edit
+
+### Outcome 
+
+This goal has been successfully achieved at the goal date.
+
+### What we could improve
+
+It would be valuable for external developpers and for the sake of tracking future evolutions to the protocol to have the documentation ported into a repository and generate a static website to expose the documentation to the outside world.
+
+There's been discussions around the encoding for the communication protocol and it was mentionned that protocol buffers might be a better solution than transit for portability. We are going to research that topic and gather feedback from other teams working on whisper on that matter.
+
+## Iteration 1
 Goal Date: 2018-04-17 
 
-Description: Group chats are implemented and all bugs fixed
+### Description 
 
-### Iteration 2
+- TODO Group chats are implemented and all bugs fixed
-Goal Date: 2018-04-24
 
-Description: Support for versionning is confirmed and tested experimentally. A benchmark for bandwith consumption in advanced features allows testers to verify performance claims with real conditions. Crypto libraries have been removed and traces of transport layer concerns have all been removed from the application code and database schemas
+### Outcome
+
+This goal was not reached. Amount of time available/amount of time required was not matched.
+
+Group chat are removed from the scope after discussion involving @yenda, @oskarth, @cammellos and @chadyj here https://github.com/status-im/ideas/pull/224#discussion_r184694789 (note: they were already disabled as of 0.9.16 because of bugs)
+
+## Iteration 2
+Goal Date: 2018-05-04
+
+### Description
+
+- TODO Support for versionning is confirmed and tested experimentally. 
+- TODO A benchmark for bandwith consumption in advanced features allows testers to verify performance claims with real conditions. 
+- DONE Crypto libraries have been removed and traces of transport layer concerns have all been removed from the application code and database schemas
 
 ## Success Metrics
 * We have protocol versioning, so we can say that for example release 0.9.15 and 0.9.16 are using the same protocol version v1, so are fully compatible and people can communicate with each other.

ideas/90-branch-perf-stats.md

@@ -0,0 +1,105 @@
+---
+id: 090-branch-perf-stats
+title: Make branch performance stats visible
+status: draft
+created: 2018-03-12
+category: core
+lead-contributor: PombeirP
+contributors:
+    -
+    -
+    -
+exit-criteria: no
+success-metrics: no
+clear-roles: no
+future-iteration: no
+roles-needed:
+    - DevOps
+    - Go dev
+okrs:
+   - "[P4]: Objective: Implement continuous delivery"
+   - "[P0]: KR: >80% automated test coverage"
+---
+
+## Preamble
+
+    Idea: 090
+    Title: Make branch performance stats visible
+    Status: Draft
+    Created: 2018-03-12
+
+## Summary
+
+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.
+
+## Swarm Participants
+
+- Lead Contributor: PombeirP
+- Contributor (Go): TBD
+- Contributor (DevOps): TBD
+
+## Product Overview
+
+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.
+
+### User Stories
+
+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.
+
+### Requirements & Dependencies
+
+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.
+
+### Security and Privacy Implications
+
+N/A
+
+## Dates
+
+> Description of deliverables at a given date, for example each Town Hall (default).
+> Add more iterations as required.
+>
+> Evaluator accepts responsbility to checkin at Goal dates, forces discussion to
+> continue implementation or recommend disband and post-mortem.
+>
+> Upcoming Town Halls this quarter:
+> 2018-04-23, 2018-05-07, 2018-05-21, 2018-06-04, 2018-06-18
+
+### Minimum Viable Product
+
+> Mandatory, completes the Idea in the fastest route possible, can be hacky,
+> needed to feel progress. See https://imgur.com/a/HVlw3
+
+Goal Date:
+
+Description:
+
+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.
+
+**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:
+
+![graph](https://user-images.githubusercontent.com/138074/37280336-c04ad1c6-25ed-11e8-8064-1dd4a01c4882.png)
+
+### Iteration 1
+
+Goal Date:
+
+Description:
+
+## Success Metrics
+
+- 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.
+- Builds with a lower quality (network consumption, etc) fail automatically.
+
+## Exit criteria
+
+- status-go and status-react builds are handled and success metrics are fulfilled for those two teams.
+
+## Supporting Role Communication
+
+N/A
+
+## Copyright
+
+Copyright and related rights waived
+via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/92-disc-v5-research.md

@@ -1,3 +1,20 @@
+---
+id: 92-disc-v5-research
+title: Research Ethereum Discovery V5 Protocol
+status: Active
+created: 2018-03-12
+category: core
+contributors:
+    - adambabik
+    - dshulyak
+    - themue
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+---
+
 ## Preamble
 
     Idea: #92-disc-v5-research
@@ -20,25 +37,67 @@ Discovery protocol will allow us to dynamically change the number of server peer
 The biggest challenge may be increased CPU and network usage. This needs to be carefully measured and we may end up with proposing some protocol changes.
 
 ### Product Description
+
 This is a research swarm. It must provide answers to the following questions:
-- [ ] CPU/network increase usage. How does it change in absolute and relative values? How to reproduce the measurement?
+
-- [ ] Can we turn on and off discovery protocol when the node is running?
+#### Q: CPU/network increase usage. How does it change in absolute and relative values? How to reproduce the measurement?
-- [ ] Can Discovery V5 protocol carry more information than protocol name and version? How can we distinguish Light Whisper nodes or Whisper nodes with MailServer capability? Notice that revealing this information (like Light Whisper node) may increase a chance to reveal the peer identity. The fact that we don’t want mobile phones to be each other peers raises this question.
+
-- [ ] How to make sure that connecting to the cluster will be fast? When the app goes to the background, does it take significantly more time to find peers? Do we need to use cache? From the cluster perspective, how to autoscale cluster so that its free capacity is always high?
+**A:** TBD
-- [ ] How to make sure that there are always at least `N` peers with given capabilities? For instance, we always want to have at least `K` Whisper, `L` MailServer and `M` LES peers connected.
+
+
+#### Q: Can we turn on and off discovery protocol when the node is running?
+
+**A:** Yes. First of all, we can tell how often the Discovery V5 should search for new peers with a given topic. Also, as we implemented Discovery V5 as a peer pool, we managed the list of peers. If the number of peers found for all topics is equal or exceed the upper limit, we can disable Discover V5 completely.
+
+
+#### Q: Can Discovery V5 protocol carry more information than protocol name and version? How can we distinguish Light Whisper nodes or Whisper nodes with MailServer capability? Notice that revealing this information (like Light Whisper node) may increase a chance to reveal the peer identity. The fact that we don’t want mobile phones to be each other peers raises this question.
+
+**A:** Topic can be an arbitrary `key=value` pair. The rest will be answer later...
+
+
+#### Q: How to make sure that connecting to the cluster will be fast? When the app goes to the background, does it take significantly more time to find peers? Do we need to use cache? From the cluster perspective, how to autoscale cluster so that its free capacity is always high?
+
+**A**: We need a cache to quickly provide the list of recently used peers. If the app fails to connect to them, it will use Discovery V5 in fast mode (checking for new peers more often).
+
+To use Discovery V5, we need to set up bootnodes, however, they can use the existing server nodes, provided that they advertise Discovery V5 topics.
+
+*Provide answer for cluster autoscaling.*
+
+
+#### Q: How to make sure that there are always at least `N` peers with given capabilities? For instance, we always want to have at least `K` Whisper, `L` MailServer and `M` LES peers connected.
+
+**A:** This is implemented in [`github.com/status-im/status-go/geth/peers`](https://github.com/status-im/status-go/tree/develop/geth/peers) package. For each topic we are interested in, a lower and upper limits are provided. `PeerPool` and `TopicPool` take care of maintaining the number of peers within the limits.
+
 
 ### Requirements & Dependencies
 The discovery protocol should be testable locally with Docker, but for some more extensive tests, we will utilse a Docker Swarm cluster.
 
 ### Minimum Viable Product
-Goal Date: 2018-04-08
+Goal Date: 2018-04-27
 
 Description:
 1. All questions described in Product Description are researched and answered,
-1. It's possible to start statusd and Status App with DiscV5 enabled instead of static nodes (switch between them with a flag would be great),
+1. It's possible to start `statusd` and Status App with DiscV5 enabled instead of static nodes (switch between them with a flag would be great),
-1. There is an automated way to collect CPI and network usage metrics in an isolated environment.
+1. There is an automated way to collect CPU and network usage metrics in an isolated environment.
 
-#### Exit criteria
+### Iteration 1
+
+Goal Date: 2018-05-18
+
+Description:
+- [ ] increase awarness by changing the UI copy that Rinkeby network uses Discovery protocol,
+- [ ] ~~make LES working in Mainnet and Ropsten~~ (this is not in scope of this swarm as we haven't decided between LES vs ULC),
+- [ ] make sure the current MailServers as static peers work,
+- [ ] run a job in Jenkins daily that will print network I/O statistics of Discovery mode (to make sure that changes we make to Discovery V5 actually improve it).
+
+## Updates
+
+### 2018-04-27
+
+- Added `Iteration 1`.
+
+
+## Exit criteria
 
 1. Assess if DiscV5 is a viable protocol to replace static nodes.
 1. If so, there is a list of issues that we should work on to further improve DiscV5 usage in the Status app and in the cluster (this may be realized as next iterations or a new swarm).

ideas/96-message-tributes.md

@@ -0,0 +1,115 @@
+---
+id: 96-message-tributes
+title: Tribute to Talk
+status: Active
+created: 2018-03-20
+category: core
+lead-contributor: richard-ramos
+contributors:
+    - richard-ramos
+    - 3esmit
+    - rachelhamlin
+    - denis-sharypin
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+roles-needed:
+    - Clojure dev
+okrs:
+    - "[P2] Objective: SNT is a powerful utility in Status"
+    - "[P0] KR: 2x launched SNT use cases"
+    - "[P0] KR: 2x demo’s/proof of concepts using SNT"
+    - "[P4] KR: 2x Fleshed out description of the utility"
+---
+
+## Preamble
+
+    Idea: 96
+    Title: Tribute to Talk
+    Status: In Progress
+    Created: 2018-03-20
+    Requires (*optional): TBD
+
+
+## Summary
+Economics-based anti-spam filter, in our case for receiving messages and “cold” contact requests from users.
+
+
+## Swarm Participants
+- Lead Contributor: @richard-ramos
+- Testing & Evaluation: 
+- Contributor: @3esmit
+- PM:  @rachelhamlin
+- UX: @denis-sharypin
+
+
+## Product Overview
+This enables stakeholders to set a minimum amount of SNT that a Status stakeholder must deposit in order for someone outside of their network to contact him directly. If the recipient replies the deposit is forfeited to the recipient.
+
+**SNT Utility**
+
+SNT is deposited, and transferred from stakeholders to recipients upon receiving a reply from the recipient.
+
+Example use-cases
+
+- Stakeholder A, a professional, would like to reach out to a high profile figure in the same industry, but would otherwise have no means of receiving a response.
+- Stakeholder B, an artist and celebrity wishes to spend some time chatting with fans, and also desires a means of monetizing their fan base.
+- Stakeholder C, a freelancer, provides photography tutorials, and has a means of generating revenue.
+
+### Product Description
+Any Status user can enable Tribute to Talk and set a minimum required deposit for other users to stake in order to send them a message. Users requiring a tribute can whitelist their full contact list, or specific contacts.
+
+If User A requires a minimum 200 SNT deposit, User B will not be able to open a new chat with User A until they deposit at least 200 SNT. Once deposited, User B can send their message.
+
+If User A responds to User B’s message, the deposit is transferred to User A, and a conversation is opened.
+
+If User A does not respond or User B changes their mind, User B can cancel or withdraw the request. The request will also time out automatically if User A does not respond in some number of days. In any case where User A does not respond, the deposit is returned to User B.
+
+If User A rejects User B’s request, User B’s deposit is returned. User B will have to wait some amount of time before they are able to send a new request to User A.
+
+In the future, User A might have the option to respond to User B but waive the deposit. User B might have the option to make a tribute to User A without requiring a response. 
+
+
+### Requirements & Dependencies
+<!-- Are there bugs or feature requests in other repositories that are part of this Idea? -->
+<!-- There is no approval unless the idea requires to be reviewed by supporting organelles (Financial, Hiring, or Design). -->
+<!-- The Swarm must develop a fully fleshed out Requirements document for the idea to proceed, to the satisfaction of participants. -->
+
+### Minimum Viable Product
+Goal Date: TBD 
+
+Description:
+For the initial delivery, these are the minimum features proposed.
+- [ ] UI for recipients to set Tribute to Talk with required minimum deposit for any new chat
+- [ ] UI for requesters to send minimum SNT deposit and their message to users with Tribute to Talk enabled
+- [ ] UI for requesters to cancel a request and withdraw deposit
+- [ ] UI for recipient to respond to or reject new requests 
+- [ ] Deposit is transferred from requester to recipient when recipient responds
+- [ ] Deposit is returned to requester if rejected or withdrawn
+
+Next milestones and deliverables would be determined discussing and prioritizing features of the product description
+
+## Dates
+Goal Date: TBD 
+
+Description: TBD 
+
+Testing Days required: TBD 
+
+## Exit Criteria
+Any user can set up Tribute to Talk and require a deposit minimum to be contacted. Other users can put down a deposit to message them. New requests can be responded to, rejected or withdrawn. The deposit is transferred when a recipient responds, and sent back if they reject or the requester withdraws.
+
+## Success Metrics
+Initial emphasis is on TtT working as expected and producing no bugs for critical events. 
+
+- Message requests are delivered 100% reliably from requester to recipient.
+- Message responses by recipients are successfully recognized in all instances, both accepted and rejected.
+- Transfer or return of deposit to either recipient or requester is successful.
+
+
+## Supporting Role Communication
+TBD
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

ideas/99-confidence.md

@@ -1,8 +1,29 @@
+---
+id: 99-confidence
+title: Confidence in Messaging
+status: Active
+created: 2018-03-22
+category: core
+contributors:
+    - rasom
+    - lukaszfryc
+    - mandrigin
+    - dmitryn
+    - chadyj
+    - nikitalukianov
+    - jpbowen
+    - hesterbruikman
+exit-criteria: yes
+success-metrics: yes
+clear-roles: yes
+future-iterations: yes
+---
+
 ## Preamble
 
     Idea: 99
     Title: Confidence in Messaging
-    Status: Draft
+    Status: In Progress
     Created: 2018-03-22
 
 
@@ -14,9 +35,9 @@ As end users we currently don't have confidence that messages are being sent, de
 - Testing & Evaluation: @lukaszfryc
 - Contributor: @cammellos
 - Contributor: @mandrigin
-- Contributor: #dmitryn 
+- Contributor: @dmitryn
 - PM: @chadyj
-- UX (if relevant): @nikitalukianov @jpbowen @hesterbruikman
+- UX: @nikitalukianov @jpbowen @hesterbruikman
 
 ## Product Overview
 
@@ -90,30 +111,38 @@ Request messages history after background: https://github.com/status-im/status-r
 New protocol https://github.com/status-im/status-react/pull/3273
 https://github.com/status-im/ideas/issues/87
 
-### Minimum Viable Product
+### Security and Privacy Implications
-Goal Date: <!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --> 
 
-Description: <!-- Description of Deliverables-->
+None currently known.
 
-**TBD**
+### Iteration 1
-Probably something like: Select subset of above to implement/finish; do initial community check, do design basics and plan initial UXR session.
 
-## Dates
+Complete several reliability improvements that have been identified so far:
-Goal Date: <!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --> 
 
-Description: <!-- Description of Deliverables-->
+- [#3827 Message reliability survey](https://github.com/status-im/status-react/issues/3827)
+- [#3793 Improve timestamps in chat messages](https://github.com/status-im/status-react/issues/3793)
+- [#3787 Improve network offline and mail server error messaging](https://github.com/status-im/status-react/issues/3787)
+- [#3784 Provide users with delivery status feedback when sending messages](https://github.com/status-im/status-react/issues/3784)
+- [#3792 Measure message send/receive ratio on internal builds ](https://github.com/status-im/status-react/issues/3792)
+- [#828 Send an expiration signal when envelope wasn't delivered to any peer](https://github.com/status-im/status-go/pull/828)
+- [#810 Notify clj side when the message actually "left" local node.](https://github.com/status-im/status-go/issues/810)
+- [#3785 Remove "seen by everyone" from public chat](https://github.com/status-im/status-react/issues/3785)
 
-Testing Days required: <!-- Days required at the end of development for testing -->
+### Iteration 2
+
+After iteration 1 is complete the swarm will meet and discuss the results of the UXR survey, send/receive ratio results, review current UX and discuss future iterations. Work will then be planned for a future iteration, or the swarm will be closed.
+
+## Exit Criteria
+
+- >99% message deliverability from [#3792](https://github.com/status-im/status-react/issues/3792)
 
 ## Success Metrics
-**TBD**
 
-95% of a group of 20-100 users surveyed - who don't have additional context beyond Status providing a p2p IM capability - using the app for an extended period of time, should answer 'yes' to the question: "Do you trust Status to deliver messages for you?" (and possibly variants of this).
+95% of a group of 100 users surveyed - who don't have additional context beyond Status providing a p2p IM capability - using the app for an extended period of time, should answer 'yes' to the question: "Do you trust Status to deliver messages for you?" (and possibly variants of this).
 
 This is fundamentally a soft or qualitative goal. It is thus necessary but not necessarily sufficient, and additional harder numbers might be used as we develop the capability to measure this.
 
 Zero instabug reports within 30 days of alpha release
 
-## Supporting Role Communication
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

index.html

@@ -0,0 +1,12 @@
+---
+layout: default
+title: Home
+---
+
+<h1>Status Ideas</h1>
+
+<p>A space for our ideas - our current, past and future efforts.</p>
+
+<h2> Contributing</h2>
+
+See <a href="https://github.com/status-im/ideas">Github</a>.

people.html

@@ -0,0 +1,6 @@
+---
+layout: page
+title: People
+---
+
+{% include peoplestable.html ideas=site.pages %}