Should we add telemetry?

[MFelida]

At minimum it would help sysadmins gauge demand for apps.

[CheapFuck]

A few thoughts / questions to help scope this, since "telemetry" can mean very different things:

What signal is actually wanted?
If the goal is "gauge demand for apps" (which packages people install/export), that's a much narrower dataset than general usage telemetry — basically towel install <pkg> / towel export <pkg> events. Worth deciding up front whether you want:

• package popularity (install/export counts), vs
• feature usage (which subcommands), vs
• environment/version stats (for support).

Privacy / consent (Codam is in the EU):
Anything that leaves the machine should be opt-in, anonymous, and documented, given GDPR. An opt-out-by-default model on student machines is likely a non-starter. A clear towel telemetry --enable/--disable plus a first-run notice would be the safe baseline.

Lightweight alternatives before building a service:

• If the sysadmins control the install base, package counts can often be derived server-side from the package mirror / proxy logs without any client telemetry at all.
• Or a purely local counter (~/.local/share/towel/stats) the user can voluntarily share — no network, no consent machinery.

Questions:

1. Who consumes the data and what decision does it drive? (Just app demand, or more?)
2. Is a server endpoint in scope, or would aggregating from existing infra (mirror logs) suffice?
3. Opt-in vs opt-out expectation on student machines?

Happy to prototype the opt-in toggle + local-counter approach (no network) as a first step if that direction sounds right — it'd be useful on its own and keeps the consent surface small.