Why one Diffie-Hellman isn't enough here
The ECDH tool's exchange needs both sides online to swap public keys in real time. X3DH's trick is precomputing several DH values from keys Bob published in advance, so Alice — the sender — can complete every DH computation herself, without Bob's participation at that moment at all.
Four DH computations, folded into one secret
"Alice fetches the bundle" runs four separate ECDH computations, mixing her own identity and ephemeral keys with Bob's published identity key, signed prekey, and one-time prekey.
Combining them: a simplified stand-in for HKDF
This tool concatenates the four raw DH outputs and hashes the result with SHA-256 to produce a single shared secret. Real X3DH runs that same concatenation through HKDF (covered in the key derivation functions module) instead of a plain hash, to get a properly uniform, arbitrary-length key rather than exactly one SHA-256 digest — a simplification made here for clarity, not a difference in the core idea.
Why Bob can compute the identical secret, later
When Bob comes back online, he runs the mirrored computation — his private keys against Alice's public keys, in the same four combinations — and lands on the same four DH values Alice did, because ECDH is commutative: a·(bG) and b·(aG) are the same point, regardless of which side's private key did the multiplying. That's the exact property the ECDH tool demonstrates directly.