address feedback
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Mar 3 2023
looks fine to me rust wise
otherwise looks fine rust wise
In D6944#206752, @atul wrote:In D6944#206737, @ashoat wrote:but identity build seems to have failed CI
Looks like this was because of issues with Buildkite Agent API, restarted the workflows.
In D6943#206753, @ashoat wrote:Why is socialProof separate from siweMessage + siweSignature? Is it for the same reason that we pull signingPublicKey from sessionInitializationInfo (convenience)?
Why is socialProof separate from siweMessage + siweSignature? Is it for the same reason that we pull signingPublicKey from sessionInitializationInfo (convenience)?
In D6944#206737, @ashoat wrote:but identity build seems to have failed CI
Make logging and errors more consistent
JS looks good, but identity build seems to have failed CI. Adding @varun as blocking for the Rust side of things
address feedback
Handle promises more gracefully
Please wait on relevant parts of CI
address feedback
Just got to the point of a successful update, still need to address feedback
Serialize messages in correct order
Realizing my comment from last time probably doesn't make sense to Flow
address feedback
Just one nit. Realizing my comment from last time probably doesn't make sense to Flow, and passing in the primary ed25519 twice (in signingPublicKey and sessionInitializationInfo) lets Rust avoid having to re-parse the JSON
Defer to you guys, I don't know enough about PAKE to comment on the .proto, and I don't know Rust so can't comment on the rest
Post semaphore once and only once. Give lambda a better name
Remove artificial body property
Improve parsing and error handling
I'm still working on one remaining issue with message ordering, but wanted the diff to be up so varun had more time to review
We talked about the usage of access tokens, and decided that we can defer doing access_token validation when the client (not keyserver) is able to provide them.
We talked about the usage of access tokens, and decided that we can defer doing access_token validation when the client (not keyserver) is able to provide them.