search

waku-org / research

Waku Protocol Research
MIT License
3 stars 0 forks source link

Negotiate time frames before request #37

Open s-tikhomirov opened 8 months ago

s-tikhomirov commented 8 months ago

Currently, if a node signals that it suns Store (as a server), it is assumed that it can respond to any client request. This assumes that each Store node stores all past messages forever, which may not be sustainable. Explore the following idea:

Two sub-ideas on how time frame negotiations can happen:

  1. servers announce them proactively in the P2P network;
  2. a client asks a particular server before sending the actual request.
alrevuelta commented 8 months ago

Indeed. Related to capability discovery. Ideally we should use 1) since its more efficient than 2). In other words, having this capability announcement as part of discovery, allows peers to search for the capability they are interested in a more efficient way. 2. would require going node by node, setting up a connection to query the capabilities, which is very inneficient.

s-tikhomirov commented 8 months ago

we should use 1) since its more efficient

On the other hand, 1) distributes the burden to the whole network, while in 2) only the two involved nodes care about this negotiation. I'm thinking about edge cases, for example, when the description of which time frames a node covers is in itself heavy. A malicious operator could set up its node such that it covers lots of small irregular intervals, and everyone would have to sync this across the DHT or whatever peer discovery mechanism. This is likely a secondary concern though.

alrevuelta commented 8 months ago

A malicious operator could set up its node such that it covers lots of small irregular intervals, and everyone would have to sync this across the DHT or whatever peer discovery mechanism

yep, we should limit this to a fixed (or max) length field. The simpler the better. I dont think it would be necesary to allow for weird configurations. Just "this node stores the last x days" in shard y", where x and y are parameters advertised as capabilities in the discovery layer.