diff --git a/@ 9bdf484 b/@ 9bdf484
diff --git a/@ 9bdf484 b/@ 9bdf484
diff --git a/@ 9bdf484 b/@ 9bdf484
diff --git a/@ 9bdf484 b/@ 9bdf484
diff --git a/@ 9bdf484 b/@ 9bdf484
diff --git a/@ 9bdf484 b/@ 9bdf484
diff --git a/@ 9bdf484 b/@ 9bdf484

1	+	# Multi-stage build for the WebRTC signaling server.
2	+	# Stage 1: compile signal.c statically against musl so the runtime image
3	+	# doesn't need libc at all.
4	+	FROM docker.io/library/alpine:3.20 AS build
5	+	RUN apk add --no-cache gcc musl-dev
6	+	WORKDIR /src
7	+	COPY server/signal.c ./
8	+	RUN cc -O3 -Wall -Wextra -Werror -static signal.c -o signal
9	+
10	+	# Stage 2: minimal runtime. Keep alpine (instead of scratch) so the
11	+	# entrypoint can use /bin/sh + cp to publish index.html into the bind-
12	+	# mounted /static directory on startup.
13	+	FROM docker.io/library/alpine:3.20
14	+	RUN apk add --no-cache curl
15	+	COPY --from=build /src/signal /usr/local/bin/signal
16	+	COPY index.html /opt/static/index.html
17	+	COPY entrypoint.sh /usr/local/bin/entrypoint.sh
18	+	RUN chmod +x /usr/local/bin/entrypoint.sh
19	+	EXPOSE 8080
20	+	ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

1	+	# WebRTC Tool
2	+
3	+	A single-page tool for direct peer-to-peer audio, video, chat, and file
4	+	transfer between two browsers, using WebRTC for the media/data path. The
5	+	client is one self-contained `index.html` with no build step. An optional
6	+	signaling server (~500 lines of C, POSIX `poll`, no dependencies) lets
7	+	peers connect by sharing a short room code instead of pasting SDP blobs.
8	+
9	+	## What it does
10	+
11	+	- Two-peer call. Microphone, camera, screen share. Standard WebRTC.
12	+	- Chat over a text data channel.
13	+	- File transfer over a separate data channel with backpressure,
14	+	cancellable mid-upload.
15	+	- Manual signaling. Generate an offer, copy/paste it to the other
16	+	peer, paste back their answer. No backend required.
17	+	- Auto signaling. Optional: both peers enter the same room code and
18	+	the signaling server relays the offer/answer for them. Media itself
19	+	still flows peer-to-peer.
20	+	- Loopback mode. Run both peers in the same tab for testing.
21	+	- Stats (RTP, codec, bandwidth) and an in-page console.
22	+
23	+	## How it works
24	+
25	+	WebRTC requires the two peers to exchange Session Description Protocol
26	+	(SDP) blobs (offer/answer) before media can flow. After that exchange,
27	+	the connection is peer-to-peer; the signaling channel is no longer used.
28	+
29	+	This tool offers two ways to do that exchange:
30	+
31	+	1. Manual. The initiator generates an offer (a few KB of text),
32	+	sends it to the joiner by any means (email, chat, etc.). The joiner
33	+	pastes it, generates an answer, sends it back, and the initiator
34	+	pastes it. No server involved.
35	+	2. Auto. Both peers enter the same room code into the signaling
36	+	server's UI. The server stores the offer briefly, hands it to the
37	+	other peer when they ask, and is forgotten as soon as the answer
38	+	has been delivered. Rooms expire after 5 minutes of inactivity.
39	+
40	+	The signaling server understands four endpoints:
41	+
42	+	```
43	+	POST /room/<code>/offer POST /room/<code>/answer
44	+	GET /room/<code>/offer GET /room/<code>/answer
45	+	GET /health
46	+	```
47	+
48	+	Long-polling: a `GET` that arrives before the matching blob exists is
49	+	parked for up to 10 s and answered with `204 No Content` on timeout; the
50	+	client retries. As soon as the matching `POST` arrives, the parked
51	+	request is woken with `200` and the SDP body. After the answer has been
52	+	delivered to the initiator, the room is dropped.
53	+
54	+	## Usage
55	+
56	+	### Standalone (no backend)
57	+
58	+	The full feature set works without the backend, using manual signaling.
59	+	Each peer just needs to load `index.html`; they don't need to load it
60	+	from the same place. Options:
61	+
62	+	- Send the file to the other peer and have them open it from disk
63	+	(`file://…`).
64	+	- Host it on any static web server (a personal site, GitHub Pages,
65	+	Netlify, S3, etc.) and share the URL.
66	+	- For local testing on one machine, serve it on loopback:
67	+	`python3 -m http.server 8000` and open `http://localhost:8000/`.
68	+
69	+	Then both peers pick Manual mode in the configure screen, the
70	+	initiator generates the offer and sends the blob to the joiner (email,
71	+	chat, etc.), and the joiner sends the answer back the same way.
72	+
73	+	For mic/camera/screen-share to work, the page must be loaded from a
74	+	secure context: either `https://…`, `http://localhost`, or `file://`
75	+	(some browsers, with limits). On plain `http://` to a remote host,
76	+	browsers will refuse to grant media access.
77	+
78	+	### With the signaling backend
79	+
80	+	The backend is needed only if you want auto signaling (peers exchange
81	+	SDPs via a room code rather than copy-paste). It does not see or
82	+	proxy media — that's still peer-to-peer.
83	+
84	+	```
85	+	podman compose up -d # builds the image and starts the server on :8080
86	+	# or: docker compose up -d
87	+	```
88	+
89	+	After startup, `./static/index.html` appears on the host (copied out of
90	+	the image). Point your own web server at `./static` to serve the page.
91	+
92	+	Or just build and run the binary directly:
93	+
94	+	```
95	+	cc -O2 -Wall -Wextra -Werror server/signal.c -o signal
96	+	./signal 8080
97	+	```
98	+
99	+	### Loopback (testing)
100	+
101	+	In the configure screen, pick Loopback and click Continue. Both
102	+	peers run in the same tab over a local RTCPeerConnection pair. Useful
103	+	for trying chat/file transfer/codec settings without a second device.
104	+
105	+	## Self-hosting at a single URL
106	+
107	+	For a production setup with both the HTML and the signaling server on
108	+	the same origin (no CORS, no `Server URL` field to fill in), reverse-
109	+	proxy `/room/*` and `/health` to the backend and serve everything else
110	+	as static files.
111	+
112	+	The backend binds to `127.0.0.1:8080` (or whatever you mapped in
113	+	`compose.yml`). Configs below assume the static files live at
114	+	`/var/www/webrtc` and the backend listens on `127.0.0.1:8080`.
115	+
116	+	### Caddy
117	+
118	+	```caddy
119	+	example.com {
120	+	encode zstd gzip
121	+	root * /var/www/webrtc
122	+
123	+	@signaling path /room/* /health
124	+	reverse_proxy @signaling 127.0.0.1:8080
125	+
126	+	file_server
127	+	}
128	+	```
129	+
130	+	### nginx
131	+
132	+	```nginx
133	+	server {
134	+	listen 443 ssl http2;
135	+	server_name example.com;
136	+
137	+	ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
138	+	ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
139	+
140	+	root /var/www/webrtc;
141	+	index index.html;
142	+
143	+	# Signaling backend: long-polled, must disable response buffering
144	+	# so the 204/200 reaches the browser as soon as the server writes it.
145	+	location ~ ^/(room/\|health$) {
146	+	proxy_pass http://127.0.0.1:8080;
147	+	proxy_http_version 1.1;
148	+	proxy_set_header Host $host;
149	+	proxy_buffering off;
150	+	proxy_read_timeout 30s;
151	+	}
152	+
153	+	location / {
154	+	try_files $uri $uri/ =404;
155	+	}
156	+	}
157	+	```
158	+
159	+	### lighttpd
160	+
161	+	```lighttpd
162	+	server.modules += ( "mod_proxy" )
163	+	server.document-root = "/var/www/webrtc"
164	+	index-file.names = ( "index.html" )
165	+
166	+	$HTTP["url"] =~ "^/(room/\|health$)" {
167	+	proxy.server = ( "" =>
168	+	(( "host" => "127.0.0.1", "port" => 8080 ))
169	+	)
170	+	proxy.header = ( "upgrade" => "disable" )
171	+	}
172	+	```
173	+
174	+	## Configuration notes
175	+
176	+	- HTTPS is required for production. Browsers gate microphone,
177	+	camera, and screen-share behind a secure context. The page works in
178	+	receive-only mode without media access, but most users will want at
179	+	least one side to publish.
180	+	- Same-origin removes the CORS path entirely. When the HTML and
181	+	signaling are served from the same scheme+host+port, the browser
182	+	doesn't issue preflights and the `Server URL` field in the configure
183	+	screen can be left at its default (`location.origin`).
184	+	- `http://localhost` is treated as secure by Chromium and Firefox,
185	+	so local development with mic/cam works without certificates.
186	+	- Server capacity is hard-coded in `server/signal.c`: 1024 rooms.
187	+	Rooms expire after 5 minutes of inactivity and are also deleted immediately
188	+	once the answer reaches the initiator; a GC sweep runs every 60 s.
189	+	Each connection pre-allocates a ~68 KB request buffer, so the BSS reaches
190	+	~140 MB — Linux only touches the pages on demand, so an idle server
191	+	uses around 10 MB resident.
192	+
193	+	## Repository layout
194	+
195	+	```
196	+	.
197	+	├── index.html # client (one self-contained page, no build)
198	+	├── server/
199	+	│ └── signal.c # signaling server (~500 lines, POSIX poll, no deps)
200	+	├── Containerfile # multi-stage build, static-musl binary, alpine runtime
201	+	├── compose.yml # podman/docker compose: builds image, exposes :8080
202	+	├── entrypoint.sh # copies index.html into the bind-mounted /static
203	+	└── README.md
204	+	```

1	+	services:
2	+	webrtc-tool:
3	+	build:
4	+	context: .
5	+	ports:
6	+	- "8080:8080"
7	+	volumes:
8	+	# Bind-mount a host directory the entrypoint will drop index.html into.
9	+	# Point your own web server (nginx/caddy/python -m http.server / etc.)
10	+	# at this directory to serve the page. Anything else placed here is
11	+	# preserved; only index.html is overwritten on container start.
12	+	- ./static:/static
13	+	healthcheck:
14	+	test: ["CMD-SHELL", "curl --show-error --silent http://localhost:8080/health -o /dev/null"]
15	+	interval: 30s
16	+	timeout: 5s
17	+	retries: 3
18	+	start_period: 5s

1	+	#!/bin/sh
2	+	# Publish the bundled index.html into the (typically bind-mounted) /static
3	+	# directory so the host's web server can pick it up, then start the
4	+	# signaling server. Always overwrites so a rebuilt image updates the file.
5	+	set -e
6	+	if [ -d /static ] && [ -w /static ]; then
7	+	cp -f /opt/static/index.html /static/index.html
8	+	fi
9	+	exec /usr/local/bin/signal "${PORT:-8080}"