feat(proxy): wire up Registry user registration #238
Conversation
xla
requested review from
rudolfs,
garbados,
geigerzaehler,
NunoAlexandre and
MeBrei
|
@MeBrei Good catch, wired it up as well as part of this PR. |
| ed25519::Pair::from_legacy_string(&format!("//{}", handle.to_string()), None); | ||
|
|
||
| use radicle_registry_client::CryptoPair; | ||
| // Give new account some dough so we can perform transactions. |
There was a problem hiding this comment.
| // Give new account some dough so we can perform transactions. | |
| // The new account needs funds to perform transactions. |
"dough" sounds cool but such language is unhelpful here, imo. Also, I suggest explaining why we are doing it, the what the code tells already.
There was a problem hiding this comment.
It's a temporary measure and I allowed myself some fun with it. Will add a comment to remove the method alltogether.
| id: juniper::ID, | ||
| ) -> Result<registry::Transaction, error::Error> { | ||
| // TODO(xla): Get keypair from persistent storage. | ||
| let fake_pair = ed25519::Pair::from_legacy_string("//Alice", None); |
There was a problem hiding this comment.
You could make this function receive the seed for the ed25519 pair instead of hardcoding it to Alice.
There was a problem hiding this comment.
Then we also need to ensure that that account has funds, will leave it until the needs arises.
| @@ -247,6 +247,21 @@ impl Registry { | |||
| Ok(self.client.get_user(user_id).await?.map(|_user| handle)) | |||
| } | |||
|
|
|||
| pub async fn prepay_account( | |||
There was a problem hiding this comment.
This is essentially a transfer, but now you can't specify the donator.
There was a problem hiding this comment.
This method is acting like a faucet, you can bootstrap a new account from the main available pool Alice. At this point there is no reason to have more flexibility until we actually wanna test transfers in the app. Also see this as temporary aid .
|
|
||
| futures::executor::block_on( | ||
| ctx.registry | ||
| .read() |
There was a problem hiding this comment.
I'm not fully sure as to what this is but should it be write since it's registering a user and not, say, getting/reading one?
There was a problem hiding this comment.
These are the calls to acquire the RWLock and as we don't mutate the field itself we don't need to acquire a write lock.
We replace the mock used so far for user registration with an actual integration with the Registry. Follow up to radicle-dev/radicle-registry#249.
Closes #185