-
Notifications
You must be signed in to change notification settings - Fork 0
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 an asv2 resolver #143
Conversation
}: { | ||
providerUrl: string | ||
federatedAttestationsProxyContractAddress: Address | ||
authSigner: AuthSigner |
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'd like to avoid exposing types of AuthSinger
and ServiceContext
.
In general, it seems prudent to avoid exposing specific implementation details of how we might resolve things. E.g., it shouldn't matter to the caller of this library if we use web3.js or ethers; or the ODIS SDK or something else; etc.
We could check with the identity team if we can avoid exposing this. E.g., is it OK with them if we manually construct a ServiceContext from constants vs using the SDK helpers?
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.
Totally fine to declare your own ServiceContext
constant, but using the getter in the SDK ensures your info is the most up to date.
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 a little confused around your point about exposing how things are resolved. You can use the ODIS SDK with web3js or ethers already, and you can even forgo the SDK and make queries directly to ODIS if you really wanted to
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 don't want to expose the implementation details of resolve-kit to the caller. E.g., if resolve-kit uses web3js, but then wants to change to ethers, the users of this library shouldn't notice.
re ServiceContext
: that's kinda my question. Do you want to manage the specific constants via the SDK? or are you OK if users (i.e., Valora) use them directly? I think those two options have different maintenance implications on the ODIS SDK.
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.
@silasbw if I'm understanding this correctly, you don't want the caller of this library to need to pass in arguments of types ServiceContext and AuthSigner since those types are defined within the identity sdk, right?
I think it should work fine to just pass in a private key (instead of AuthSigner) and environment name (i.e. 'mainnet' or 'alfajores', instead of ServiceContext) and construct the ServiceContext and AuthSigner to pass in to the identity sdk within the ResolveCelo constuctor.
Does that address your concern?
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.
Kinda. We try (with varying degrees of success) to avoid interfaces that take a specific network name, and instead try to use the values directly that are connoted by that network name (e.g., alfajores -> https://alfajores-forno.celo-testnet.org; or local -> http://localhost:7545). We hope this facilitates more controlled integration tests, but we make compromises all the time and it sounds non-trival to spin up an ODIS instance, so what you suggest is fine.
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.
did you decide to keep these parameters as type ServiceContext and AuthSigner?
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.
Yes, for now :/, if that's OK.
7c50233
to
62fe77c
Compare
Codecov Report
@@ Coverage Diff @@
## main #143 +/- ##
==========================================
+ Coverage 87.23% 92.50% +5.26%
==========================================
Files 4 5 +1
Lines 47 80 +33
Branches 7 9 +2
==========================================
+ Hits 41 74 +33
Misses 6 6
Continue to review full report at Codecov.
|
src/resolve-celo.ts
Outdated
|
||
async resolve(id: string): Promise<NameResolutionResults> { | ||
try { | ||
// TODO(sbw): need a timeout |
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.
you can just wrap the getObfuscatedIdentifier
function in a timeout function timeout(OdisUtils.Identifier.getObfuscatedIdentifier, [params], timeoutMs, ...)
I would just note that the getObfuscatedIdentifier
function retries the ODIS query if it returns an error, so the timeout would consider all the retries as one attempt
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 might be dumb question: what's the timeout
function?
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 found a reference 1 in the celo-monorepo. It looks like timouting this way during long-lived connections could cause cascading issues, like a bunch of open sockets building up. We'd like to avoid that if possible.
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.
from the slack thread surrounding this, it seems like we need to update either @celo/base or @celo/identity to take in an AbortController. We've created a ticket for this here and will work on implementing it ASAP - most likely in the new year celo-org/celo-monorepo#10083
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.
updating that the above ticket is done ^
}: { | ||
providerUrl: string | ||
federatedAttestationsProxyContractAddress: Address | ||
authSigner: AuthSigner |
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 a little confused around your point about exposing how things are resolved. You can use the ODIS SDK with web3js or ethers already, and you can even forgo the SDK and make queries directly to ODIS if you really wanted to
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.
Looks great!! Only comment is regarding the trusted issuer list and making it easier to extend to allow for cross-wallet lookups
package.json
Outdated
@@ -39,8 +39,9 @@ | |||
"yargs": "^17.7.0" | |||
}, | |||
"dependencies": { | |||
"@celo/base": "^3.2.0", | |||
"@celo/utils": "^3.2.0", | |||
"@celo/base": "^3.0.1", |
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 a reason these aren't on the latest version?
@@ -2,3 +2,4 @@ export * from './types' | |||
export { ResolveAddress } from './resolve-address' | |||
export { ResolveGroup } from './resolve-group' | |||
export { ResolveNom } from './resolve-nom' | |||
export { ResolveCelo } from './resolve-celo' |
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.
will this be updated to ResolveSocialConnect?
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.
Yes, in a follow-on PR!
}: { | ||
providerUrl: string | ||
federatedAttestationsProxyContractAddress: Address | ||
authSigner: AuthSigner |
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.
did you decide to keep these parameters as type ServiceContext and AuthSigner?
src/resolve-celo.ts
Outdated
clearTimeout(timer) | ||
|
||
const attestations = await this.federatedAttestationsContract.methods | ||
.lookupAttestations(identifier, [this.account]) |
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.
Note that if you only pass in the Valora issuer account here you will only be able to see attestations published by Valora. Even if you don't want to allow cross-wallet lookups now, it might make sense to add the option to pass a list of trusted issuers either to this function or to the constructor so it's easier in the future
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 may also warrant adding a way to optionally store the issuer address on the NameResolution type
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.
ohhh, what's the right way to pass in the current set of "suggested" trusted issuers?
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.
Right now the set of issuers is so small that you can just hard code them in. We have the Kaala and Libera addresses listed in the docs here and can add Valora and Node's addresses as well. If the need arises in the future we have ideas about how to use a smart contract (possibly a token curated registry) to manage the "suggested" list of issuers
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.
Awesome! 👍
My main question about this is: what is the impact in Valora in the send flow?
Right now when entering a phone number this is what users see:
By adding an ASv2 resolution, this flow will then also show entries for the resolved address(es) for the entered number.
Which may be confusing.
If they click the entry with the phone number, it will use the normal internal resolution (central phone verification lookup + legacy decentralized lookup), possibly with secure send.
If they click the other pre-resolved entries, it will send to the resolved addresses.
I guess we should check what exact behavior we want so there's no surprise.
|
||
const resolutions = await resolver.resolve('+18888888888') | ||
expect(resolutions.resolutions.length).toBe(0) | ||
expect(resolutions.errors.length).toBe(1) |
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.
Should we check the error itself here?
Re @jeanregisser's point user flow point above, I thought I'd share a mockup of how Benoit and I designed the user flow in Kaala. This is how the Kaala production version in the AppStore currently handles lookups. |
Co-authored-by: 0xarthurxyz <46296830+0xarthurxyz@users.noreply.github.com>
No description provided.