libp2p
kad: Add `Key` to InboundRequest::{PutRecord, AddProvider}
Description
Add the record Key to InboundRequest::PutRecord and InboundRequest::AddProvider event so the node can know the Key of the record that it has received.
Motivation
Currently, it the behaviour informs the node that they received a record InboundRequest::{PutRecord, AddProvider} event, unless StoreInserts::FilterBoth is enabled via Config::set_record_filtering in which case the record is included in its respected event. However, if the node wishes to know the key of the record it has received, it would have to enable filtering, which would then need to be explicitly stored in RecordStore through its respected functions. This seems a bit redundant since the record key can be included in the event to be more informational to the node in understanding what record has been stored without needing to store the record manually.
Current Implementation
Does not provide the key in InboundRequest::{PutRecord, AddProvider}
Are you planning to do it yourself in a pull request?
Maybe
Sorry, I already gave a thumps-up on this, but reading through this again I was just wondering: what's the use-case for this? Unless a node wants to filter the records that is is storing, why does the key matter?
Sorry, I already gave a thumps-up on this, but reading through this again I was just wondering: what's the use-case for this? Unless a node wants to filter the records that is is storing, why does the key matter?
Mostly to provide information to the node without needing to enable filtering, but as I begin to look at the code more, I do wonder if it would matter if it is provided from libp2p-kad. On one hand, it would be good for information and would reduce the need for one having to explicitly insert the record if they just want to know the key of the record that was inserted, but on the other hand most would ever need access to the record key if they are performing checks against it to determine if the record would be accepted or rejected, thus kind of negating the need for the former.
For me, in a project I am working on, I dont need explicit access to the record (thus not needing to have filter enabled), but would like to report about a record that been provided from a peer on a channel which would allow one cache it for later use if its still in the record store and to do that would require the key of the record, which is only available if filtering is enable, but I guess I could perform a check to determine if filtering is disabled before initializing the behaviour and if so to enable it internally but provide the record key to the channel and instantly insert the record into the store and if the filtering is enabled to provide the record to the same channel with a oneshot to confirm if the record should be stored or not.