Usage of the console with "console-less" network participants
aMinuteMan opened this issue · comments
After working with the console for a while I can tell it is a great tool which removes a lot of complexity (creating channels with all possible options, updating them, collecting of signature, etc.) and provides a nicely designed UI.
However, in order to enjoy these benefits all network participants must use the UI, particularly when it comes to sending and receiving signature requests.
This opens the question how the console can be utilized in this environment.
An example would be to update a channel where a network participant using the console and a network participant not using the console have to sign a config update.
My understanding so far is that the consoles communicate directly with each other, which wouldn't work in this scenario. The second network participant would expect a config update block to sign and the first network participant would expect some kind of notification containing at least the signed block plus additional data.
In short, can the console be used in such a scenario? If yes, how, resp. is there any best-practice?
Well... it is theoretically possible with the current code to coordinate console users with non-console users across signature request events. But it will be exceedingly difficult. Its hard b/c of the auth. Its not the auth/signatures that fabric will check, but the auth that the console will check for before accepting edits/creation of signature collections.
For that reason we don't really support what you are after. However it would be a great improvement if we could. What we need is a way to wrap up the signature creation and formatting in some lib.
If someone is reading this and wants to make it happen, here's the details of some apis where you would start.
- Get signature collections api - https://github.com/hyperledger-labs/fabric-operations-console/blob/main/packages/athena/json_docs/json_validation/ibp_openapi_v3.yaml#L7130
- Edit signature collection api - https://github.com/hyperledger-labs/fabric-operations-console/blob/main/packages/athena/json_docs/json_validation/ibp_openapi_v3.yaml#L7416
- Backend code for validating signatures - https://github.com/hyperledger-labs/fabric-operations-console/blob/main/packages/athena/libs/signature_collection_lib.js#L1325
- Docs/readme on signature collection apis - https://github.com/hyperledger-labs/fabric-operations-console/blob/main/packages/athena/docs/signature_collection_apis.md
The other approach I was thinking of is this flow
- Console user creates a channel update (that needs other participants to sign)
- Console has a download option to save the proto
- Other users sign the proto using CLI or some sort, save the signature in base64 and send it to the console user (out of band)
- Console user imports the received signature
- Completes channel request
The other potential approach is to generate some sort of signature request link that can be sent to the target user that can sign using their keys and send the console just the signature
But of course these are going to require quite a bit of work!
Dear both,
thanks a lot for your comments! A "mixed" environment is not supported, that is clear to me now.
If you see a chance that this will happen in the future you could flag it as enhancement. Otherwise it can also be closed, at least no further question from my side.
Thanks again!
It could be a nice to have, but it is not in the roadmap... will could reopen if there are people interested in contributing.