-
Notifications
You must be signed in to change notification settings - Fork 58
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
feat: add keyfile support for RLN credentials secure storage #1285
Changes from all commits
7abe2fd
a6bf2be
31a9787
1d79fbf
0ded30f
2a6464b
fc5f48f
7dc2469
eb744d3
7c2c1f9
589ee0d
517c3b1
5a47ec3
e74cc7e
168612e
08be67c
d814f17
4ff8a7f
01ebc54
9b6850e
6aa7805
edab924
75c6ff6
112de23
239113c
ffad08b
78f2151
def10d0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -161,7 +161,12 @@ type | |
desc: "Address of membership contract on an Ethereum testnet", | ||
defaultValue: "" | ||
name: "rln-relay-eth-contract-address" }: string | ||
|
||
|
||
rlnRelayCredentialsPassword* {. | ||
desc: "Password for encrypting RLN credentials", | ||
defaultValue: "" | ||
name: "rln-relay-cred-password" }: string | ||
Comment on lines
+165
to
+168
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can this configuration option be within a The rest of the RLN conf options should also be under the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See my comment: #1285 (comment) |
||
|
||
staticnodes* {. | ||
desc: "Peer multiaddr to directly connect with. Argument may be repeated." | ||
name: "staticnode" }: seq[string] | ||
|
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 this configuration option be within a
when defined(rln):
compilation guard?The rest of the RLN conf options should also be under the
when
compilation guard; if this is allowed by Nim.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.
Possible, but the full
Chat2Conf/WakuNodeConf
object has to be redefined under/outside the flag, i.e. we duplicate all the remaining field definition. I agree that it should be the case, i.e. not have fields unless supported, but nim seems a bit unhandy for these tasks. No problem for me, but maybe not the right PR. Wdyt?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'm ok moving this to another PR. Not a blocker on this PR, but certainly, in the near future, we should put a
when
guard to RLN-specific configuration options (the same way we have it in the implementation).cc @rymnc @staheri14
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.
Tracking issue #1294
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.
One more relevant issue about the visibility of config options is #999 where it was suggested to use sub-commands to group all the rln-relay-related configs and make them available only when the rln-relay config option is set to true. Would that address your comment @LNSD ?
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.
Now I see why you said that. It is an issue in
nim-confutils
macros 😫 Then, let's leave it as it is until we have a better way of doing this.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.
Oh! I thought was just not possible in nim (i.e. have object fields defined at compilation-time), but indeed with some macros it might be possible to achieve the same goal.
I agree that this has to be done in followup PRs! Thanks for pointing it out!
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.
@LNSD I see your point, that makes sense.
It was suggested in one of the PRs and my understanding was that it is part of the plan to use subcommands: #992 (comment) @jm-clius
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.
Please let us know if the plan re subcommands has changed so that we deprioritize that issue i.e., #999 cc: @jm-clius @LNSD
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.
@LNSD
I'd say all the rln-relay-related config options will get encapsulated (and only accessible) under the rln-relay command/subcommand, hence the CLI interface becomes less confusing for the users (I assume this is the desirable feature we are looking for)