-
Notifications
You must be signed in to change notification settings - Fork 7
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/connect rtc #8
Conversation
# Conflicts: # package-lock.json # services/liquid-auth-api-js/package.json # services/liquid-auth-api-js/src/app.controller.ts
…ect-rtc # Conflicts: # package-lock.json # services/liquid-auth-api-js/src/connect/connect.controller.ts # services/liquid-auth-api-js/src/connect/connect.module.ts # sites/dapp-ui/src/pages/home/ConnectModal.tsx
9799efb
to
9203910
Compare
- adds tests to the core library - adds ci for pull requests
…connect-rtc # Conflicts: # sites/dapp-ui/src/pages/home/ConnectModal.tsx
- removes awesome-algorand tweetnacl fork
|
||
- Limit dependency on WebSockets to signaling | ||
- Allow bidirectional communication between peers | ||
- Enforce locality of device? |
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.
do we enforce it?
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.
We could if we remove the STUN/TURN servers but we would lose a decent percentage of devices behind symmetric NAT
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 enforced locality even possible if apple / chrome sync passkeys across devices?
Not sure about chrome but apple really doesn't adhere to the standard well
"impossible to verify the device type used to generate a key, and hence the trustworthiness of the key and its metadata. In fact, the lack of an attestation statement means that you can’t prove the key has been stored, or even generated, safely because you can’t infer properties/provenance of the authenticator."
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.
@kylebeee Enforcing locality of the WebRTC peer channel, limiting discovery to only local addresses (no STUN/TURN)
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.
if the decision is no enforcing locality we should remove this bullet IMO
@@ -47,10 +56,12 @@ async function bootstrap() { | |||
ttl: 20000, | |||
}); | |||
|
|||
app.enableCors(); | |||
|
|||
const sessionHandler = session({ | |||
secret: 'my-secret', |
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.
?
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.
Requires CORS for hosting as a third party API, this may be a requirement if projects can't integrate the service as a proxy/side-car. We can remove it for now but we should consider the following:
- Hosting from a different domain than the rendered application
- With a different domain, we require third-party cookies which are deprecated and will only have partial support by end of 2024 with eventual removal*
*Future techniques will involve device fingerprinting or assigning ID's from the service to the devices local storage. For now, it's a hard rule that the service must be the request layer and operate as a sidecar/proxy
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.
sorry, I wasn't clear with my comment here. I was referring to secret: 'my-secret'
. can we change it? reading from env maybe? something else?
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.
We should definitely read this from the env
, could be a new ticket
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.
left a few comments, otherwise LGTM
8a87888
to
af6b7e7
Compare
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 good
} | ||
return await fetch(`/assertion/request/${credId}`, { | ||
...DEFAULT_FETCH_OPTIONS, | ||
}).then((r) => { |
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.
any chance fetch
throws an exception? I don't think we handle that if that's the case
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 fetch can fail to get the URL, handling the error from the call site is good here since it's client/sdk code. We handle the invalid responses and let all other errors bubble to the call site.
client-gen.sh
Outdated
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.
couldn't find any mention of this in the readme
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 is mostly in the docs branch to limit merge conflicts with the unit tests
* @param key | ||
* @deprecated | ||
*/ | ||
sign(key: string | Account | Uint8Array | SignKeyPair): 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.
why do we need signing capabilities in the client?
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 interface is marked as deprecated
. We will need to refactor it at some point for extension wallets but it's largely been replaced by the Signaling Client and the FIDO Liquid Extension
super(); | ||
this.url = url; | ||
this.socket = io(url, options); | ||
globalThis.socket = this.socket; |
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.
why do we need to set the globalThis
?
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.
Convenience for using in projects, eventually it will be attached to the standard algorand
namespace the other wallet providers use.
} | ||
|
||
static generateRequestId() { | ||
//TODO: replace with toBase64URL(nacl.randomBytes(nacl.sign.seedLength) |
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.
shouldn't be hard to add
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 needs some changes in the API and Android client, we could kick off a new ticket to harden the requestId
* @param config | ||
*/ | ||
async peer( | ||
requestId: any, |
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.
why not 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.
It should be refactored to a encoded string when we harden the requestId
. It's any
to signal it's going to change/not stable API.
LGTM |
ℹ Overview
📝 Related Issues
🛑 Blocked by
✅ Acceptance: