-
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
identitiesProvidersList
rpc 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
identitiesAuthenticatedGet
rpc handler (which returns the user's own authenticated identities) currently uses the commandpk identities authenticated
- this name is very similar topk identities authenticate
and 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 identities
subcommand- 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 list
and anidentities list
command)
- 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 trust
command 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
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