App store: the design you're describing already exists in pieces What you're sketching is essentially an Alpine-style APKINDEX meets BitTorrent meets Tor — a content-addressed package repo with transport-agnostic delivery. Here's how I'd structure it: The authoritative server (store.agelesslinux.org) hosts three things: a signed catalog.json (package index with metadata, versions, SHA256 hashes, parental advisory tags), a GPG/ed25519 public key for verification, and .tar.gz packages available over HTTPS. This is the "seed" — it's what boots the network.
Transport layers, in order of complexity to implement:
HTTPS (day one): wget from the authoritative server. Works now. BitTorrent (week one): Each package gets a .torrent file hosted alongside it. Devices that download packages seed them. transmission-cli is ~2MB on Debian. The torrent tracker can be the authoritative server or a well-known public tracker. Local peer discovery (week two): mDNS/Avahi + a simple HTTP server on each device. Devices on the same WiFi network advertise what packages they have. ageless-store checks local peers before hitting the internet. This is the STEM fair scenario — one device downloads over cellular hotspot, fifty devices get it over local WiFi. Tor (week three): An .onion mirror of the authoritative server. Small Python packages over Tor is totally viable — latency doesn't matter when the payload is 4KB. tor + torsocks are packaged for Debian RISC-V. LoRa (stretch): Meshtastic or custom protocol for package gossip between devices that have no internet at all. Realistic only for very small packages or catalog updates, not full package transfer — LoRa bandwidth is measured in bytes/second.
The signature chain is the critical piece: the device trusts FFwF's signing key. It verifies every package regardless of where the bits came from. HTTP, torrent peer, local WiFi neighbor, .onion service, LoRa relay — doesn't matter. If the signature checks out, the package is authentic.
Ageless Linux as a spec This is the right move, and it's where the three pieces converge. The spec becomes:
Must run Linux (kernel, not "Linux-like"). uname -s returns Linux. Must have a user account created without age data. whoami returns a name. Must be able to reach the Ageless Store via at least one supported transport. Must verify package signatures against the FFwF signing key. Must display parental advisory metadata when present. Must not provide any age verification API, signal, or data.
example app metadata:
{
"name": "chat-client",
"advisory": {
"network": true,
"stranger-interaction": true,
"user-generated-content": true,
"humor-crude": false,
"system-access": false
},
"disclaimer": "This app lets you chat with people on the internet. If you're a kid: ask an adult before chatting online. That's not a legal requirement. It's just good advice."
}
the key element is that all apps are available to any device, and users configure for themselves what they want to see. we're describing what software does. This is the equivalent of a restaurant menu saying "contains peanuts." At no point would we consider it appropriate for resturaunts to require "allergy brackets" from every user.
What a parent can do (without age data) The device is a Linux computer. The parent has root. They can:
- Uninstall any app (
rm -rf ~/apps/chat-client) - Set a root password so the child can't reinstall it
- Block network access entirely (nmcli wifi off)
- Put the device in a drawer
None of these actions involve the device knowing the child's age. None of them involve an API. They're the same thing a parent does with any computer: decide what's appropriate for their child, based on their judgment, using their authority. This is parenting. It predates AB 1043 by several millennia.