Andrew Dryga

@thomaseizinger a few questions: 1. Is there any reason why client can't generate ICE creds and send them over in connection intent and eliminate an async process of distributing them...

@thomaseizinger what if, to eliminate 2nd roundtrip, the portal will figure out if tunnel can be reused? You already send `connected_gateway_ids` so if I select one of the gateways that...

@thomaseizinger but this race is not solved by having a separate message, you still can send me `connection_details` and something can fail on the client or gateway while it's being...

Here are two ideas. First if we don't care about `gateway_payload` and response from gateway for reused connections in general (but there will be race if client tries to send...

BTW keep in mind the messages between `client` and `gateway` processes in the portal can also have a costly roundtrip/network splits/other failure scenarios once we scale out our API -...

Here is the design we settled on: ```mermaid sequenceDiagram Client->>Portal: upsert_flow (resource_id, connected_gateway_ids) Portal->>Portal: Authorize and Log Access Portal->>Portal: Generate preshared_key (random 32 bits) Portal->>Portal: Generate Ice Credentials (hash of...

@thomaseizinger renamed, lmk if you want to change more - I'm don't have any strong opinions about naming there

@thomaseizinger I'll add payload field. Does the gateway need to send any payload back to the client?

@thomaseizinger > I think we need to embed the domain and proxy IPs in the initial upsert_flow message because this check is part of the authorisation and we shouldn't authorize...

@thomaseizinger I'm afraid that if we replace battle tested in 1000s of productions WebSocket transport layer we will: 1. Have to maintain it for eternity without getting any critical fixes...