Skip to content
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

Merged
merged 7 commits into from
Mar 14, 2023
Merged

feat: add an asv2 resolver #143

merged 7 commits into from
Mar 14, 2023

Conversation

silasbw
Copy link
Contributor

@silasbw silasbw commented Dec 19, 2022

No description provided.

}: {
providerUrl: string
federatedAttestationsProxyContractAddress: Address
authSigner: AuthSigner
Copy link
Contributor Author

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?

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.

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

Copy link
Contributor Author

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.

Copy link

@alecps alecps Dec 21, 2022

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?

Copy link
Contributor Author

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.

Copy link

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?

Copy link
Contributor Author

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.

@codecov-commenter
Copy link

codecov-commenter commented Dec 19, 2022

Codecov Report

Merging #143 (da77830) into main (c7ebb72) will increase coverage by 5.26%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
src/resolve-celo.ts 100.00% <100.00%> (ø)
src/types.ts 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7ebb72...da77830. Read the comment docs.


async resolve(id: string): Promise<NameResolutionResults> {
try {
// TODO(sbw): need a timeout
Copy link

@isabellewei isabellewei Dec 19, 2022

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link

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

Copy link

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

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

Copy link

@alecps alecps left a 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",
Copy link

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'
Copy link

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?

Copy link
Contributor Author

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
Copy link

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?

clearTimeout(timer)

const attestations = await this.federatedAttestationsContract.methods
.lookupAttestations(identifier, [this.account])
Copy link

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

Copy link

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

Copy link
Contributor Author

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?

Copy link

@alecps alecps Feb 22, 2023

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

src/resolve-celo.ts Outdated Show resolved Hide resolved
Copy link
Member

@jeanregisser jeanregisser left a 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)
Copy link
Member

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?

@arthurgousset
Copy link
Contributor

arthurgousset commented Mar 8, 2023

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.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants