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

RFC: coreapi.Name,Key #4477

Merged
merged 7 commits into from
Jan 4, 2018
Merged

RFC: coreapi.Name,Key #4477

merged 7 commits into from
Jan 4, 2018

Conversation

magik6k
Copy link
Member

@magik6k magik6k commented Dec 10, 2017

TODO:

  • Review
  • Docs
  • Tests

Note that most of the implementation code comes form respective commands, if this get's merged, I'll rewrite them to use this API.

@magik6k magik6k added the topic/core-api Topic core-api label Dec 10, 2017
@magik6k magik6k requested a review from a user December 10, 2017 22:50
@ghost ghost assigned magik6k Dec 10, 2017
@ghost ghost added the status/in-progress In progress label Dec 10, 2017
@whyrusleeping
Copy link
Member

@magik6k since these are going to be user facing APIs, lets go ahead and make this all godoc compliant

api,
nil,
}
}
Copy link

Choose a reason for hiding this comment

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

Is this multiline format what gofmt emitted?

type IpnsEntry struct {
Name string
Value Path
}
Copy link

Choose a reason for hiding this comment

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

I wonder if we should make IpnsEntry an interface, in the spirit of future extensibility. Opinions on that?

Copy link
Contributor

Choose a reason for hiding this comment

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

On the topic of future extensibility, we should also consider adding TTL/expiry to the returned values.

// WithKey is an option for Publish which specifies the key to use for
// publishing. Default value is "self" which is the node's own PeerID.
//
// You can use .Key API to list and generate more names and their respective keys.
Copy link

Choose a reason for hiding this comment

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

You can use KeyAPI

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

This looks pretty good overall :) 🤖 Left a few comments and questions


// WithNoCache is an option for Resolve which specifies when set to true
// disables the use of local name cache. Default value is false
WithNoCache(nocache bool) options.NameResolveOption
Copy link

Choose a reason for hiding this comment

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

I have a hunch we shouldn't make this a negative, even if it's already a negative in the CLI/API -- opinions?

// Supported algorithms:
// * rsa
// * ed25519
WithAlgorithm(algorithm string) options.KeyGenerateOption
Copy link

Choose a reason for hiding this comment

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

Let's call this WithType(), following ipfs key generate --type=

We can have consts for the key types:

const (
    RSAKey = "rsa"
    Ed25519Key = "ed25519"
)

keyapi.Generate(ctx, "my-key", keyapi.WithType(coreopts.Ed25519Key))

WithForce(force bool) options.KeyRenameOption

// List lists keys stored in keystore
List(ctx context.Context) (map[string]string, error) //TODO: better key type?
Copy link

Choose a reason for hiding this comment

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

//TODO: better key type?

Let's make it a Key interface (for easier future extensibility)

type Key interface {
    Name() string
    Type() string // is the type exposed through the keystore?
    Path() Path // => /ipns/QmPeerID
}

Copy link

Choose a reason for hiding this comment

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

Also, any opinion on returning a map[string]Key or a []Key here?

type KeyAPI interface {
// Generate generates new key, stores it in the keystore under the specified
// name and returns a base58 encoded multihash of it's public key
Generate(ctx context.Context, name string, opts ...options.KeyGenerateOption) (string, error)
Copy link

Choose a reason for hiding this comment

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

Should we return Paths instead of PeerID strings?


func NamePublishOptions(opts ...NamePublishOption) (*NamePublishSettings, error) {
options := &NamePublishSettings{
ValidTime: 24 * time.Hour,
Copy link

Choose a reason for hiding this comment

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

Should have DefaultValidTime = 24 * time.Hour for this


func (api *KeyAPI) Rename(ctx context.Context, oldName string, newName string, opts ...caopts.KeyRenameOption) (string, bool, error) {
options, err := caopts.KeyRenameOptions(opts...)
if newName == "self" {
Copy link

Choose a reason for hiding this comment

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

This looks like it should be err != nil, typo?


if n.Identity == "" {
return nil, errors.New("identity not loaded")
}
Copy link

Choose a reason for hiding this comment

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

We don't use n.Identity, I think this check can be removed

settings.Key = key
return nil
}
}
Copy link

Choose a reason for hiding this comment

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

I noticed key can be both a key name and peerID (see keylookup()) -- cool! Let's make sure to document that :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@magik6k magik6k force-pushed the feat/coreapi/name branch 3 times, most recently from e280cd4 to b80a76e Compare December 20, 2017 12:15
@magik6k
Copy link
Member Author

magik6k commented Dec 22, 2017

Waiting for #4471 to be merged for test utils

@magik6k magik6k added the status/blocked Unable to be worked further until needs are met label Dec 22, 2017
Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

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

👍 looks really good to me

@magik6k magik6k removed the status/blocked Unable to be worked further until needs are met label Dec 31, 2017
@whyrusleeping
Copy link
Member

@magik6k merged the other PR, let me know when to look at this one again

License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
}

func TestBasicPublishResolveTimeout(t *testing.T) {
t.Skip("ValidTime doesn't appear to work at this time resolution")
Copy link
Member Author

Choose a reason for hiding this comment

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

@whyrusleeping, I noticed that ValidTime doesn't seem to work at this time scale. Is this by design (should I drop this test), or is there a better way to do this (or is it a bug)?

Copy link
Member

Choose a reason for hiding this comment

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

hrm... thats tricky. It should be okay at 100ms... I'm not sure this isnt a bug. How does it fail?

@magik6k
Copy link
Member Author

magik6k commented Jan 2, 2018

Added tests, fixed some bugs they caught, other than that one question and after test are reviewed this PR is RTM.


// WithSize is an option for Generate which specifies the size of the key to
// generated. Default is 0
WithSize(size int) options.KeyGenerateOption
Copy link
Member

Choose a reason for hiding this comment

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

It feels a bit weird having these options be part of the interface... cc @lgierth

Copy link

@ghost ghost Jan 2, 2018

Choose a reason for hiding this comment

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

The thinking was that in the future some of these option funcs might depend on state of the KeyAPI object. But actually in these cases we can just pass it in as an argument, e.g. keyapi.Generate(ctx, "mykey", coreopts.WithType(coreopts.Ed25519Key))

Drawback: the likelyhood of name collisions increases: there's more "type" options than just the one in key/generate. We can prefix these funcs, e.g. coreopts.WithKeyType, or we can make a conversion similar to the api.KeyAPI() conversions: opts := api.Options(); keyopts := opts.KeyOptions()

Copy link
Member

Choose a reason for hiding this comment

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

Oh, so all the options are in the same package?

Copy link
Member Author

@magik6k magik6k Jan 2, 2018

Choose a reason for hiding this comment

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

They are in one package, though are scoped per API, see https://github.com/ipfs/go-ipfs/pull/4477/files#diff-764a71d2f522b4136e7909befd573776R53 (or the tests).

For key API, type will always mean 'key type'. In the case where we create another function for which it would make sense to pass this option, it's possible to reuse that (with some more go types magic)

return nil, err
}

if pid.Pretty() == k {
Copy link
Member

Choose a reason for hiding this comment

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

when could this ever not be the case?

Copy link

Choose a reason for hiding this comment

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

We're iterating over all keys in the keystore and this is our return condition -- it's not a sanity assertion :)

Copy link
Member

Choose a reason for hiding this comment

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

Ah, i see now. Carry on

License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
@whyrusleeping whyrusleeping merged commit 3af7206 into master Jan 4, 2018
@whyrusleeping whyrusleeping deleted the feat/coreapi/name branch January 4, 2018 23:08
@ghost ghost removed the status/in-progress In progress label Jan 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/core-api Topic core-api
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants