[WIP] feat: add option to select record

[vasco-santos]

When we intend to use arbitrary keys with no namespaces, we end up not being able to get them js-libp2p-recordselection.js#L20. However, there are use cases where we want to be able to select a specific record or provide a function to select it.

In this PR, I added an option to select the first record obtained.

[vasco-santos]

@jacobheun

I added an option to select the first one. However, I am not sure if this is the best option for us. Maybe I should provide a function instead. What do you think?

[blakebyrnes]

I've thought before that it would be nice to be able to return the actual record you want to re-propagate instead of an index. Use case is where you might want to merge records that different nodes have into a new entry.

[vasco-santos]

@blakebyrnes as this is in the get, I think I did not understand your suggestion. What is the actual record that you want to re-propagate?

[blakebyrnes]

@vasco-santos lets say you have every node in a system storing top 10 lists. When all N records come back, the "get" will compare each record to say "what is the best record" to send out as a corrected record. In cases like this type of data storage, you might actually want to merge the lists to create a new, aggregated top 10 list. It's a bit of a different use case than the bittorrent use case, but it seems like the Kad is still a valid data structure for those cases. It's just using "keys" as a convention for the content instead of as the hash of the content.

[vasco-santos]

@vasco-santos lets say you have every node in a system storing top 10 lists. When all N records come back, the "get" will compare each record to say "what is the best record" to send out as a corrected record.

Correct

In cases like this type of data storage, you might actually want to merge the lists to create a new, aggregated top 10 list. It's a bit of a different use case than the bittorrent use case, but it seems like the Kad is still a valid data structure for those cases. It's just using "keys" as a convention for the content instead of as the hash of the content.

So, kad-dht should receive a function that selects the record to send out as a correct. But, instead of returning the index, it would return a record. This way, if the function receives a set of records, it can return one of them, or even generate a new one based on the received ones. Is that what you suggest?

[blakebyrnes]

Yep, that's exactly what I was thinking.

[vasco-santos]

I understand its advantages, but I don't know if I agree with that approach, as we will provide an easy way of rewriting DHT entries. Anyway, you can create a PR with your proposal, so that we can have a more clear discussion of it.