-
Notifications
You must be signed in to change notification settings - Fork 4
Closed
Labels
designRequires design (architecture, protocol, specification and task list requires further work)Requires design (architecture, protocol, specification and task list requires further work)discussionRequires discussionRequires discussionr&d:polykey:core activity 3Peer to Peer Federated HierarchyPeer to Peer Federated Hierarchy
Description
Specification
Our Identities CLI seems incomplete and needs to be reviewed. In particular:
- The
identitiesToken*rpc handlers have no corresponding CLI commands - something likepk identities token ...should be added- We need to consider what kind of access we want the user to have to this data (authenticating a provider already "puts" a token - need to consider the implications of allowing the user to put/get/delete their own tokens)
- Our 'tokens' are data of the following type:
type TokenData = {
accessToken: string;
refreshToken?: string;
accessTokenExpiresIn?: number;
refreshTokenExpiresIn?: number;
};- The
identitiesProvidersListrpc handler has no corresponding CLI command - possible command could bepk identities providers- As it's currently implemented, this just returns a list of the providers (provider ids) currently registered to the IdentitiesManager (and thus supported by Polykey)
- The
identitiesAuthenticatedGetrpc handler (which returns the user's own authenticated identities) currently uses the commandpk identities authenticated- this name is very similar topk identities authenticateand could get confusing- The naming of this command, as well as its relationship with the token manipulation commands (particularly
identitiesTokenGet) should be reviewed
- The naming of this command, as well as its relationship with the token manipulation commands (particularly
- At the moment, the gestalts and identities commands are both grouped under the
pk identitiessubcommand- We should consider separating these, especially as the functionality of our CLI grows and we need to be able to reuse command names (e.g. we may need both a
gestalts listand anidentities listcommand)
- We should consider separating these, especially as the functionality of our CLI grows and we need to be able to reuse command names (e.g. we may need both a
- Many of the identities CLI commands receive data from the server in the form of a stream, however this data is outputted as a single array
- This should be modified such that the data returned from the stream is streamed to stdout as we iterate through it (as opposed to after)
- The
identities trustcommand does not add a new node into the gestalt graph if it cannot find it in the node graph/via Kademlia- Related to Discovery - revisiting Gestalt Vertices and error handling Polykey#328
- More context provided here https://github.com/MatrixAI/js-polykey/issues/334#issuecomment-1043779027
Additional context
- General CLI review issue: Publishing the PK CLI for General Use Polykey#268
- Beginning of a thread discussing some of the issues with the identities CLI: Growing the Gestalt Graph and Implementing Social Discovery Polykey#320 (comment)
Tasks
- Review what functionality should be exposed to the CLI and what should not
- Create CLI commands for functionality that is not yet exposed to the CLI
- Consider separating identities and gestalts commands in the CLI
- Ensure that data returned as a stream to the CLI is outputted to STDOUT as a stream
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
designRequires design (architecture, protocol, specification and task list requires further work)Requires design (architecture, protocol, specification and task list requires further work)discussionRequires discussionRequires discussionr&d:polykey:core activity 3Peer to Peer Federated HierarchyPeer to Peer Federated Hierarchy