mirror of
https://github.com/lrnselfreliance/wrolpi.git
synced 2026-10-26 19:01:39 -04:00
Create your own off-grid library
https://wrolpi.org
91f92683ba
* Speed Test calculator: ping, download, and upload against the API Users asking whether the hotspot is fast enough, or how many people can stream video at once, had no objective tool that works offline. This adds one under Calculators > Tools & Reference. Backend (wrolpi/speedtest.py, /api/speedtest): * ping: tiny no-store JSON the browser times for round trip latency. * download: streams slices of a pre-built random buffer for a clamped number of seconds (0.1-15). Random so no proxy or compression can flatter the result; slices so no bytes are generated per request. * upload: streaming-body handler that reads and discards the body and reports bytes and elapsed time. Requests over 8 MiB are refused. * info: the client address Caddy forwarded plus how many tests are in flight. Sanic now trusts one proxy hop (PROXIES_COUNT = 1) so request.remote_addr is the browser, not Caddy. Nothing else read that field before. There is deliberately no one-test-at-a-time lock. Several people testing at once is how a user learns how the link shares between streamers, so the server only counts in-flight tests (a shared_ctx Value created pre-fork so every worker sees the same number) and the UI reports how many others ran alongside. Both Caddyfiles route /api/speedtest/* unbuffered, as the SSE chat route already is, so throughput is measured live rather than in bursts. Frontend: * speedtest.js holds the logic with no React in it (bucketed throughput, steady-state average that drops the first second, ping stats, stream-capacity tiers, hotspot address check) so Jest drives it with fake fetch and streams. * SpeedTestCalculator runs 20 pings, a 10 s download, and a 10 s upload with a live figure and rolling trace, then shows Mbps and MB/s, ping verdict, the client address with a hotspot badge, and a table of how many 480p..4K streams the download speed supports. Upload is sequential POSTs of one 4 MiB Blob because Safari cannot stream a request body. Nothing is saved. * Sparkline is a new inline-SVG ui component (no chart dependency), added to /theme-sample and checked in all four themes. A missing sample is a gap, not a plunge to zero. The page states that it measures the network path, not the drive that actually serves video files. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * speedtest: bound uploads in time, close the Start race, address review Review on #708 found three bugs and some polish: * Start could be clicked again while the first fetchInfo() was still pending, because the phase only left `idle` after that await. A second click made a second AbortController and a second concurrent run, and Cancel only reached the later one. start() now refuses when a controller already exists and enters a `starting` phase synchronously, so the button is Cancel before the first await. * The upload phase could overrun the advertised 10 s by however long the in-flight 4 MiB POST took: on a slow hotspot, the very link this tool exists for, that is tens of seconds. runUpload() now aborts the in-flight request at the phase deadline (counting only completed requests) and uses 1 MiB bodies so a few-Mbps link still completes several inside the phase. * The server upload sink was capped by size only, so a slow or paused body could hold a worker until 8 MiB eventually arrived. It now also enforces MAX_UPLOAD_SECONDS (15 s, matching download) and answers 408 when exceeded. Both caps together are what "cannot hold a worker" actually requires. Also: a NaN `seconds` now gets a NaN message instead of "must not be negative"; the module, Sparkline, and gallery docstrings are trimmed to purpose; and the upload counter is covered for the mid-stream 413, the 408, and a broken body. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|---|---|---|
| .circleci | ||
| .github | ||
| .run | ||
| alembic | ||
| app | ||
| controller | ||
| debian-live-config | ||
| docker | ||
| etc | ||
| modules | ||
| pi-gen | ||
| release | ||
| scripts | ||
| test | ||
| wrolpi | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| .gitpod.yml | ||
| .mcp.json.example | ||
| alembic.ini | ||
| conftest.py | ||
| demo_link.jpg | ||
| docker-compose.yml | ||
| help.sh | ||
| icon.ico | ||
| icon.png | ||
| INSTALL.md | ||
| install.sh | ||
| join_discord.png | ||
| LICENSE | ||
| main.py | ||
| pytest.ini | ||
| README.md | ||
| repair.sh | ||
| requirements.txt | ||
| test_all.sh | ||
| UPGRADE.md | ||
| upgrade.sh | ||
WROLPi
Create your own off-grid library.
WROLPi is a self-contained collection of software to help you survive the world Without Rule of Law.
WROLPi is intended to be run on a Raspberry Pi with an optional external drive attached. It serves up it's own Wi-Fi network so that any user with a laptop/tablet/phone can connect and use the library created by the maintainer.
Table of Contents
Features
- Videos
- Web Archives
- Maps
- Wikipedia
- File search
- eBooks (EPUB / PDFs)
- Wi-Fi Hotspot
- Universal search
- Food Inventory management
- One-Time pad generator, encrypter/decrypter
- Synchronizer/duplicator
- Food storage calculator
Module features matrix
| Module | View | Search | Download | Project |
|---|---|---|---|---|
| Videos | yes | yes | yes | yt-dlp |
| Web Archives | yes | yes | yes | Singlefile |
| Wikipedia | yes | yes | yes | Kiwix |
| eBooks | yes | yes | planned | EPUB/PDF |
| Map | yes | yes | yes | Protomaps |
| Podcasts/Audio | yes | planned | planned |
Demo
Download
Images are available at wrolpi.org
Try WROLPi!
You can try out WROLPi by running the docker containers.
- Install docker-ce and docker-compose
- Copy the latest WROLPi code.
git clone https://github.com/lrnselfreliance/wrolpi.git
- Change directory into the code base.
cd wrolpi
- Initialize git submodules
git submodule update --init
- Build the containers.
docker-compose build --parallel
- Create volumes.
docker volume create --name=openstreetmap-datadocker volume create --name=openstreetmap-rendered-tiles
- Initialize the database (SQLite in the media directory).
docker-compose run --rm api db upgrade
- Start the docker containers.
docker-compose up
- Browse to WROLPi.
More Docker documentation is available in docker/README.md
Install WROLPi
Full installation instructions are in INSTALL.md. Pick the option that matches your hardware:
- WROLPi Portable (Live USB) — boot a complete WROLPi from a USB stick on any x86 PC or laptop. Nothing is installed to the computer; the first boot creates a persistence partition on the USB so your library, database, and configuration survive reboots.
- Debian 12 — install WROLPi onto an x86 PC or laptop.
- Raspberry Pi — install WROLPi onto a Raspberry Pi with an external drive.
- Docker — run the WROLPi containers on an existing Linux host.
Charter
Guiding Principals
- Storage is cheaper than power.
- Two is one, one is none.
- Run silently.
- Primary, secondary, tertiary.
- Secure as a bookshelf in your home.
Physical properties
- A WROLPi instance should be capable of running with a minimal of hardware:
- Raspberry Pi
- SD card
- External USB hard drive
- Power supply and cables
- Wi-Fi USER device such as a phone, tablet, or laptop.
- A WROLPi instance should consume a minimal amount of electricity during WROL event. It is expected power will be scarce when WROLPi is needed most.
User expectations
- A WROLPi instance should be run and maintained by a person (MAINTAINER) with a moderate amount of Linux and Raspberry Pi experience. It is expected that they should be able to do this using only the documentation on their WROLPi.
Software properties and capabilities
- A WROLPi instance should be able to "factory-reset" itself without any outside services.
- WROLPi should function completely without any internet services.
- A user should have easy access to their data if WROLPi fails:
- For example, a user can watch their videos by navigating a short and intuitive directory structure and opening the video in their preferred video player.
- WROLPi should be self-documented. The UI should contain a tutorial for USERS as well as the MAINTAINER.
- If the UI isn't functional, the code should be documented such that a user can restore functionality.
- WROLPi should favor pre-processing, rather than processing during a WROL event. Such as re-encoding a video, or processing captions. This is to ensure that when a user adds content during non-WROL time, the processing for optimum performance is already done for a WROL event.
Join!
