Skip to content
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

Set record handlers for the default protocol prefix #560

Merged
merged 5 commits into from
Apr 6, 2020

Conversation

aschmahmann
Copy link
Contributor

The default protocol prefix /ipfs assumes the existence of the "pk" and "ipns" namespaces. These are now both constructed and added to the DHT if no Validators are specified and the protocol prefix is /ipfs.

The current behavior of having the "pk" namespace enabled by default is still there though.

@aschmahmann aschmahmann requested a review from Stebalien April 6, 2020 15:37
dht_options.go Outdated
Comment on lines 82 to 84
c.validator = record.NamespacedValidator{
"pk": record.PublicKeyValidator{},
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've had this in in the past, but I'm not quite sure why... does anyone even use this?

dht_options.go Outdated
// on other configuration parameters (e.g. optA is by default 2x optB) and/or on the Host
func (c *config) applyFallbacks(h host.Host) {
if c.validator == nil {
if c.protocolPrefix == DefaultPrefix {
Copy link
Contributor Author

@aschmahmann aschmahmann Apr 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it too weird to only have this default set for the /ipfs prefix instead of for everyone? This is the way that makes the least changes to any users of the library, but is also kind of unintuitive/unhelpful if someone wants to fork the /ipfs network.

dht_options.go Outdated
Comment on lines 194 to 195
// For the default protocol prefix it defaults to a namespaced validator that
// supports validating both public key and IPNS records
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the weird comment we sort of have to leave now if we stick with this approach https://github.com/libp2p/go-libp2p-kad-dht/pull/560/files#r404190615

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated things to make them a little simpler and more compliant, but now this comment isn't 100% accurate because the internals have more subtleties. Thoughts?

dht_options.go Outdated
Comment on lines 76 to 79
nsval, ok := c.validator.(record.NamespacedValidator)
if ok {
nsval["ipns"] = ipns.Validator{KeyBook: h.Peerstore()}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if this is quite what we want... it seems reasonably close though

…alidator defaults are modified in which case neither of them are added
…Validator has been changed, in which case neither of them are added. Simply adding additional NamespacedValidators does not remove the pk or ipns validators
dht_options.go Outdated
//
// Example: Given a validator registered as `NamespacedValidator("ipns",
// myValidator)`, all records with keys starting with `/ipns/` will be validated
// with `myValidator`.
func NamespacedValidator(ns string, v record.Validator) Option {
return func(c *config) error {
if !c.validatorChanged {
if ns == "pk" {
return fmt.Errorf("cannot override the pk namespace without first changing the Validator")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

… other validators, however they are of an invalid type then they will fail if using the default /ipfs protocol prefix
@Stebalien Stebalien merged commit 067f8ab into master Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants