Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Epic: Cislunar economy: a widgets-drawer app for the Earth–Moon logistics network, as a basis for routing and operations research

Open
#273 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
bun, javascript
Domain
data, full-stack

Research direction

Start with #272 and the widgets drawer and dock section of DESIGN.md, then read ui/apps.jsx and the existing Human Expansion app for the app entry point. The issue describes a multi-phase network model, solver, scene drawing, panel, URL state, and documentation; its first phase can start with the points from #272 and schematic arcs. Done means the app supports the stated route query and flow scenario, cites its data sources, and restores a scenario from a permalink.

Written by the indexing model from the issue text.

Description

enhancement epic track:spacecraft

Track F (spacecraft and missions). #272 first: its points and regimes are this network's nodes.

What

An app in the widgets drawer, alongside Human Expansion (ui/apps.jsx; DESIGN.md widgets drawer and dock). It models the cislunar economy described in this explainer video (chapters 5, "The cislunar economy", and 6, "Security and future strategy"; transcript excerpts in #272). It draws that economy's network in the scene and gives it a structure an operations-research model can run on: nodes, lanes, costs, flows and windows, editable, solvable and exportable.

Like Human Expansion, it is a what-if model, labelled as one: a scenario, not a forecast.

Why

The video's argument is about logistics. Gravity structures the efficient routes, and the Moon's shallow gravity well makes it far cheaper to move mass from the Moon than from Earth (escape velocity ~2.4 km/s against ~11.2 km/s: about 22× less energy per kg). Celestiary already places the Earth, the Moon and (with #272) the Lagrange points and orbital regimes in true 3D over time. That makes it a good place to see such a network, and to hand its structure to a solver.

The model (from the video)

Nodes (from #272's points and regimes): Earth's surface (launch sites), LEO, GEO, Earth–Moon L1, L2, L4, L5, the Gateway NRHO, low lunar orbit, the lunar surface (bases, mass-driver sites), Sun–Earth L1/L2, and near-Earth asteroids that are cheap to reach in Δv (some cheaper than the lunar surface), with captured asteroids as a later node type.

Named lanes, the video's celestial lines of communication (CLOCs):

  • Apollo CLOC: Earth ↔ LEO ↔ lunar surface. People and equipment out; propellant and construction materials back to LEO; small quantities of high-value minerals all the way to Earth.
  • Mass driver (lunar catapult): lunar surface → L2, with no propellant (electrical energy instead).
  • L2 processing → GEO: refined material for space data centres and solar power satellites.
  • Glaser CLOC: lunar surface → GEO directly, for solar power satellites.
  • O'Neill CLOCs: L2 → Earth–Moon L5 → L4, for the raw materials of orbital settlements.

Commodities and demand: people, equipment, raw regolith, processed material, propellant, construction material, high-value minerals. Demand nodes: GEO (data centres, SSPS), LEO (stations, manufacturing), L4/L5 (settlements), Earth.

Security layer (chapter 6): space-domain-awareness sensors at the Lagrange points and in cycler orbits, which detect and track the lanes' traffic. Rescue, medevac and fast-response vehicles staged in cyclers, with a response-time reach.

Scope, in phases

1. The Δv network, drawn and queryable
  • Nodes and directed edges. Each edge has its Δv, transfer time and propulsion mode (chemical, mass driver, SEP, aerobraking or aerocapture). Edges are directed because aerobraking makes the way down to Earth cheaper than the way up. Seed the numbers from published Δv maps and cite each edge's source in the data file; never invent values.
  • Lanes drawn in the scene with wideLines.js, on the overlay layer (through sceneReferred()). At first schematic arcs between the nodes' real positions; later real trajectories (#11). The gravity-well depth of each node is shown in the panel.
  • Route query: the cheapest path between two nodes. The cost is propellant mass for a payload through the rocket equation, with an Isp per stage, so path cost is multiplicative in mass ratio, not a sum of Δv. Also fewest Δv, shortest time.
2. Flows: a min-cost flow scenario
  • A scenario editor: supply at sources (lunar mine rate, Earth launch rate), demand at sinks (tonnes a year at GEO, LEO, L5…), capacities (mass-driver throughput, processing at L2) and cost per kg per edge.
  • Solved in the app for small networks (successive shortest paths or network simplex, a few hundred lines of pure, tested JS like Colonization.js). Draw the result as lanes whose width scales with tonnage, with animated packets.
  • Export/import as JSON: a documented schema (nodes, edges, commodities, scenario) so the same network can be solved in an external OR tool (an LP/MIP solver, a notebook) and the solution loaded back to be drawn.
3. Time
  • Launch windows and periodicity: transfer opportunities to L-point orbits, NRHO phasing, cycler encounters. Build a time-expanded network from the edges' windows and transit times.
  • Play/scrub the flows over simulation time, on the app's own timeline as Human Expansion does, tied to c.time.
4. Security and coverage
  • Sensor placement as a covering problem: which lanes and volumes a set of sensors at L1/L2/L4/L5 and in cyclers can see, and the gaps.
  • Response reach: from a staging orbit, which points on the network a rescue vehicle can reach within a time limit and a Δv budget.
Later
  • The same model at Mars (Phobos and Deimos as depots, areostationary relays), reusing #272's points at every pair.

Plumbing

  • apps.cislunar: state token for the running app's scenario and view (design/URLs.md, js/store/appTokens.js), so a link restores a scenario.
  • Pure model in js/scene/cislunar/ (graph, costs, solver; unit-tested in bun), drawing in its own lines module, panel in js/ui/CislunarApp.jsx, and a doc (js/scene/Cislunar.md, after Colonization.md) that records the sources of every number.
  • Loaded only when the app opens (DESIGN.md what loads when); nothing in the first load.

Done when

  • The app opens from the drawer, draws the video's nodes and named CLOCs in the Earth–Moon system at the right places over time, and answers a cheapest-route query with the propellant mass and the path.
  • A min-cost flow scenario (e.g. N t/yr of lunar material to GEO and to L5) solves in the app and draws its flows, and round-trips through the JSON export.
  • Every Δv and capacity has a cited source in the data file or the doc; the panel says the model is a scenario, and credits the video.
  • A permalink restores the app with its scenario.

Children

Phases 1–4 above, each filed as a sub-issue when it's picked up.

  • Phase 1: the Δv network and route query
  • Phase 2: min-cost flows and the JSON export
  • Phase 3: windows and the time-expanded network
  • Phase 4: sensor coverage and response reach

Depends on

  • #272: the Lagrange points, orbital regimes and halo/NRHO/DRO orbits are the nodes. Phase 1 can begin with the points alone.
  • #11 for real trajectories along the lanes (phase 1 can use schematic arcs); #30 for near-Earth asteroids as nodes; #50 for real traffic in LEO/GEO.
Dominant language
JavaScript
Stars
55
Forks
4
Avg merge
9h 32m
Merged PRs (30d)
136

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from celestiary/web

All issues in celestiary/web

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.