add open design questions to README
This commit is contained in:
parent
a35e30c05c
commit
a1fa0d8fe5
|
@ -54,9 +54,16 @@ The manifest file would do several important things:
|
|||
* metadata size should not be used as an excuse to sacrifice utility (such as providing checksums over each chunk of a large file)
|
||||
|
||||
# Open Questions
|
||||
|
||||
* Should the manifest file include checksums of individual file chunks, or just for the whole assembled file?
|
||||
* If so, should the chunksize be fixed or dynamic?
|
||||
|
||||
* Should the manifest signature format be GnuPG signatures, or those from
|
||||
OpenBSD's signify (of which there is a good [golang
|
||||
implementation](https://github.com/frankbraun/gosignify)?
|
||||
|
||||
* Should the on-disk serialization format be proto3 or json?
|
||||
|
||||
# Tool Examples
|
||||
|
||||
* `mfer gen` / `mfer gen .`
|
||||
|
@ -109,4 +116,4 @@ I would like to be able to plug in a hard drive or flash drive and, if there is
|
|||
# Collaboration
|
||||
Please email [`sneak@sneak.berlin`](mailto:sneak@sneak.berlin) with your desired username for an account on this Gitea instance.
|
||||
|
||||
I am currently interested in hiring a contractor skilled with the Go standard library interfaces to specify this tool in full and develop a prototype implementation.
|
||||
I am currently interested in hiring a contractor skilled with the Go standard library interfaces to specify this tool in full and develop a prototype implementation.
|
||||
|
|
Loading…
Reference in New Issue