status-im/swarms
2
0
Fork 0
mirror of https://github.com/status-im/swarms.git synced 2025-02-23 07:08:19 +00:00
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into 172-topic-democracy

Browse Source
This commit is contained in:
Ricardo Guilherme Schmidt 2018-04-27 02:31:26 -03:00
commit 59cfe93766
13 changed files with 477 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
README.md
View File

@ -13,13 +13,12 @@ Then submit a Pull Request in this repository.
Ideas looking for people Ideas looking for people
| Idea | Looking for | Swarm lead | In progress? | OKR prios | | Idea | Looking for | Swarm lead | In progress? | OKR prios |
|------|-------------|------------|--------------|----------------------| |------|-------------|------------|--------------|-----------|
| #58 | Clojure dev | Adam | Yes | p1: p0 | | #58 | Clojure dev | Adam | Yes | p1: p0 |
| #145 | PM | Ricardo | No | | | #145 | PM | Ricardo | No | |
| #145 | UX | Ricardo | No | | | #145 | UX | Ricardo | No | |
| #151 | Clojure dev | Ricardo | No | p2: p0 | | #151 | Clojure dev | Ricardo | No | p2: p0 |
| #096 | UX | Richard | Yes | p2: p0 |
## Idea Registry ## Idea Registry
@ -31,47 +30,49 @@ aborted.
## In Progress :walking_man: ## In Progress :walking_man:
| Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? | | 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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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 | | [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: ## Draft :seedling: and limbo :question:
| Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? | | Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? |
|---------------------------------------------------------------------|---------------------------|------------------------|------------------------|------------------------|-----------------------------------| |-------------------------------------------------------------------|------------------|------------------------|------------------------|------------------------|--------------------------|
| [145-identity](ideas/145-identity.md) | :seedling: Draft | :x: No | :white_check_mark: Yes | :x: No | - :white_check_mark: Yes | | [150-gas-abstraction](ideas/150-gas-abstraction.md) | :seedling: Draft | :white_check_mark: Yes | :x: No | :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 | | [027-username-ens-subdomain](ideas/027-username-ens-subdomain.md) | :seedling: Draft | :x: No | :white_check_mark: Yes | :x: No | - :white_check_mark: Yes |
| [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 | | [145-identity](ideas/145-identity.md) | :seedling: Draft | :x: No | :white_check_mark: Yes | :x: No | - :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 | | [94-wallet-compatibility](ideas/94-wallet-compatibility.md) | :seedling: Draft | :x: No | :white_check_mark: Yes | :white_check_mark: Yes | - :x: No |
| [99-confidence](ideas/99-confidence.md) | :seedling: Draft | :x: no | :x: no | :x: no | :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 |
| [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 | | [117-message-ordering](ideas/117-message-ordering.md) | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :x: No | :x: No |
| [86-push-notif-v2](ideas/86-push-notif-v2.md) | :seedling: Draft | :x: no | :x: no | :x: no | :x: no | | [99-confidence](ideas/99-confidence.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 | | [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 |
| [76-smooth-ui](ideas/smooth-ui.md) | :question: Limbo | :white_check_mark: Yes | :x: No | :x: No | :white_check_mark: Yes :question: | | [86-push-notif-v2](ideas/86-push-notif-v2.md) | :seedling: Draft | :x: no | :x: no | :x: no | :x: no |
| [71-low-traffic](ideas/71-low-traffic.md) | :question: Limbo | :white_check_mark: Yes | :x: No | :x: No | :white_check_mark: Yes :question: | | [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 | - | | [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 | - | | [142-recovery-compatibility](ideas/142-recovery-compatibility) | :seedling: Draft | :white_check_mark: Yes | :white_check_mark: Yes | :x: No | - |
## Completed :champagne: and aborted :dagger: ## Completed :champagne: and aborted :dagger:
| Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? | | Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? |
|---------------------------------------------------------------------|---------------------------|------------------------|------------------------|------------------------|-----------------------------------| |---------------------------------------------------------------------|-----------------------|------------------------|------------------------|------------------------|--------------------|
| [64-release](ideas/64-release.md) | :dagger: Aborted | :white_check_mark: Yes | :x: No | :white_check_mark: Yes | - | | [76-smooth-ui](ideas/smooth-ui.md) | :dagger: aborted | :white_check_mark: Yes | :x: No | :x: No | :white_check_mark: |
| [61-app-structure-refinement](ideas/61-app-structure-refinement.md) | :champagne: Completed | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | - | | [71-low-traffic](ideas/71-low-traffic.md) | :dagger: aborted | :white_check_mark: Yes | :x: No | :x: No | :white_check_mark: |
| [3-erc20-token-support](ideas/3-erc20-token-support.md) | :champagne: Completed | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | - | | [64-release](ideas/64-release.md) | :dagger: Aborted | :white_check_mark: Yes | :x: No | :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 | - | | [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 ## Commitment Registry

26
ideas/095-les-service-model/micropayment.md
View File

@ -70,6 +70,32 @@
- https://github.com/ethersphere/swarm/wiki/Swap - https://github.com/ethersphere/swarm/wiki/Swap
- https://github.com/ethersphere/swarm/wiki/Swap-demo-instructions - https://github.com/ethersphere/swarm/wiki/Swap-demo-instructions
#### Plasma [Cash]
##### Concept
- Child-chains with PoA for ERC20/ERC223-compliant tokens
- Needs the plasma chain block headers to be written to root chain
- Submit the plasma chain blocks to the root chain on its every block
- Any number of users in a plasma side chain
- The root chain is involved into transaction for creating a side-chain, adding funds (deposit) and withdraws
- Plasma: withdraw takes 7 days for confirmation
- Plasma Cash: withdraw without any confirmation
- Plasma Cash: the plasma chain + ERC721 unique identifiers for each token
- Plasma Cash: sharded client-side validation
- The implementation is going to be integrated to the Ethereum blockchain
- If a block producer starts acting maliciously, a user can leave the child-chain with his or her tokens. The user can publish a fraud proof to the root contract (valid previous and current states + invalid fraud state) and withdraw his or her tokens
- Invalid exits can be challenged by any user with the token's data
##### Links
- https://karl.tech/plasma-cash-simple-spec
- https://github.com/ethereum-plasma
- https://ethresear.ch/t/minimal-viable-plasma/426
- https://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ
- https://plasma.io
- https://github.com/BANKEX/PlasmaETHexchange
### API ### API
#### Client #### Client

118
ideas/123-whisper-visualization.md Normal file
View File

@ -0,0 +1,118 @@
## Preamble
Idea: 123
Title: Whisper Visualization
Status: Draft
Created: 2018-04-06
## Summary
WebGL 3D visualization platform for Whisper and peer-to-peer processes (message propagation, peers discovery, etc), both for educational and research purposes.
![demo1](https://i.imgur.com/MZElq0K.png)
*Note: current image doesn't represent real Status cluster (yet) and serves only for showcasing purposes.*
[Demo GIF](https://i.imgur.com/GAu4zte.gifv)
The core aspect of Status messaging layer is a peer-to-peer (p2p) network of Ethereum nodes and the Whisper messaging protocol. For developers it is crucial to understand how P2P overlay network and Whisper works and build intuition about it. However, P2P networks in general are among one of the most complicated topics to study.
The decentralized nature of those networks increase security and privacy (which is exactly the reason why they are built), but makes it incredibly hard to collect meaningful metrics, understand network topology, analyze its behaviour and create educational material. This results in a generaly poor understanding of P2P decentralized systems, and that's exactly the problem this project aims to attack.
Proposed visualization framework should provide a tooling for visualizing different types and scales of Ethereum network, processes that occur in network in different layers (p2p, les, whisper, etc), both collected from real data and from simulations.
## Swarm Participants
- Lead Contributor: [@divan](https://github.com/divan)
- Testing & Evaluation:
- Contributor:
- Contributor:
- PM:
- UX:
## Product Overview
![demo2](https://i.imgur.com/9IajeMC.png)
*Note: current image doesn't represent real Status cluster (yet) and serves only for showcasing purposes.*
Essentially the product is a software framework, that serves as a platform for building end-user products. One project in particular is suggested to be a showcase of the potential and a starting point for other projects – visualization of the Whisper message propagation in the Status cluster.
Other projects that can be implemented using this framework:
- real-time visual monitoring of Status cluster - visualizing nodes connectivity, CPU/memory/disk utilization, ingress/egress traffic, etc
- visualizing real Status app activity by collecting opt-in metrics from Status app
- researching the network heterogeneity and clusterization for Status nodes with different peers layer configurations
- educational visualizations of Whisper messaging, P2P network types and their properties
It's impossible to predict all possible ideas and needs, so the framework should provide easy to use building blocks, rather than try to be an all-in-one hyper-configurable solution.
Basically there are two important parts in any of the visualization projects:
##### User interface part (frontend)
The P2P network is essentially a directed graph, and the best known approach to represent those graphs is to use force-directed graph layout. It allows human brain to reuse our intuition built on top of physics and understand graph properties intuitively. The algorithm is basically to put peers (nodes) into 3D space, assign some weight (mass) to them and apply two physical forces: *repelling force* between nodes and *spring force* between linked nodes. The forces than applied repeatedly till the system stabilze i.e. reach the minimum energy threshold.
- WebGL 3D representation of p2p network and processes
- UI for user interaction: controls, import/export data, restarting or stepping through simulation, etc
##### Data collection part
Data collectors can be implemented separately once the common data exchange format is determined. Currently JSON format is used. Data can be collected or generated in many different ways:
- metrics from the controlled cluster and e2e tests
- metrics gathered from the Ethereum crawlers bots
- message propagation simulations from P2P network simulators
- empirical data based on state of the art estimation techniques (for example, BMS system described in https://arxiv.org/pdf/1801.03998.pdf)
---
User interface part needs to be implemented in the browser, because we want to reach as many people as possible, and thus have to use web. Fortunately, most browsers got decent support of WebGL technology and even have native GPU rendering capabilities. Currently the fantastic library [Three.js](https://threejs.org) is used – it has smooth learning curve, hides all shaders magic, provides nice API and great documentation.
The downside of implementing this part for web is, of course, inherit limitation of web browsers in terms of supported languages – they support 0 programming languages plus Javascript. WebAssembly is not a thing yet, but we still have to implement some important calculations for this part, like physical model for the force-directed graph layout and Barne-Hut optimizations, so the suggested approach is to offload most of heavy calculation to the backend server running on the same machine, that communicates with frontend via websockets. This approach proved to be fast enough in terms of responsiveness for the set of tasks needed for this part, and allows to implement pretty complicated concurrent calculations that run natively on the user machine, and not in the browser.
##### Data processing part (backend)
Currently most of the code involved into data processing is written as separate web servers that talks to the frontend via websockets. Important parts are:
- force-oriented graph physical model
- common data format import/export code
- use-case specific data processing and optimization for frontend
- websocket server
As we're talking about set of tools and libraries, all data collectors and generators could be implemented as a part of backend as well, adding to the interactivity of the final product. For example, user interface can allow changing different options for the simulations or data collectors and rerun them directly from the browser.
## Product Details
#### Help needed
The core part of this project is already written and will be opened this week. There three major focus points where brains and skills are needed:
- Frontend developers: frontend part still have to be written in Javascript, so JS-ninjas are very welcome. My goal is to package current [Vanilla.js](http://vanilla-js.com) code into something easy to work with and refactor in the future - React for example (suggestions are welcomed).
- UI/UX/VR designers: as this project involves user interactivity why not make it bloody awesome? This is virtual 3D space and we can do whatever we want – change colors, shapes, invent better way of visualization of complex systems, put this into VR space, anything. Maybe you have ideas for #ArtProject and want to make physical model out of the visualization. Let's talk.
- Researchers: mainly Go developers who involved into P2P-layer, nodes discovery and Whisper protocol improvements and research. Most of the simulations can be done without visualization, but having visual model helps enormously to develop intution and stir research tools into the right direction.
- WebGL/shaders ninjas: if you, by any chance, have an experience with [GLSL](https://en.wikipedia.org/wiki/OpenGL_Shading_Language) (OpenGL Shading Language), you're are very welcomed. Larger graphs and cooler animations will require bringing more shaders programming magic, and I will really need help here.
#### Performance considerations
It's important to realize that in WebGL world performance is an important player when it comes to the tradeoffs. Graphs with 10, 100, 1000 and 1000000 nodes require drastically different approaches. Static nodes vs dynamic nodes rendering should be implemented in a totally different way, so for each particular project, this should be taken into account.
Whisper message propagation project should work relatively fast with a graphs ~1K nodes. For higher numbers more optimizations have to be made.
### Requirements & Dependencies
This idea may be related to the [92 - Research Ethereum Discovery V5 Protocol](https://github.com/status-im/ideas/blob/master/ideas/92-disc-v5-research.md) idea.
### Minimum Viable Product
Goal Date: 06-05-2018
Description: The Whisper propagation visualization tool is implemented and documented. It should use either simulated propagation data or real data from controlled cluster. Minimal needed set of interactivity and controls is implemented (ability to choose node initiating the message sending, start multiple message sendings, etc). Code (libraries and tools) is documented and prepared to be open-sourced and used by third-party contributors.
## Dates
Goal Date: 06-06-2018
Description: First visualization project from another teams (i.e. Marketing, Community etc) or external contributors are implemented. That may be creating educational material on messaging in Whisper, researching libp2p code behaviour, visualizing Mailboxes, etc.
## Success Metrics
1. There is at least three useful projects that use this framework for different goals (i.e. research, monitoring, education).
2. Once open-sourced, number of "Awesome" comments should be at least 10 per week.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

3
ideas/146-status-go-sdk/1to1Channels.md
View File

@ -16,6 +16,9 @@ Basically the only difference between 1to1 and public is the field message type
### Ability to send 1 to 1 conversation ### Ability to send 1 to 1 conversation
### Ability to subscribe to 1 to 1 conversation ### Ability to subscribe to 1 to 1 conversation
### Ability to unsubscribe from a 1 to 1 conversation ### Ability to unsubscribe from a 1 to 1 conversation
### Documented API for 1 to 1 conversations ### Documented API for 1 to 1 conversations

7
ideas/146-status-go-sdk/ContactManagement.md
View File

@ -11,23 +11,26 @@ if account, err := conn.Invite("my_friend_public_key"); err != nil {
Before starting to chat with someone privately you should have its contact details. In order to do that, the next process should happen Before starting to chat with someone privately you should have its contact details. In order to do that, the next process should happen
##### Generate a new symkey (shh_newSymKey): ##### Generate a new symkey (shh_newSymKey):
Generates a new symetric key
``` ```
{"jsonrpc":"2.0","id":872,"method":"shh_newSymKey","params":[]} {"jsonrpc":"2.0","id":872,"method":"shh_newSymKey","params":[]}
``` ```
##### GetSymKey (shh_getSymKey): ##### GetSymKey (shh_getSymKey):
**[ TODO Describe what's this call doing...]** Polls any message for the symetric key
``` ```
{"jsonrpc":"2.0","id":873,"method":"shh_getSymKey","params":["14829092e1b30cb9ab643ef9aa3c37e5a576e69821259cc690f8cccedd08dc94"]} {"jsonrpc":"2.0","id":873,"method":"shh_getSymKey","params":["14829092e1b30cb9ab643ef9aa3c37e5a576e69821259cc690f8cccedd08dc94"]}
``` ```
** [ TBD : How do i calculate what's on params? ] **
##### Create filter for new topic (shh_newMessageFilter): ##### Create filter for new topic (shh_newMessageFilter):
``` ```
{"jsonrpc":"2.0","id":879,"method":"shh_newMessageFilter","params":[{"topics":["0x6c0b63af"],"symKeyID":"14829092e1b30cb9ab643ef9aa3c37e5a576e69821259cc690f8cccedd08dc94","allowP2P":true}]} {"jsonrpc":"2.0","id":879,"method":"shh_newMessageFilter","params":[{"topics":["0x6c0b63af"],"symKeyID":"14829092e1b30cb9ab643ef9aa3c37e5a576e69821259cc690f8cccedd08dc94","allowP2P":true}]}
``` ```
Main difference here with public channels is how the topic is calculated **[TODO DEFINE HOW'S CALUCULATED]** Main difference here with public channels is how the topic is calculated
**[ TODO DEFINE HOW TOPIC IS CALCULATED ]**
##### Send first message with my contact information (shh_post) ##### Send first message with my contact information (shh_post)

4
ideas/146-status-go-sdk/PrivateChannels.md
View File

@ -12,8 +12,8 @@ Interacting with private channels is complex than public channels as
### Ability to unsubscribe from a private groups ### Ability to unsubscribe from a private groups
**[ TBD ]** **[ TBD ]**
### Documented API for private groups interaction. ### Documented API for private groups
**[ TBD ]** **[ TBD ]**
### Working examples for private groups interaction. ### Working examples for private groups interaction
**[ TBD ]** **[ TBD ]**

4
ideas/146-status-go-sdk/PublicChannels.md
View File

@ -40,11 +40,11 @@ ch.Subscribe(func(m *sdk.Msg) {
``` ```
### Documented API for public channels interaction. ### Documented API for public channels interaction
This document can be adapted as a documentation for public channels interaction This document can be adapted as a documentation for public channels interaction
### Working examples for public channel interaction. ### Working examples for public channel interaction
Actually [here](https://github.com/status-im/status-go/blob/sdk/sdk/examples/) you'll find an example of a "ping pong game". Actually [here](https://github.com/status-im/status-go/blob/sdk/sdk/examples/) you'll find an example of a "ping pong game".

54
ideas/146-status-go-sdk/README.md
View File

@ -106,42 +106,44 @@ Testing Days required: TBD
## Success Metrics ## Success Metrics
#### Milestone 1: [Status messaging basic interaction](BasicSDK.md) #### Milestone 1: [Status messaging basic interaction](BasicSDK.md)
- [ ] Setup a new connection - [ ] [Setup a new connection](BasicSDK.md#setup-a-new-connection)
- [ ] Ability to close a specific connection - [ ] [Ability to close a specific connection](BasicSDK.md#ability-to-close-a-specific-connection)
- [ ] Ability to change connection configuration - [ ] [Ability to change connection configuration](BasicSDK.md#ability-to-change-connection-configuration)
- [ ] Ability to sign up on the platform - [ ] [Ability to sign up on the platform](BasicSDK.md#ability-to-sign-up-on-the-platform)
- [ ] Ability to login as a specific account - [ ] [Ability to login as a specific account](BasicSDK.md#ability-to-login-as-a-specific-account)
- [ ] Documented API for basic sdk interaction - [ ] [Documented API for basic sdk interaction](BasicSDK.md#documented-api-for-basic-sdk-interaction)
### Milestone 2: [Contact management](ContactManagement.md) #### Milestone 2: [Public channels interaction](PublicChannels.md)
- [ ] Invite new contact - [ ] [Ability to join public channels](PublicChannels.md#ability-to-join-public-channels)
- [ ] Accept new contact - [ ] [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)
- [ ] [Ability to unsubscribe from a public channel](PublicChannels.md#ability-to-unsubscribe-from-a-public-channel)
- [ ] [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)
- [ ] [Invite new contact](ContactManagement.md#invite-new-contact)
- [ ] [Accept a contact request](ContactManagement.md#accept-contact-request)
#### Milestone 3: [Public channels interaction](PublicChannels.md)
- [ ] Ability to join public channels
- [ ] Ability to publish messages on public channels
- [ ] Ability to subscribe to public channels
- [ ] Ability to unsubscribe from a public channel
- [ ] Documented API for public channels interaction.
- [ ] Working examples for public channel interaction.
#### Milestone 4: [1 to 1 messages interaction](1to1Channels.md) #### Milestone 4: [1 to 1 messages interaction](1to1Channels.md)
- [ ] Ability to send 1 to 1 conversation - [ ] TBD : [Ability to send 1 to 1 conversation](1to1Channels.md#ability-to-send-1-to-1-conversation)
- [ ] Ability to subscribe to 1 to 1 conversation - [ ] TBD : [Ability to subscribe to 1 to 1 conversation](1to1Channels.md#ability-to-subscribe-1-to-1-conversation)
- [ ] Ability to unsubscribe from a 1 to 1 conversation - [ ] TBD : [Ability to unsubscribe from a 1 to 1 conversation](1to1Channels.md#ability-to-unsubscribe-1-to-1-conversation)
- [ ] Documented API for 1 to 1 conversations - [ ] TBD : [Documented API for 1 to 1 conversation](1to1Channels.md#documented-api-for-1-to-1-conversations)
- [ ] Working examples 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)
- [ ] Ability to publish messages on private groups - [ ] TBD : [Ability to publish messages on private groups](PrivateChannels.md#ability-to-publish-messages-on-private-groups)
- [ ] Ability to subscribe to private groups - [ ] TBD : [Ability to subscribe to private groups](PrivateChannels.md#ability-to-subscribe-to-private-groups)
- [ ] Ability to unsubscribe from a private groups - [ ] TBD : [Ability to unsubscribe from a private groups](PrivateChannels.md#ability-to-unsubscribe-to-private-groups)
- [ ] Documented API for private groups interaction. - [ ] TBD : [Documented API for private groups interaction](PrivateChannels.md#documented-api-for-private-groups)
- [ ] Working examples for private groups interaction. - [ ] TBD : [Working examples for private groups interaction](PrivateChannels.md#working-examples-for-private-groups-interaction)
#### Milestone 6: Extra methods #### Milestone 6: Extra methods
- [ ] Ability to recover your account - [ ] Ability to recover your account
- [ ] Ability to log out. - [ ] Ability to log out.
- [ ] ...
## Exit criteria: ## Exit criteria:

97
ideas/150-gas-abstraction.md Normal file
View File

@ -0,0 +1,97 @@
# Gas Abstraction
## Preamble
Idea: 150-gas-abstraction
Title: Gas Abstraction
Status: Draft
Created: 2018-02-01
Requires: 145-identity
Replaces: 073-economic-abstraction
## Summary
Enable Status users to pay gas fee with any token that is valueable to society.
Users would sign a message request to contracts which will use user's Identity balance of selected token to refund proportional used gas to a incentivezed ETH owner to include that message in a transction.
## Swarm Participants
- Lead Contributor: Ricardo Guilherme Schmidt
- Contributor: Richard Ramos
- Contributor: Iuri Matias
- UX (Mist): Alexandre Van de Sande
- UX (Status): (help needed)
## Product Overview
A barrier for user adoption to blockchain through Status would be the need of holding two tokens for paying fees, ether gas for moving the [SNT](https://etherscan.io/address/0x744d70fdbe2ba4cf95131626614a1763df805b9e#readContract) fee from user balance to decentralized service provider.
The product solve this by emulating a gas abstraction by adding "Gas Relayer Actor" in top of smart contracts as: [Identity](https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/identity/Identity.sol)[GasRelay](https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/identity/IdentityGasRelay.sol), MultiSigWallet, [SNTController](https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/status/SNTController.sol#L82) (updated from SNTPlaceHolder).
- Allows SNT holder to broadcast ethereum signed messages to anyone with ETH to validate them in the GasRelay smart contracts, and offering a refund of gas used in a gas price set in SNT.
- Whoever have ether could verify if the gas price worth the SNT gas price offered.
- This becomes a micro trade of ETH->SNT.
- Allow user to use any token they want (even ETH, or ETH stored in Identity).
### Product Description
Gas Relay node:
- Status Destkop extension or an independent node can include messages by making automatic transactions calls to smart contracts to earn tokens being offered as gas price refund.
- Configuration for tokens accepted and types of contract willing to interact with.
Important as fundamental pivot actor.
Identity Gas Relay adaptor:
- include smart contract terms for accepting ethereum signed messages representing authorization to call by/for Identity owner offering a gas price refund for relayer.
- Identity UI should allow user to choose what token it wants to use as gas price.
Important for gas abstraction of call.
SNTController Gas Relay adaptor:
- include smart contract terms for accepting ethereum signed messages to call `IdentityGasRelayFactory` and for moving the tokens from there using SNT controller contract.
- a "wizard" UI would make the calls to create a Identity and send user SNT to Identity (so it can be used as ether gas).
Important for opt-in gas abstraction without ever holding ether.
### Requirements & Dependancies
Idea [145-identity](https://github.com/status-im/ideas/pull/145) is important to seamless and safe integration of gas abstraction for any type of call, so identity can become `msg.sender` for other contracts.
### Minimum Viable Product
Goal Date: 2018-05-15
Description:
- Users can use Identity paying gasPrice in any token.
- Users can create Identity using SNTController and paying with SNT.
- Users can earn tokens running a node that include other's messages
#### Identity Gas RelayIdentity UX should allow user to choose what token it wants to use as gas price.
Goal Date: 2018-04-20
Description:
- Gas Relay Node that recieve whisper messages from Identity owners,
- Identity User Interface with Gas Relayed option of calls
#### SNT Gas Relayer
Goal Date: 2018-04-27
Description:
- Gas Relay Node implements watching messages for SNTController
- User interface for creating Identity (pay gas in SNT)
- Moving SNT to other address from SNTController terms (paying gas in SNT)
#### UX Integration
Goal Date: 2018-05-15
Description:
- User can create Identity paying in SNT.
- User can select differnt tokens in gasPrice when using Identity.
## Success Metrics
Users are able to use Ethereum Virtual Machine and Status Network with only ever holding SNT.
## Supporting Role Communication
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

68
ideas/151-ens-usernames.md Normal file
View File

@ -0,0 +1,68 @@
# Username ENS subdomain Registrar
## Preamble
Idea: 151-ens-usernames
Title: Username ENS subdomain Registrar
Status: Draft
Created: 2017-11-20
Replaces: 027-ens-usernames
## Summary
Eliminates the need to copy/scan - and worse, type - long hexadecimal addresses / public keys, by providing an [ENS](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md) subdomain registry and recognition of ENS names in Status for interacting with other people in Status.
## Swarm Participants
- Lead Contributor: Ricardo Guilherme Schmidt
- Contributor: Richard Ramos
- UX (Mist): Alexandre Van de Sande
- UX (Status): Hester Bruikman
- Design: Denis Sharypin
- PM: Rachel Hamlin
## Product Overview
A bad experience in most cryptosystems, aswell Status, is the requirement of typing or scanning the public keys and addresses to interact with other users in the network.
ENS disrupt centralized DNS: like DNS resolves into IPs, ENS resolve into ethereum addresses (and more) trustlessly.
Status would introduce a option for users registering a human readable contact username and its URI would be used in place of QR codes / private keys.
A small fee is required, so users are buying the subdomain, and therefore could be exchanged with other users, this network effect is ignored by this idea.
### Product Description
Users would be able to:
- buy a subdomain from one of the ENS domains owned by Status.
- find users by using the configured ENS Resolver for EMS address (subdomain.domain.eth)
- search/suggest domain for a username.
- send funds by typing their ENS address.
Subdomain owners would be able to:
- change the owner of the subdomain
- change the resolver of the subdomain
Democracy (or authority) would be able to:
- add new domains available with its own price
- change domains price
- change owner of domain (required for update of subdomian registry)
### Minimum Viable Product
Goal Date: 2018-05-10
Description:
- Users can register (FIFS) an available username in Status's ENS subdomain
- Users can add friends by entering an ENS address
- Basic UI for call include a domain
## Success Metrics
Most users opt-in to register their username and use username subdomain to find their friends.
## Exit Criteria
Running on Mainnet
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

81
ideas/163-support-erc721.md Normal file
View File

@ -0,0 +1,81 @@
## Preamble
Idea: 163
Title: Support ERC721 tokens
Status: Draft
Created: 2018-04-10
## Summary
Add ERC721 support to Status wallet so that users can see their CryptoKitties, Punks, Celebrities, etc. alongside their other assets.
## Swarm Participants
- Lead/PM: [@rachelhamlin](https://github.com/rachelhamlin)
- Testing & Evaluation:
- Contributor: [@jeluard](https://github.com/jeluard)
- Contributor: [@goranjovic](https://github.com/goranjovic)
- UX: [@denis-sharypin](https://github.com/denis-sharypin)
## Product Overview
ERC721 tokens, or non-fungible tokens (NFTs), represent unique assets on the blockchain. The ability to use rare digial assets as a store of value has spawned a large market of digital collectibles.
With 100+ digital collectibles on the market and a combined sales volume greater than $50MM, it's important that we allow users to access their NFT collections inside Status right alongside their ETH and ERC20 tokens.
The two primary cases we need to support are:
1. Having my existing collectibles in my Status wallet
2. Buying or receiving new collectibles and seeing them in my Status wallet
Additional use cases may focus on gifting collectibles from one user to another, or sending collectibles in a chat.
### Product Description
##### For already owned crypto assets
Users should be able to view their collection of NFTs in a dedicated section of their Status wallet.
Tokens associated with a user's Mainnet address should appear there automatically.
Any ERC721 token should be supported, and individual assets within a collection should display available metadata such as name or number, properties, creation date, etc. To whatever extent possible, we can standardize the metadata displayed for each type of collectible and provide a link to the DApp for more.
##### For newly purchased crypto assets
When a user buys a new collectible through some other browser, it should automatically appear in their Status wallet. Same goes for collectibles that can be gifted, as is the case with Cryptokitties; Status should recognize when a user receives a new collectible as a gift.
A user should also be able to purchase collectibles from the Status browser, and the collectible should appear in their wallet.
Initially we can use marketplaces to support this by consuming metadata from [Opensea.io](https://opensea.io/) or [Rarebits.io](https://rarebits.io/), but users should also be able to purchase new collectibles inside each DApp.
### Requirements & Dependencies
Potential dependency on Status extensions (formerly #101)
### Minimum Viable Product
Goal Date:
Description:
As there is no way to automatically browse all the existing collectible types, we'll focus on individual support for any collectible DApps that Status currently features.
- UX/UI for collectibles in wallet:
- Browse collections (categories/types)
- Browse collectibles
- View individual collectible
- Add wallet support for any ERC721 featured in Status Selected DApps:
- CryptoFighters
- CryptoKitties
- CryptoPunks
### Iteration 1
- Expand collectible support
- Add profile showcase for users to display their collections
- Purchase new collectibles via a marketplace
### Exit Criteria
TK
### Success Metrics
TK
## Supporting Role Communication
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

4
ideas/71-low-traffic.md
View File

@ -1,7 +1,7 @@
## Preamble ## Preamble
Idea: <to be assigned> Idea: 71-low-traffic
Title: Low traffic consumption(technical) Title: Low traffic consumption(technical)
Status: Limbo Status: Aborted
Created: 2018-01-25 Created: 2018-01-25
## Summary ## Summary

2
ideas/76-smooth-ui.md
View File

@ -5,7 +5,7 @@
Idea: 76-smooth-ui Idea: 76-smooth-ui
Title: Make UI fast and smooth Title: Make UI fast and smooth
Status: Limbo Status: Aborted
Created: 2018-01-24 Created: 2018-01-24
Requires (*optional): 87-new-protocol Requires (*optional): 87-new-protocol