RFC: Capabilities advertising

[oskarth]

Discussed in #374

^{Originally posted by oskarth April 21, 2021}

Problem

Just knowing a peer is using STORE doesn't tell you much about what they are storing, if anything.

Proposed solution

An alternative and perhaps a more efficient solution we may want to consider an approach where nodes periodically advertise their capabilities over a designated pubsub topic . This way, a requestor node connects to another node with the knowledge that the queried node is capable of responding to that request. Moreover, the advertised capability messages can also be persisted in the store db.

(We can also complement this with an aggregator/view/log compact function, so you can ask for latest state of capabilities for each node. Basically for node A B C announcing capabilities Acap0 Bcap0 Acap1 Cap0 Bcap1 Acap2 on pubsub topic "capabilities", then a new node can send protobuf message getNodesWithCapabilties() => {A: Acap2, B: Bcap1, C: Cap0} or similar.)

What do people think of this?

Details

From previous issue

There are a few different dimensions of information that are desirable:

• Are they persisting messages at all? For which topics? (e.g. default pubsub topic to start with)
• For how long are they store? (7d retention policy e.g.)
• For how long have they been online (e.g. online window in epochs, assuming honest => extend with checks)

This informs a peer with enough data to know if:

• they should ask some other peer
• they should ask more than one peer

Acceptance criteria

• Raw spec

Notes

Adaptive node discussion context: #87

cc @staheri14 @jm-clius @D4nte

[jimstir]

Issue moved here