Most sites you use are client–server: your browser asks a server for HTML, APIs, and assets. That model is simple and scalable — but it is not the only shape data can take. This module sets the baseline so WebRTC, relays, and decentralized storage make sense later.
Your browser opens https://example.com. DNS points to an IP; TCP connects; TLS encrypts; HTTP carries a request. The server decides the response. Identity, rate limits, and business logic usually live there. The browser is a thin client.
That is perfect for documents, commerce, and centralized products. It is awkward when two browsers want to stream video or files directly to each other without paying for a big relay forever — because neither browser is a public server on the internet.
Home and mobile devices usually sit behind NAT (network address translation): one public IP for the whole network, many private IPs inside. Outbound connections work; inbound connections to a random laptop are blocked unless you port-forward or use a tunnel.
So “just open a socket on my friend’s browser” fails most of the time. Protocols like WebRTC exist partly to punch through or coordinate around NAT with help from signaling and relay servers — topics in Module 2.
Peer-to-peer means endpoints talk as equals (or at least directly), not only through a single landlord server. Benefits can include lower latency for realtime, less central custody of raw bytes, and censorship resistance — at the cost of more complex setup, discovery, and trust.
Nothing here says “throw away servers.” Real systems mix servers for coordination (signaling, relays, indexes) with peer links for data plane where it helps. Coffee’s stack is allowed to be hybrid.