The changes in 097deee and 98fffb8 forced projectKey to be a hex string that must be 32-bytes long. This reverts the change so that projectKey can be any string of arbitrary length.
The implementation of discoveryKey() in hypercore-crypto uses the input as the key argument for crypto_generichash. This restricts the projectKey to be within crypto_generichash_KEYBYTES_MIN - crypto_generichash_KEYBYTES_MAX (16-bytes - 64-bytes on my machine). This doesn't matter for hypercore, since the publicKey (32-bytes long) is always used as the input for the discovery key (see https://github.com/mafintosh/hypercore-crypto/issues/4) but for our use-case it is helpful that projectKey can be of arbitrary length, so we can have human-readable project ids in the short-term (whilst we define projectId in presets.json) and we can always start using 32-bit public keys in the future for increased entropy without needing to change the discovery key generation.
This might also need changing in mapeo-web although I'm not sure it uses discoveryKey() in the same way there. @noffle?
This implementation uses a 32-byte hash of mapeo as the hash key, since the sodium docs suggest that:
the key can be used to make sure that different applications generate different fingerprints even if they process the same data.
This change is also helpful because we have downstream tests that use arbitrary-length projectKey and those tests were breaking with mapeo-core v8.
The changes in 097deee and 98fffb8 forced projectKey to be a hex string that must be 32-bytes long. This reverts the change so that projectKey can be any string of arbitrary length.
The implementation of
discoveryKey()inhypercore-cryptouses the input as thekeyargument forcrypto_generichash. This restricts the projectKey to be withincrypto_generichash_KEYBYTES_MIN-crypto_generichash_KEYBYTES_MAX(16-bytes - 64-bytes on my machine). This doesn't matter for hypercore, since thepublicKey(32-bytes long) is always used as the input for the discovery key (see https://github.com/mafintosh/hypercore-crypto/issues/4) but for our use-case it is helpful thatprojectKeycan be of arbitrary length, so we can have human-readable project ids in the short-term (whilst we define projectId in presets.json) and we can always start using 32-bit public keys in the future for increased entropy without needing to change the discovery key generation.This might also need changing in mapeo-web although I'm not sure it uses
discoveryKey()in the same way there. @noffle?This implementation uses a 32-byte hash of
mapeoas the hash key, since the sodium docs suggest that:This change is also helpful because we have downstream tests that use arbitrary-length projectKey and those tests were breaking with mapeo-core v8.