--- name: free-firebase-ideas description: "What the FREE Firebase tier can do (Firestore + Auth, client-side only, NO Cloud Functions). Ideation the owner reviewed and folded in — plus the standing NO-SERVER verdict and its reasoning." metadata: node_type: memory originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- Owner asked 2026-07-08 what else the FREE Firebase tier could do; floated (a) syncing device settings to the account (cross-device, not per-device) and (b) a "save to cloud" button. **Ideation only — don't implement until the owner picks.** **HARD CONSTRAINTS (these are the durable part):** free tier ONLY ([[project-must-stay-free]] — no Blaze, no Cloud Functions, no server) · everything CLIENT-SIDE (Firestore + Auth) · **the manual-sync rule stays — auto-push-to-cloud is a PROHIBITED pattern, cloud sync is a manual button only** · writes stay additive · security rules must hold · **NO PII synced.** ⚠ **Before building any of this, check what already exists in the source.** *Incident worth remembering: the owner asked for a "save to cloud button" that already existed — he simply hadn't found it. The real gap was DISCOVERABILITY, not capability, and the fix was a mobile-prominence task rather than a feature.* Assume the same may be true of anything below. ## GOOD IDEAS (owner reviewed) 1. **★ Cross-device SETTINGS/PREFERENCES sync** (owner's idea, and Dispatch's standout pick) — sync the device-prefs (immersion tier, audio mutes, high-lumen, input mode, optics…) to a per-user Firestore doc so they follow across devices. Free-tier trivial: small doc, infrequent writes. **NUANCE: some prefs are genuinely device-specific** (wake-lock/haptics support, maybe per-game optics) — sync the *user-preference* ones, keep truly-device-specific ones local, or offer a "this device overrides" option. Conflict resolution = last-write-wins (simplest). **LOW risk, good value.** 2. **Surface the existing cloud-save button** — make SAVE TO CLOUD as prominent as the file export, **especially on mobile.** Small UX task. 3. **Distribution Network content delivery** ([[robco-os-architecture]]) — deliver content / updates / seasonal broadcasts / data cartridges via read-only Firestore docs. Free, no server; App-Check + kill-switch gated. 4. **Shareable read-only campaign snapshot** — "transmit your terminal record": publish a snapshot others view via a shareable ID. Community/fun, on-theme. **CAVEAT: needs careful public-read rules, NO PII, and owner opt-in per share.** 5. **Account profile** — display name / operator callsign (minor polish). 6. **In-app feedback / bug report → cloud** — write to a restricted, owner-read-only collection; optionally attach the diagnostic bundle. Useful for a solo dev. **Careful write-rules.** 7. **Cross-campaign Operator Record** — an account-level ledger persisting BEYOND any single save (total playtime, campaigns run, milestones, cross-device boot count). On-theme: the "Terminal Record" as operator meta-progression. 8. **Preset / loadout / MACRO library** — user-defined builds, loadouts and macros stored to the account, reusable across campaigns and devices. 9. **★ Real-time CO-OP campaign** — owner-flagged *"really cool, thoroughly consider."* Use case: **owner + his brother both editing ONE shared campaign live** (brother plays and edits, owner watches and edits). **NEEDS A THOROUGH PLANNING PASS BEFORE BUILD.** 10. **Continue-on-another-device** — a "last active campaign" pointer offering resume-where-you-left-off. 11. **Dated/seasonal broadcasts** — the client checks a timestamp in a doc so content "unlocks" on a date, **no server scheduler needed.** **Placement:** these group as a cloud/account cluster alongside the Distribution Network and account subsystems in the OS round. **`QUEUE.md` is authoritative for where they actually sit** — confirm placement there rather than trusting this file. ## ⭐ DISTRIBUTION NETWORK vs THE CURRENT UPDATE PATH — verdict (owner asked to compare, 2026-07-08) They are **COMPLEMENTARY, doing different jobs — the network does NOT replace the deploy path.** Git → static deploy + service-worker cache bump + "REBOOT TERMINAL" prompt is **how the APP/CODE updates**: offline-first, versioned, no per-fetch cost. **KEEP IT — it is better for app deploys.** The Distribution Network is **how LIVE/DYNAMIC content arrives WITHOUT a redeploy** (seasonal broadcasts, intercepts, data cartridges, announcements). Neither is strictly better; **the network's value scales with how much live content the owner actually wants to push.** If he wants little, it is low priority. ⚠ **The free/offline invariant MUST hold: content ships offline and local by DEFAULT; the network is the OPTIONAL live channel** (last-known-good + kill-switch + App Check). ## ⭐ THE SERVER QUESTION — VERDICT: NO SERVER (owner asked 2026-07-08, *"or should we swap to a server… has to be free"*) **Stay on free client-side Firestore.** **KEY FACT that decides it:** real-time co-op is **ALREADY achievable on FREE Firestore via real-time listeners** — two clients open the same shared campaign doc and live-sync both ways, **no Cloud Functions.** Access = a shared "editors" array in the doc plus security rules; read-only "watch" = a listener without write. **The HARD part is CONFLICT HANDLING**, not infrastructure: both editing the same field means last-write-wins can lose an update — mitigate with field-level writes and optionally per-field timestamps or transactions. And a shared live co-op doc is **intentionally mutable**, scoped to its editors — genuinely different from the additive per-user saves, so reconcile it with the cloud-write-safety rule explicitly rather than by assumption. **WHY NOT A SERVER:** for two TRUSTED users tracking a campaign there is **no need for server-authoritative validation or anti-cheat**. A server adds **cost-creep risk (free tiers change and expire — violates the spirit of [[project-must-stay-free]])**, maintenance, and a new failure mode, and it **breaks the clean offline-first-PWA + client-Firestore model.** **Only revisit if a future feature genuinely needs server authority** — secure secret proxying, scheduled cron jobs, moderation, server-trusted validation. Free options if that day comes (noted, not chosen): Cloudflare Workers, Supabase, Deno Deploy. **Firebase Cloud Functions require the paid tier, which the owner treats as off-limits.** **BOTTOM LINE: co-op and everything planned is doable free and client-side. Don't swap.** ## REJECTED / OFF-TABLE - **Push notifications (FCM)** — discarded earlier ([[docked-ideas]]). - **Auto-sync** — prohibited; manual only. - **Anything needing Cloud Functions or a server** — paid. - **Leaderboards / telemetry** — doesn't fit a single-player tracker; write cost plus privacy. - **A community content pool** — owner declined explicitly.