WeStream — a Zoom-style screen & voice streaming platform (2020)

High school final project · Spring 2020 · Python 3.7 · Written entirely by hand, before the AI era

This is my 12th-grade final project in networking (עבודת גמר ברשתות), built from scratch during the COVID-19 lockdowns of spring 2020 — the same months the whole world was suddenly living on Zoom. Every line here was written the pre-AI way: with books, documentation, Stack Overflow, and a lot of trial and error. No Copilot, no ChatGPT — they didn't exist yet.

The code is preserved exactly as it was submitted in May 2020 (teenage spelling mistakes included). The only changes made for publication are privacy redactions in the project book and this README.

What it does

WeStream lets one person stream their screen and voice to many viewers over the network — and moderate them, Zoom-style:

• Accounts — streamer registration and login backed by a SQLite database
• Stream lobby — browse live streams by name, viewer count, and category (Teaching, Gaming, Talking…), or join directly with a stream code
• Public and private streams — private streams are joinable only by code
• Live screen sharing — the streamer's screen is captured, compressed, and pushed to all viewers
• Voice chat — the streamer talks; viewers can be granted the mic
• Moderation tools — per-viewer mute/unmute, allow/disallow speaking, kick, ban
• "Raise hand" — viewers ask for the mic, the streamer decides
• Text chat — a shared chat room alongside the stream

Screenshots

Live screen share with chat (streaming its own window, hall-of-mirrors style)	The lobby — live streams with viewer counts and categories
Creating a public or private stream	Streamer registration

Architecture

A central server coordinates accounts and stream discovery; the actual media flows peer-to-peer, with the streamer's machine acting as the media server for its viewers:

flowchart LR
    subgraph central[" Central server "]
        direction TB
        S["Server logic<br/>login · registration · lobby"]
        DB[("SQLite<br/>user accounts")]
        S <--> DB
    end

    subgraph machine["&nbsp;Streamer's machine&nbsp;"]
        direction TB
        SC["Streamer client<br/>wxPython GUI"]
        VS["Video server<br/>screen frames · zlib"]
        AS["Audio server<br/>voice · mic permissions"]
        MS["Chat server<br/>messages · moderation"]
        SC --- VS
        SC --- AS
        SC --- MS
    end

    V["Viewer clients"]

    SC -- "register stream<br/>(control TCP)" --> S
    V -- "login · browse lobby<br/>(control TCP)" --> S
    VS == "screen share" ==> V
    AS <== "voice" ==> V
    MS <== "chat" ==> V

Loading

The design separates a control plane (thin arrows — everything goes through the central server) from a media plane (thick arrows — video, audio, and chat flow directly between peers over dedicated TCP channels, never touching the central server).

And here is the original architecture diagram from the 2020 project book — drawn by hand in draw.io before writing a line of the implementation:

Everything is hand-rolled on raw TCP sockets:

• Custom application protocols — opcode-prefixed messages with custom separators, one protocol per channel (control, video, audio, chat)
• Concurrency — Python threading with select-based socket handling; per-viewer threads for audio fan-out
• Media pipeline — screen capture via PIL/OpenCV, zlib compression, pickle/struct framing; microphone capture and playback via PyAudio
• GUI — wxPython with pubsub events connecting network threads to the UI
• Persistence — sqlite3 for user accounts

Repository layout

server/   — the central server (run this first)
client/   — the desktop app: lobby, streamer & viewer GUIs, P2P media servers
docs/     — the 100+ page project book (Hebrew), class presentation, screenshots,
            and the original 2020 README
vendor/   — the PyAudio wheel that Windows + Python 3.7 needed back in 2020

Running it (as of 2020)

Built for Python 3.7 on Windows; the exact pins are in requirements.txt.

1. pip install -r requirements.txt (PyAudio may need the wheel in vendor/)
2. Start the central server: python server/Server_logic.py
3. Point clients at the server: edit client/Starting_information.py (IP/port)
4. Start a client: python client/User_Startup_2.0.py

The project book

The full engineering document submitted with the project — requirements, design, protocol specifications, and testing — is in docs/report (Hebrew, ~100 pages). It walks through the whole process from initial concept to the finished system.

A note from the future (2026)

Reading this code today, I can spot plenty I'd do differently — SQL built with f-strings instead of parameterized queries, passwords stored in plaintext, no TLS on the wire. I'm leaving it all exactly as it was: it's an honest snapshot of what a high schooler could build alone in 2020 with sockets, threads, and stubbornness — designing multi-channel network protocols, debugging race conditions, and shipping a working multi-user streaming app without a single AI assistant, because there weren't any.