Why is socialProof separate from siweMessage + siweSignature? Is it for the same reason that we pull signingPublicKey from sessionInitializationInfo (convenience)?

JS looks good, but identity build seems to have failed CI. Adding @varun as blocking for the Rust side of things

Please wait on relevant parts of CI

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

Taking it off of @tomek's plate

Minor

Avoid "coupling" in favor of a linear data flow

Got it, thanks for explaining!

Seems reasonable

Thought about this a bit more. We need to make sure that we don't accidentally initialize two tbClientBinding, but TunnelbrokerPublisher.connect is an async function, which makes this difficult to guarantee.

I don't know Rust :(

API looks good as far as I can tell, but I don't really understand the OPAQUE protocol definition so mostly deferring to you

Okay, never mind... let's pause on this work until you have time to pair with me

Oh actually, it sounds like you can just try this:

Hey @rohan, you seem to have partially landed your stack. Just wanted to get some clarification – what is the current state of master after your partial land? I want to make sure we aren't in a bad state where we are blocked from deploys. (If so, we should revert)

1. The rename would've been best in a separate diff
2. Does D6632 need to be updated so that getEmojiKeyboardPosition no longer looks at emojiKeyboard.getBoundingClientRect()?
3. It's not clear to me which change is causing the issue here. I think you should investigate:
   • If getting rid of the useEffect is what caused the issue, then you could potentially bring back the useEffect. You would be able to address my "coupling" concern, but not my "set state in effect" concern. Still, that's better than nothing.
   • It's possible that immediately calling getEmojiKeyboardPosition from the ref function is causing the problem, and you could potentially undo that by moving back to storing the node itself as state, and computing getEmojiKeyboardPosition in a useMemo that takes the node as input

I think it would've been good to separate this into two diffs: one that moves the code around, and the other than changes things (eg. the interceptor that you added). More details here

It looks like this is handled by D6780 now, and @marcin confirmed that it does not break XCode tests (which I assume includes CryptoTests?)

We still need to do this, don't we?

Yeah but it makes it much harder whenever we want to change it. Protobufs / gRPC don't handle versioning of schemas very well. @jon, do you have a good story on how we'll handle it if we need to add a new entry?

Missed this previously

Never mind that's D6911

So is the format basically { +payload: string, +signature: string }, where payload is the previously agreed upon JSON format?

this can be landed without issue