diff --git a/proposals/4388-secure-qr-channel.md b/proposals/4388-secure-qr-channel.md
index f4270a6a4..c36945c76 100644
--- a/proposals/4388-secure-qr-channel.md
+++ b/proposals/4388-secure-qr-channel.md
@@ -28,6 +28,44 @@ This proposal is split into three parts:
- Encoding the rendezvous session and an ephemeral key in a QR code
- Establishing a secure channel over the insecure rendezvous session using an ephemeral key
+The overall flow looks like this:
+
+```mermaid
+sequenceDiagram
+ participant G as Device generating QR
+ participant HS as Homeserver
+ participant S as Device scanning QR
+
+ note over G,S: Generating and scanning devices each pick ephemeral Curve25519 keys to use to set up the secure channel
+
+ note over G: Generating device picks a suitable homeserver to use for the rendezvous session
+
+ G->>+HS: Creates a rendezvous session on the homeserver
+ HS->>-G: ID for the rendezvous
+
+ note over G: Generates and displays a QR code containing:
ephemeral key of generating device, rendezvous ID, homeserver base URL,
device disposition (whether device is new or existing)
+
+ G-->>S: Other device scans the QR code
+
+ note over S: Scanning device checks that the disposition matches what it expects
+
+ S->>+HS: Scanning device checks that it can communicate with the
rendezvous session on the homeserver identified by information in QR
+ HS->>-S: OK
+
+ G<<->>S: Generating and scanning device then communicate by
sending and receiving to/from the rendezvous session via the homeserver
+
+ note over G,S: Devices perform Elliptic Curve Diffie-Hellman protocol
(using the ephemeral keys from earlier on) to agree a shared secret
+ S->>G: Scanning device sends LoginInitiateMessage handshake message
+ G->>S: Generating device validates and responds with LoginOkMessage handshake message
+
+ note over G,S: Devices ask user to confirm that the connection isn't being Man-In-The-Middle attacked by
entering a two digit CheckCode shown on scanning device into the generating device
+
+ S-->>G: User enters two digit code
+ note over G,S: Devices can now communicate securely using the shared secret to encrypt future messages via the rendezvous session
+
+ S<<->>G: Devices then send and receive messages as described in MSC4108
+```
+
## Insecure rendezvous session
It is proposed that an HTTP-based protocol be used to establish an ephemeral bi-directional communication session over
@@ -36,7 +74,7 @@ end-to-end confidentiality nor authenticity by itself - these are layered on top
New optional HTTP endpoints are to be added to the Client-Server API.
-### High-level description
+### Concept
Suppose that Device A wants to establish communications with Device B. Device A can do so by creating a
_rendezvous session_ via a `POST /_matrix/client/v1/rendezvous` call to an appropriate homeserver. Its response includes