mirror of https://github.com/status-im/swarms.git
Add Discoverable And Trusted Server Nodes swarm (#280)
This commit is contained in:
Adam Babik
GitHub
parent
fa4ee7e7ac
commit
a16c8c2e48
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
id: 280-discoverable-trusted-server-nodes
|
||||
title: Discoverable And Trusted Server Nodes
|
||||
status: Draft
|
||||
created: 2018-06-07
|
||||
category: core
|
||||
lead-contributor: adambabik
|
||||
contributors:
|
||||
- richard-ramos (Smart Contract Developer)
|
||||
exit-criteria: yes
|
||||
success-metrics: yes
|
||||
clear-roles: no
|
||||
future-iterations: yes
|
||||
roles-needed:
|
||||
- Go Developer
|
||||
- Clojure Developer
|
||||
okrs:
|
||||
- "[PO]: Objective: Messaging is reliable"
|
||||
- "[P2]: KR: Cluster can handle 500 concurrent users"
|
||||
---
|
||||
|
||||
## Summary
|
||||
The idea here is to provide a way to make Mail Server nodes discoverable and trusted. This should work seamlessly for the end user.
|
||||
|
||||
## Product Overview
|
||||
Currently, Mail Servers (and other planned server nodes like Push Notification servers) need to be hardcoded in the app code. It's possible to provide your own Mail Server in the app settings but that's not a scalable solution and it does not solve all issues.
|
||||
|
||||
The outcome of this swarm are decentralized and discoverable Mail Servers which will initially be managed and trusted by Status. The client will still accept user's custom Mail Servers.
|
||||
|
||||
In the next iterations, we may work on a solution to allow external providers to submit their own Mail Servers into the cluster and allow end users to accept these resources as trusted. The list of providers and their resource could be managed by [Token-Curated Registries](https://docs.google.com/document/d/1BWWC__-Kmso9b7yCI_R7ysoGFIT9D_sfjH3axQsmB6E), for instance.
|
||||
|
||||
## Product Description
|
||||
The work in this swarm can be divided into three areas:
|
||||
- (Infra) making Mail servers discoverable,
|
||||
- (Smart Contract) writing a smart contract to keep track of trusted Mail Servers,
|
||||
- (Client) mechanism of verifying whether a discovered Mail Server is trusted.
|
||||
|
||||
The smart contract should implement the complete interface that will allow managing providers and their resources. The client will have an option to decide which providers it trusts. Status will be a default provider and by default the app will trust it.
|
||||
|
||||
Due to the fact that all Mail Servers are supposed to be equal and independent (in other words, they should store the same messages, possibly in different order though), we will be able to remove all hardcoded Mail Server addresses from the client and rely only on discovered Mail Servers. This will allow Status to dynamically scale number of resources depending on the usage.
|
||||
|
||||
**Note** Important thing is that this solution should be flexible for other server nodes. It should be easy to introduce new resources, as long as a particular group of servers is discoverable, the client verifies them using a smart contract and can choose arbitrary one to continue.
|
||||
|
||||
## Requirements & Dependancies
|
||||
1. (Optional) Before this swarm starts, https://github.com/status-im/status-go/issues/1006 should be resolved in order to avoid working on the same piece of code.
|
||||
|
||||
## Minimum Viable Product
|
||||
|
||||
Goal Date: TBD
|
||||
|
||||
1. [ ] A smart contract that keeps track of providers and Mail Servers,
|
||||
1. [ ] Discoverable Mail Servers,
|
||||
1. [ ] Requests for messages are securely encrypted to provide confidentiality,
|
||||
* As devp2p packets are encrypted and this is P2P communication, the question is should we additionally encrypt Whisper messages with a Mail Server's public key?
|
||||
1. [ ] A client that collects discovered Mail Servers and verifies if they are trusted using the smart contract. Verified Mail Servers are added to the pool and a random one is selected to use.
|
||||
* We keep the option to add user's own Mail Server addresses.
|
||||
1. [ ] Make sure this solution is flexible and can work with other server nodes.
|
||||
|
||||
## Iteration 1 (Optional, TBD)
|
||||
|
||||
Goal Date: TBD
|
||||
|
||||
1. [ ] Allow custom providers to register their Mail Servers (Status as a curator?),
|
||||
1. [ ] Allow users of the app to select trusted providers
|
||||
* [ ] A new design of a screen needed.
|
||||
|
||||
## Success and exit criteria
|
||||
|
||||
1. Mail Servers are not hardcoded in the client but are discovered using Discovery V5 protocol and verified using a smart contract,
|
||||
1. (Optional) External Mail Server providers can register themselves and users can decide if they trust their resources (a list of providers is curated by Status).
|
||||
|
||||
## Copyright
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
Discoverable And Trusted Server Nodes
|
||||
=====================================
|
||||
|
||||
## Proposed Workflow
|
||||
|
||||
1. Mail Server registers itself with a topic `mailserver` in Discovery V5 pool,
|
||||
1. A client subscribes to Discovery V5 for peers registered with `mailserver` topic,
|
||||
1. A client verifies that a found Mail Server is trusted using a smart contract,
|
||||
1.1. If so, the selected Mail Server is cached and used to retrieve historic messages,
|
||||
1.2. Otherwise, it's discarded and the client waits for new candidates.
|
||||
|
||||
### What does happen when a previously trusted Mail Server is not trusted anymore?
|
||||
|
||||
(when a previously trusted Mail Server got removed from the smart contract registry)
|
||||
|
||||
We can use smart contract events to observe that in order not to check if a given Mail Server is trusted whenever the historic messages are requested ([discussion](https://github.com/status-im/ideas/pull/280/files?utf8=%E2%9C%93&diff=unified#r194015066)).
|
||||
|
||||
## Token-Curated Registries
|
||||
|
||||
[Detailed Specification](https://docs.google.com/document/d/1BWWC__-Kmso9b7yCI_R7ysoGFIT9D_sfjH3axQsmB6E)
|
||||
|
||||
This concept overlaps in many aspects with the smart contract that is needed to be designed for this swarm. TCRs can be used as a solution or inspiration to design the smart contract.
|
||||
|
||||
## Q&A
|
||||
|
||||
### Q: What consistency level do Mail Servers provide?
|
||||
|
||||
Each Mail Server is independent and stores its own log of historic messages. It means there is no sync between them and the consistency is not maintained or even verified. In particular:
|
||||
- stored messages might be in a different order on each Mail Server,
|
||||
- if a given Mail Server was down for longer than TTL of some messages, those messages could be lost on a given server.
|
||||
Loading…
Reference in New Issue