-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Negotiate time frames before request #37
Comments
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. |
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. |
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 |
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:
The text was updated successfully, but these errors were encountered: