You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current GenericIdTypes module is slightly out of place within the larger architecture of the js-polykey codebase. We should find some time to review this, and refactor its required implementation to more suitable areas of the codebase. It was originally introduced in order to facilitate usage of the js-id module within Polykey.
Add some of the encoding wrappers into the IdInternal class, this requires a new PR in js-id. Include toMultibase and toUUID and toBuffer as instance methods, and the fromString, fromMultibase, fromUUID, and fromBuffer as static methods (these represent alternatives of creating the IdInternal). Make sure that these functions return Id as the type and not IdInternal.
This PR will focus on applying the new NodeId which is an opaque alias of Id (which itself is an alias of IdInternal & number).
All the areas which is currently using NodeId is expecting an encoded string. These will need to be changed to expect a sort of type NodeIdEncoded = string;, you still need a nodesUtils.encodeNodeId.
The encoding functions and decoding functions of NodeId should be inside nodes/utils.ts. This should be similar to how I'm doing it for VaultId. An alternative might be to create class extension or generics, but this seems complicated.
Raw usage of the NodeId will mostly occur inside the nodes domain, in particular the NodeGraph can use the Uint8Array directly. Note that the js-db currently doesn't yet allow direct usage of the Id, because it requires a Buffer type. However there is an issue Use bufferWrap to support ArrayBuffer, Uint8Array and Buffer js-db#3 to allow it to eventually take Id, so for now, just use idUtils.toBuffer and idUtils.fromBuffer when interacting with the DB.
Specification
The current
GenericIdTypesmodule is slightly out of place within the larger architecture of thejs-polykeycodebase. We should find some time to review this, and refactor its required implementation to more suitable areas of the codebase. It was originally introduced in order to facilitate usage of thejs-idmodule within Polykey.Additional context
js-idtoo) - discussion originally from here https://vimeo.com/manage/videos/652339635 5:00 - 17:30cloneVault#253 - vault id usage in EFS and when cloningTasks
IdInternalclass, this requires a new PR injs-id. IncludetoMultibaseandtoUUIDandtoBufferas instance methods, and thefromString,fromMultibase,fromUUID, andfromBufferas static methods (these represent alternatives of creating theIdInternal). Make sure that these functions returnIdas the type and notIdInternal.NodeIdas a proxy/singleton instance #254 and relates to Review js-id usage for NodeId, VaultId, NotificationId, PermId, ClaimId, Gestalts andGenericIdTypes.ts#299 (this requires more work to be done, not just node id).NodeIdwhich is an opaque alias ofId(which itself is an alias ofIdInternal & number).NodeIdis expecting an encoded string. These will need to be changed to expect a sort oftype NodeIdEncoded = string;, you still need anodesUtils.encodeNodeId.NodeIdshould be insidenodes/utils.ts. This should be similar to how I'm doing it forVaultId. An alternative might be to create class extension or generics, but this seems complicated.NodeIdwill mostly occur inside the nodes domain, in particular theNodeGraphcan use theUint8Arraydirectly. Note that thejs-dbcurrently doesn't yet allow direct usage of theId, because it requires aBuffertype. However there is an issue UsebufferWrapto supportArrayBuffer,Uint8ArrayandBufferjs-db#3 to allow it to eventually takeId, so for now, just useidUtils.toBufferandidUtils.fromBufferwhen interacting with the DB.NodeManagertoNodeConnectionManager#310 on top to benefit from it.GenericIdTypes.tscan be removed once all other areas of code stop using it.