No vaultId when creating a new vault.

[tegefaulkes]

When creating a new vault we set the vaultName and the ID is automatically generated.
However only success returned so we do not know the vaultId at time of creation.
We would have to look this up in the vaults list and work out witch one is the new ID.
It is obvious if there is only one vault the the name given but that is not always unique.

it would be nice to have the new vaultId returned when the vault is created.
It might also be useful to have extra details such as date created, is this a pulled vault, ect when listing vaults to have more context when reading the list.

[CMCDragonkai]

Is this an client GRPC API problem or does the problem exist somewhere else?

Also can you give an example of an API call where this occurs. Please give an example.

[DrFacepalm]

Put metadata in the StatusMessage response. This should solve these issues.

[DrFacepalm]

The overall design of some of the GRPC calls are proving to be quite confusing and problematic in some cases.

Some examples:

const shareMessage = new clientPB.ShareMessage();
    const ids = [info.nodeInfo.id]
    shareMessage.setName(vaultId)
    shareMessage.setId(JSON.stringify(ids))//nodeIDs
    shareMessage.setSet(true);

the setID should have been a repeated string, instead of a stingified list.

message SetActionsMessage {
  oneof node_or_provider {
    NodeMessage node = 1;
    ProviderMessage identity = 2;
  }
  string action = 3;
}

Some other things which have an option for node or identity should be using the oneof keyword.

[CMCDragonkai]

We can do this progressively, adding a message type for specific calls as we see fit.

To improve the reuse of the message types, it would good if protobuf provided ways of extending existing message types. That way common schemas can be reused. However I haven't explored this aspect yet.

In terms of doing it progressively, these 2 are calls in the grpc right now:

  rpc VaultsStat(VaultMessage) returns (StatMessage) {};
  rpc VaultsPull(VaultMessage) returns (EmptyMessage) {};

Pulling a vault is not the same kind of operation as asking about the vault's stats.

So you can just specialize this with:

  rpc VaultsStat(VaultMessage) returns (VaultStatMessage) {};
  rpc VaultsPull(VaultMessage) returns (VaultPullMessage) {};

There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton.

[CMCDragonkai]

@scottmmorris Maybe we should just incorporate this into our vaults refactoring.

[CMCDragonkai]

This should just be done inside: https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205

[CMCDragonkai]

@DrFacepalm @tegefaulkes What's the status of this?

We can create a new issue for addressing all the naming of GRPC types.

[CMCDragonkai]

Should be closed when https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205 is merged.