install.sh downloads 284MB of unneeded data during installation

[vpzed]

What was expected: The installer would download only the latest version of the LifeOS files needed for installation.
What happened: The installer downloaded a tarball that included every PAI/LifeOS release back to v2.3 which led to an ~289MB download instead of what could have been ~4.3MB.

User Impact: Slower installation time, and extra data usage on metered connections such as cellular hotspots.

How to reproduce: Manually download the release tarball and inspect the contents.

wget https://ourlifeos.ai/install.sh
DRY_RUN=1 bash install.sh

Manually download the release tarball provided in the "Fetching LifeOS .." section, and untar it to inspect.

$ du -h v7.0.0.tar.gz 
289M	v7.0.0.tar.gz

$ du -hs *
50M	images
4.0K	LICENSE
18M	LifeOS
16K	README.md
329M	Releases
8.0K	SECURITY.md
76K	Tools

$ tar cfz LifeOS.tar.gz LifeOS

$ du -h LifeOS.tar.gz
4.3M	LifeOS.tar.gz

[danielmiessler]

Thanks @vpzed — this is a real finding, and a well-documented one. You're right about the mechanism: the installer fetches GitHub's auto-generated full-repo source tarball and then keeps only the LifeOS/ skill directory, so you pay for the whole repo to install a fraction of it.

We looked into it carefully. Current numbers: the historical Releases/ directory that drove your 289MB has since been cleaned, but a fresh install still pulls ~59MB to extract ~6MB, so the waste you flagged is real and ongoing.

The clean fix is more involved than it first looks. It isn't just "point the installer at a smaller file" — the installer's extraction logic assumes GitHub's <repo>-<tag>/LifeOS/ two-level nesting, so a hand-rolled slim tarball with different nesting would break extraction (we verified this). Doing it properly means making the extraction tarball-shape-agnostic, having the release build and publish a slim asset with a gate that it actually exists, and logging which path the installer used so a fallback can't silently mask a regression. That's a three-part change that touches the release pipeline, and it only takes effect on a future release.

Given that it's a download-size cost on metered connections rather than a correctness bug, we're going to hold it for now and fold it into a future release cycle when the pipeline work is a natural fit, rather than rush it. Closing for now with that intent — genuinely appreciate you measuring it out and writing it up so clearly; that made the analysis easy.

[vpzed]

I repeated my test and confirmed results, this time with v7.1.1.tar.gz. Going from 289MB to 59MB is a significant improvement.