Open staheri14 opened 2 years ago
@staheri14 @PascalPrecht can we link this issue with existing work in this area please? I know work continued in separate issues but there's no backlink to this so it is hard to follow trail.
@oskarth Sure!
So far the only additional "work" with regards to specification was done here in the feature specs repo for Status Deskop: https://github.com/status-im/feature-specs/pull/36
This is just a draft though with a high level overview and "expectations" from a desktop's user's perspective. It also cross-links all the existing issues @staheri14 has created related to this problem.
Implementation hasn't really started yet as we're still figuring out which MVP approach to settle on.
Problem
How to use the current capabilities of waku2 to address the community history issue.
Solution idea
In the following solution, we follow the modular approach introduced in https://github.com/vacp2p/research/issues/82 and describe how each module can be implemented and realized through the current capabilities of waku2.
Current Waku2 capabilities
Message ordering mechanism
Access control management/ Group management
State synchronization/consensus The current state synchronization of the Waku2 store protocol is empowered by the Waku FT-store protocol.
Discovery
Transport
Offline/ long-term storage
Resource Throttling Not supported
A minimal solution based on the current Waku2 capabilities
Below is how can we address community history leveraging the current capabilities of Waku2.
The community owner specifies a set of store nodes with their addresses and makes the addresses public for the community members to see.
At least one store node should be online for each given time window.
Store nodes are supposed to be trusted so that they don't hide any message and behave as instructed.
All the store nodes are participants of the transport layer i.e., Gossipsub.
The community owner runs the store nodes and configures them with the static list of store nodes. As the result, it creates a full graph between the store nodes.
Store nodes are supposed to have synchronized clocks with at most +-20 sec diffs.
Store nodes begin listening to and storing all the messages published in the network through the transport layer.
If a store node goes offline, once gets back online, it queries all the other store nodes for that offline time window. It then fixes its history gap.
Each store node can reliably provide message history to the community members.
Each store node can order messages based on their timestamp + hash. It provides total ordering.
Ongoing and future work
Message ordering mechanism: https://github.com/vacp2p/research/issues/76 Access control management/ Group management: https://github.com/vacp2p/research/issues/79 Store synchronization/Consensus: https://github.com/vacp2p/research/issues/80 Discovery: https://github.com/vacp2p/research/issues/81 Offline/long-term storage: https://github.com/vacp2p/research/issues/78 Resource throttling: https://github.com/vacp2p/research/issues/84 Edit/Remove messages: https://github.com/vacp2p/research/issues/77