Was thinking, a cleaner way of implementing many of the things we have in-source right now would be by using traits / structs a bit better. Currently we have the following problems:
crypto is not aware of the structs in storage that it needs to sign.
the struct in crypto/key_pair is unaware of methods that are available in crypto/mod.
we don't have a first-class Hash struct yet.
Signature lives in storage, but is relevant to crypto too.
Something like the following:
Traits
Encrypt: using a KeyPair, sign data. Alt name: Sign.
Hash: hash data using BLAKE2b into a Hash.
Store: persist data to a Storage instance.
Structs
Node:tree data that is stored.
Bitfield: the main bitfield instance (this should stay as an internal module)
Signature: data hash.
Storage: in charge of writing values to a random-access-storage instance.
KeyPair: set of keys to sign things.
Feed: the external facing API.
Storage API
It'd be good to have the Store trait to implement a method that can write to a Storage instance.
The read/write methods can then respectively just call the .from_bytes() and .to_vec() methods respectively. Persisting to disk can then be done by just calling out to .store().
By having it in a trait we should be able to simplify the Storage module a bunch. We'll still need dedicated methods for reading / writing each type, but the hope is that we'll be able to do away with some of the inline magic numbers (e.g. 40, 32) and move them to be part of the corresponding structs.
Why Encrypt & Hash traits?
I think it's pretty nice to have a separate submodule dedicated to crypto. By creating traits rather than functions, we can create a looser relationship between our crypto internals, and the way we provide data to the crypto functions.
Was thinking, a cleaner way of implementing many of the things we have in-source right now would be by using traits / structs a bit better. Currently we have the following problems:
crypto/key_pair
is unaware of methods that are available incrypto/mod
.Hash
struct yet.Signature
lives in storage, but is relevant tocrypto
too.Something like the following:
Traits
KeyPair
, sign data. Alt name:Sign
.BLAKE2b
into aHash
.Storage
instance.Structs
tree
data that is stored.random-access-storage
instance.Storage API
It'd be good to have the
Store
trait to implement a method that can write to aStorage
instance.The
read/write
methods can then respectively just call the.from_bytes()
and.to_vec()
methods respectively. Persisting to disk can then be done by just calling out to.store()
.By having it in a trait we should be able to simplify the
Storage
module a bunch. We'll still need dedicated methods for reading / writing each type, but the hope is that we'll be able to do away with some of the inline magic numbers (e.g.40
,32
) and move them to be part of the corresponding structs.Why Encrypt & Hash traits?
I think it's pretty nice to have a separate submodule dedicated to crypto. By creating traits rather than functions, we can create a looser relationship between our crypto internals, and the way we provide data to the crypto functions.