Skip to content
This repository has been archived by the owner on Dec 9, 2019. It is now read-only.

Should we change the terminology around "default signature provider"? #67

Open
bhazzard opened this issue Sep 25, 2018 · 4 comments
Open

Comments

@bhazzard
Copy link

"Default" suggests to me that it should be my first choice. Really though, we don't want developers to use the default signature provider, we want them to choose one provided by a secure service.

Should we change the terminology to something else that suggests it shouldn't be used in production. Some things like:

  • development signature provider
  • dev-mode signature provider
  • test signature provider
  • in-memory signature provider
  • open to other ideas

If we did this, it would probably require a minor change to the code itself, and to the README.

@chris-allnutt
Copy link

I like the idea of development signature provider. We should consider the non hardware based sig providers insecure by default.

@tbfleming
Copy link

I didn't think we used the term "default" to refer to that signature provider, so I checked. It looks like we don't. Maybe you're referring to eosjs2_jssig's default export?

@tbfleming
Copy link

defaultPrivateKey should probably be renamed. There's nothing default about it...

@bhazzard
Copy link
Author

I didn't think we used the term "default" to refer to that signature provider, so I checked. It looks like we don't. Maybe you're referring to eosjs2_jssig's default export?

Yes, this. But also, for whatever reason we use the terminology "default signature provider" when talking about this, so something about the code has prompted this lexical behavior.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants