CydandClaude Fable 5
7ebcb0f0ab
- README: project charter + seed concept (per-site 10.0.y.0/24 subnets, VPN into one /16, merged siteconfigs -> master console) - docs/PODBAY-ECOSYSTEM: survey of the existing bay stack with source pointers (TeslaSuite RPC 53290, Firestorm DirectPlay 4 + CTCL, BT411 console/egg protocol, RP Munga 1501, PQS, port map) - docs/BRAINSTORM: addressing plan, routed-L3 vs bridged-L2 analysis, master console vs federation, per-game linking, shared services, security posture, open questions, phased roadmap - sites/: site-ID / subnet registry (public info only) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
40 lines
2.4 KiB
Markdown
40 lines
2.4 KiB
Markdown
# SiteLink
|
|
|
|
**Linking multiple VWE Pod Bays together to play games across the internet.**
|
|
|
|
A Pod Bay today is an air-gapped network of ~20 computers: 1 command console, 1 printer,
|
|
2 review stations (Live Cam & Mission Review), and 16 cockpit computers. SiteLink is the
|
|
project to connect those islands — so a bay in one city can field a lance against a bay in
|
|
another, share a queue, share voice, and (eventually) be commanded as one fleet.
|
|
|
|
## Seed concept (2026-07-10)
|
|
|
|
> Organize each site into its own `10.0.y.x` subnet (site 1 = `10.0.1.x`, site 2 =
|
|
> `10.0.2.x`, …), VPN them all together into a single `10.0.0.0/16`, then collect every
|
|
> site's `.siteconfig` and merge them for a **master console** that can command the
|
|
> entire fleet.
|
|
|
|
That concept is the anchor of this repo. The analysis, alternatives, and open questions
|
|
live in the docs below.
|
|
|
|
## Contents
|
|
|
|
| File | What it is |
|
|
|------|-----------|
|
|
| [docs/PODBAY-ECOSYSTEM.md](docs/PODBAY-ECOSYSTEM.md) | Survey of the existing bay software stack — every component, every protocol/port, with source pointers into the sibling repos. The ground truth SiteLink has to work with. |
|
|
| [docs/BRAINSTORM.md](docs/BRAINSTORM.md) | The design record: goals, the seed proposal analyzed, addressing plan, VPN topology options (routed vs bridged), master-console vs federation, per-game linking analysis, shared services, security, open questions, and a phased roadmap. |
|
|
|
|
## Related repositories (gitea.mysticmachines.com/VWE)
|
|
|
|
| Repo | Role |
|
|
|------|------|
|
|
| `TeslaSuite` | TeslaConsole (operator console), TeslaLauncher (pod service), the Console↔Pod RPC contract, SecureConfig provisioning, and **vPOD** (virtual pod — our cross-site test double). |
|
|
| `firestorm` | BattleTech: Firestorm — the MW4/Gameleap-engine game the 16 cockpits run. DirectPlay 4 multiplayer. Contains the drafted 16→32 player-cap plan that a two-bay link needs. |
|
|
| `RP411` | Red Planet (MUNGA engine, Win32/DX9 port). Console-controlled via Munga protocol, TCP 1501. |
|
|
| `BT411` | Classic arcade BattleTech (Tesla 4.10) reconstruction on the RP411 engine. Console streams the mission egg over TCP; pods mesh with each other. |
|
|
| (local `PQS/`) | Pod Queue System — PHP/MySQL front-of-house: registration, callsigns, queue, and the HTTP endpoints the game/console poll for the next mission + roster. |
|
|
|
|
## Status
|
|
|
|
Brainstorm / design phase. Nothing here touches a live bay yet.
|