search

ssbc / ssb-keys

keyfile operations for ssb
36 stars 26 forks source link

Split out crypto functionality from key storage functionality #8

Closed jtremback closed 9 years ago

jtremback commented 9 years ago

I'm building a system that happens to store keys in the leveldb. I'm using an old version of SSB's crypto file for my crypto, but I'd like to use this. Probably cleaner to split the filesystem functionality off, no?

jtremback commented 9 years ago

Also, what happened to the concept of the crypto code being easily replaceable?

pfrazee commented 9 years ago

I'm building a system that happens to store keys in the leveldb. I'm using an old version of SSB's crypto file for my crypto, but I'd like to use this. Probably cleaner to split the filesystem functionality off, no?

I do agree that the module's name is not right for its functionality. It needs to be renamed, but we're still discussing the entire project's name, so I haven't been in a rush to solve this problem. It does bother me though.

I'd like to have the key APIs in the same module, but I'm open to splitting them out.

Also, what happened to the concept of the crypto code being easily replaceable?

@jtremback still in the plans, I believe

dominictarr commented 9 years ago

@jtremback i'm not opposed to this at all, but can you give us more context? If you are using this, and want to be compatible we need to understand how you are using this, and intend to be using this. Otherwise we might make some decision that breaks or difficults your use case.

We are moving away from the way we where planning to support injectable crypto, and towards having tagged crypto (hashes, keys, sigs, etc) so that crypto can be upgraded in situ.

jtremback commented 9 years ago

Just seems like a good practice to keep completely disparate functionality in separate modules.

dominictarr commented 9 years ago

I wouldn't consider this a strong enough reason to mess with something that is already working, and not much of a clarity problem. If this change was combined with a more objective change (performance, correctness, security etc) then that is cool. but I for one, generally turn down a pull request that is only about opinions.

jtremback commented 9 years ago

Np, I'll close the PR