-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: ADR-066 Keyring plugin system #16637
Conversation
Co-authored-by: Marko <marko@baricevic.me>
@tac0turtle @alexanderbez updated with definitions! |
Hello! I think we need (or I need lol) a bit more of context, what's the main reason for developing this? The ADR only mentions that 99designs/keyring is not maintained, but seems a bit orthogonal to a keyring plugin system. So I think it would be good to include in the context section what you've been talking in other discussions and issues. That's my only comment, it looks great 💯 |
Hi! 👋 The idea behind this is:
The plugin system will let anyone develop a keyring by fulfilling the gRPC service with all its perks associated and as mentioned in the ADR this is compatible with the current keyring as the main interface has not been modified. |
rpc ExportPubKeyArmor(ExportPubKeyArmorRequest) returns (ExportPubKeyArmorReturns); | ||
rpc ExportPubKeyArmorByAddress(ExportPubKeyArmorByAddressRequest) returns (ExportPubKeyArmorByAddressReturns); | ||
rpc ExportPrivKeyArmor(ExportPrivKeyArmorRequest) returns (ExportPrivKeyArmorReturns); | ||
rpc ExportPrivKeyArmorByAddress(ExportPrivKeyArmorByAddressRequest) returns (ExportPrivKeyArmorByAddressReturns); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there anyway to merge these four functions, it seems a bit odd to have the api be this big
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to create an RPC endpoint for each existing keyring method. Alternatively, we can simplify this by having a single method that accepts a message containing all the necessary information to determine the user's intent. For example, we can define the following protobuf message:
message KeyringRequest {
bool exportPubKey = 1;
string uid = 2;
bytes address = 3;
}
Then, within the implementation, we can check if the uid
field is empty. If it is, we can search for the record associated with the given address
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should aim to come up with a simple api. The current api either good or bad is fairly large and increases the maintenance burden. Let's try to reduce it to a simplified api. If we need to create a larger struct that is passed that is okay as well.
rpc Key(KeyRequest ) returns (KeyReturns); | ||
rpc KeyByAddress(KeyByAddressRequest ) returns (KeyByAddressReturns); | ||
rpc Delete(DeleteRequest ) returns (DeleteReturns); | ||
rpc DeleteByAddress(DeleteByAddressRequest ) returns (DeleteByAddressReturns); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can these be deduplicated?
Key and Delete seem enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as the comment above.
#### Service Definition | ||
```protobuf | ||
service KeyringService { | ||
rpc Backend(BackendRequest) returns (BackendResponse); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does backend need to be part of this api?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is meant to return the plugins' name and version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does the node need to know what backend is being used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you markdownlint this file?
Teams can easily develop plugins to meet their specific requirements, | ||
which opens the door to new functionalities in key management. | ||
|
||
### Negative |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the overhead compared to the current implementation? In terms of latency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The methods affected by this are those related to key creation and retrieval. Ultimately, it adds one more call to the codec. I'm not sure about the exact latency impact.
The idea is to define a service method for each method already present in the keyring interface. | ||
Similarly, a request/response message will be defined for each service method. | ||
|
||
#### Service Definition |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you precise what is running the service (client or node) and if it is a node, what can is the increased load on the node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The service will be instantiated whenever a keyring call is required and terminated afterward. I believe this can be managed either by the client or the node.
I think that the overall load won't be significantly impacted, considering that plugins are lightweight and are terminated when they're no longer needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @tac0turtle do you have any other comments for us or can we close this?
should we close this and merge it into the other adr? |
We had great discussions over this ADR and implemented everything that was requested. Since this is ready, merging it instead of incorporating it as part of the bigger ADR should keep the complexity and scope reduced and allow the rest of the team to focus on other topics that will require more attention. In the other hand. It could be part of the Crypto ADR since it is aligned with the plans, but personally I don't see more benefits than having everything at one place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it makes sense to have a call about this ADR, i still think the API should be 70% less. The API proposed is the current API, for native it makes sense, but exposing so much will make it harder for users to integrate. What is the minimal API needed to funciton?
I think this would be the minimal API. service KeyringService {
rpc Backend(BackendRequest) returns (BackendResponse);
rpc List(ListRequest) returns (stream ListResponse);
rpc SupportedAlgorithms(SupportedAlgorithmsRequest) returns (SupportedAlgorithmsReturns);
rpc Key(KeyRequest ) returns (KeyReturns);
rpc Delete(DeleteRequest ) returns (DeleteReturns);
rpc Rename(RenameRequest) returns (RenameReturns);
rpc NewAccount(NewAccountRequest) returns (NewAccountReturns);
rpc SaveLedgerKey(SaveLedgerKeyRequest) returns (SaveLedgerKeyReturns);
rpc SaveOfflineKey(SaveOfflineKeyRequest)returns (SaveOfflineKeyReturns);
rpc SaveMultisig(SaveMultisigRequest) returns (SaveMultisigReturns);
rpc Sign(SignRequest) returns (SignReturns);
rpc ImportKey(ImportKeyRequest) returns (ImportKeyReturns);
rpc ExportKeyArmor(ExportKeyArmorRequest) returns (ExportKeyArmorReturns);
} The messages will hold all the information needed to determine the user's intent. Like retrieving a key from an address or an id. |
I'm starting to think this is overkill for cli support. keyring is meant for cli, which cosmos is still one of the few frameworks that have native cli. I believe this is because of a lack of client support for anything else. Id propose we rewrite the current keyring to be better maintainable and easier to integrate with autocli. This way it keeps the design simple and pushes users to use a client based frontend which will have better support for signing. |
I agree, I think we can close this. The scope of the upcoming crypto ADR will make this one deprecated, as there will be the possibility of a gRPC keyring in the new one. |
Description
Closes: #14940
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change