Use @spartan-hc/holo-hash for managing holo-hashes #259
Conversation
|
@jost-s do you see value in this? |
src/utils/base64.ts
Outdated
| } | ||
|
|
||
| export * from "@spartan-hc/holo-hash"; |
There was a problem hiding this comment.
This causes ambiguity because the HoloHash classes have the same name as all the types.ts exports. How should we export the class implementations without conflict?
There was a problem hiding this comment.
I think we should ship this client with only one type for each type. So I wouldn't want to export a legacy type and the new type under an alias. Therefore I'd replace the existing type with the spartan-hc one.
What do you think about this, @ThetaSinner?
There was a problem hiding this comment.
Supporting both HoloHash and Uint8Array input for most functions is important so that users are not forced to wrap all input in new HoloHash( input ). But I don't know enough about typescript to do that. Would it work to extend all the types with an "or-pipe"?
Example
export type AgentPubKey = Uint8Array | HoloHashLib.AgentPubKey;There was a problem hiding this comment.
Nevermind, that doesn't solve the duplicate export issue.
There was a problem hiding this comment.
Just to let you know this is still on my radar.
| * @returns The signing key pair and an agent pub key based on the public key. | ||
| * | ||
| * @public | ||
| */ | ||
| export const generateSigningKeyPair: ( | ||
| agentPubKey?: AgentPubKey |
There was a problem hiding this comment.
What is the purpose of forcing the same location bytes? Imposing location bytes on the end of random bytes makes the DHT location check fail.
| @@ -1,77 +1,77 @@ | |||
| import { range } from "lodash-es"; | |||
| import { randomByteArray } from "../api/zome-call-signing.js"; | |||
| import { DnaHash, ActionHash, AgentPubKey, EntryHash } from "../types.js"; | |||
| import { dhtLocationFrom32 } from "./hash-parts.js"; | |||
|
|
|||
| async function fakeValidHash<T extends Uint8Array>( | |||
There was a problem hiding this comment.
Since this function is not exported, it is safe to assume it was only used by this file. Correct?
Here is a quick example of how we could start using a library to manage holo-hashes while preserving legacy support.
Most of the helper functions in utils could be replaced by the native methods on
HoloHashinstances.sliceDhtLocation=><HoloHash>.getDHTLocationsliceCore32=><HoloHash>.getHashsliceHashType=><HoloHash>.getPrefix