[Experimental] Share setup downloads between laptops at Contributor Day

This issue is explicitly experimental and research-only, with no commitment to build. Start by investigating the listed checks: Windows Public-network behavior, macOS Local Network permissions, filtered Git bundles, offline npm installs, and venue client isolation. The USB fallback is described as a possible lower-risk first slice; done is not defined until the research and product scope are decided.

Experimental. Research only. Nothing here is committed to being built.

What problem does this address?

At Contributor Day the Wi-Fi is open, slow, and sometimes down. Some people in the room already have a finished site while others are still waiting on the same downloads: the wordpress-develop clone (~57 MB), npm packages (the largest part), and for Gutenberg the stock WordPress zip (~25 MB).

What is your proposed solution?

An opt-in Contributor Day mode that lets laptops in the room share those downloads with each other, torrent-style.

What would change

1. A setting, off by default. Stored in the existing preferences next to contributionEvent (src/main.js:3326). When off, the app behaves exactly as today. It switches itself off at midnight.
2. A sharing server, only while the mode is on. Serves three things by hash: a Git bundle of origin/trunk, npm packages listed in trunk's lockfile, and the stock WordPress zip.
3. Discovery of other sharers on the local network (mDNS), announced under a random ID.
4. Downloading from neighbours during setup. Git objects, npm packages (through a loopback registry proxy npm is pointed at) and the zip, each raced against the normal internet download.
5. Pairing for when the internet is fully down. Scan a code on a neighbour's screen to trust their list of hashes.

How it stays safe

The worry is fair: this would be the first thing the app exposes on an open network (every server today is loopback-only, src/bind-loopback.js). The design rests on one rule: a neighbour sends bytes, never decisions. Your app decides what it needs from a trusted source, and checks every byte against it.

Other behaviour

• Older sharers still help. A neighbour on an older trunk commit sends its history; GitHub sends only the newer commits.
• Blocked Wi-Fi (client isolation). Neighbour downloads always race the normal download, so a network that blocks laptops from each other costs nothing. The app can tell a sharer "nobody here can reach you".

USB fallback

For rooms where the network is no use at all. Same rule: the stick delivers files, the app checks them. Nothing listens and nothing is discovered, so this is the lowest-risk piece and could ship first. Organisers could also make kits the night before and hand them out at the door.

Export (from a machine with a finished site) writes one folder:

• trunk.bundle: a Git bundle of origin/trunk only, so none of the exporter's work.
• npm/: only packages listed in trunk's package-lock.json.
• The stock WordPress zip (Gutenberg).
• manifest.json: trunk commit ID, a hash of every file, and a signature. The exporter's screen shows a short code for it.
• Optionally the signed app installers, for attendees with no app and no internet. Gatekeeper and Authenticode catch tampering there.

A few hundred MB in total. Format the stick as exFAT so macOS and Windows can both read it.

Import ("Set up from a kit" when creating a site):

1. Copy the kit to local disk and check every file against the manifest. Nothing is read or run from the stick directly.
2. Trust root: with internet, the trunk commit from GitHub, so no code is needed. Offline, type the code from the exporter's screen. A code printed on the stick proves nothing, since whoever altered the stick could change it too.
3. Clone from the bundle, point origin at GitHub, and write the same repo config src/git-clone.cjs writes. Otherwise isLegacySite refuses the site.
4. npm install --offline against the imported packages; anything missing comes from the registry when online.
5. Put the zip in the Playground CLI's cache.
6. An old kit is fine: "Update trunk" fetches the newer commits once online.

Limits: a malicious USB device (one that pretends to be a keyboard) is outside what any app can defend against, so the docs should say to use sticks from organisers or people you know. Offline, trusting a kit means trusting the person who handed it over; the app checks the commit against GitHub once the internet returns.

To check before building

• Windows treats conference Wi-Fi as a Public network and blocks inbound connections. What does a Windows sharer see?
• macOS 15+ Local Network permission prompt and NSLocalNetworkUsageDescription.
• git bundle create on the --filter=blob:none clone without fetching missing blobs.
• npm install --offline from a copied cache for wordpress-develop, macOS and Windows.
• How often venue Wi-Fi uses client isolation.
• Whether the USB export needs Contributor Day mode on, or is simply a menu item.