In the current state of the store protocol, node discovery is static and out of band / centralized. Waku nodes are configured with a static list of other store nodes whose addresses are known and available on a central server.
This approach seems fine in the presence of a central entity that knows and manages all the store nodes. For example, in the case of community history, the community owner may act as the central entity and sets up store nodes or manages nodes that volunteer to maintain the community history. This poses an extra load on the community owner as well as makes it a single point of failure.
Alternative decentralized discovery methods enable load distribution and make the system more robust, reliable, and fault-tolerant.
This issue is to investigate the need for a decentralized discovery for the community history problem. If a strong need is identified, then potential solutions shall be sketched and discusses.
Problem
In the current state of the store protocol, node discovery is static and out of band / centralized. Waku nodes are configured with a static list of other store nodes whose addresses are known and available on a central server.
This approach seems fine in the presence of a central entity that knows and manages all the store nodes. For example, in the case of community history, the community owner may act as the central entity and sets up store nodes or manages nodes that volunteer to maintain the community history. This poses an extra load on the community owner as well as makes it a single point of failure.
Alternative decentralized discovery methods enable load distribution and make the system more robust, reliable, and fault-tolerant. This issue is to investigate the need for a decentralized discovery for the community history problem. If a strong need is identified, then potential solutions shall be sketched and discusses.
Ongoing works
https://github.com/vacp2p/rfc/issues/429