Space Net

\section*{Inspiration} We envision a future where data centers on Earth and in space work together as one connected network. That future raises a practical question: how do you decide where to run a compute job when part of your infrastructure is constantly moving?

On Earth, we often assume a network connection will be available when we need it. In orbit, connectivity depends on satellite positions and communication windows. A cheaper data center might miss your deadline because your data has to wait for the next connection.

We built \textbf{Space Net} to explore how computing could work across that network.

\section*{What it does} Space Net is a planner and simulator for compute jobs across Earth and orbital data centers. It considers compute costs, data transfer costs, and deadlines to choose where a job should run and how its data should travel.

An interactive globe lets users watch satellites move and follow planned data transfers. Users can submit image-processing jobs, compare the planner's decisions with a cheapest-node baseline, and introduce disruptions to see how plans respond.

Multiple users can share the same network, with reservations that prevent them from double-booking communication windows.

\section*{How we built it} We built the dashboard with \textbf{React, TypeScript, and Three.js}, backed by a \textbf{Python and FastAPI} service. \textbf{SGP4} calculates satellite positions from public orbital data, which we use to derive communication windows.

Our planner schedules computation and data transfers around those windows. A real image-resizing worker executes the processing workload, while the simulation models network transfers and orbital compute resources. \textbf{SQLite} stores jobs and reservations, and \textbf{WebSockets} deliver live updates to the dashboard.

We also integrated \textbf{Grok and xAI Voice} so users can ask about plans and interact with the simulation through text or voice.

\section*{Challenges we faced} The hardest challenge was connecting orbital motion with scheduling. Finding an inexpensive compute node is only part of the problem. The input data must reach it, and the results must return before the deadline.

Sharing the network added another layer of complexity. A communication window that works for one job might already belong to another user. We built reservation checks to keep those decisions consistent.

We also had to connect a simulation clock, live dashboard updates, and real processing workers while keeping results reproducible and clearly distinguishing real orbital data from simulated infrastructure.

\section*{What we learned} We learned that \textbf{cheap compute does not always mean a cheap, successful job}. Connectivity and timing can change which option makes sense.

We also learned how much shared infrastructure changes scheduling. A plan has to account for both the physical network and the resources other users have reserved.

\section*{What's next} We want to explore larger orbital networks, more workload types, and richer models of power, thermal limits, and communication capacity. Our goal is to keep developing Space Net as a way to test how computing across Earth and space could work.

\section*{Built with} Python, FastAPI, React, TypeScript, Three.js, Vite, SQLite, WebSockets, SGP4, Grok, xAI.

\end{document}