Push Notifications

[RyanTG]

An idea for the future:

An option to enable push notifications for nearby added machines.

Should I either be for nearby locations, or for Saved locations. I think Saved is the better option.

[RyanTG]

https://docs.expo.io/versions/latest/guides/push-notifications/

https://levelup.gitconnected.com/react-native-adding-push-notifications-to-your-app-with-expo-8e4b659ddbfb

That's just from a quick search. I haven't read them.

[RyanTG]

I think:

• Push notifications for machines added to your favorited locations
• Some limit on them, so that if someone adds, say, 10 machines to a place, you don't get 10 notifications. Not sure if that's possible.
• The notification says, "Pinball Map Update: xx machine was added to yy"
• And when you click it the app opens to the location details of that place.

[mikedg1]

For reference, an RFC for this feature. Comments are open to anyone with a Notion account.
https://www.notion.so/RFC-Push-Notifications-1b091bec82e6806a8b18ca7e16ea6681

[RyanTG]

Status: I'm not very interested in this feature. It would add cost/dependencies that might be tough to manage. Plus I personally don't like push notifications.

I will summarize some things here. First off, I think the two use cases are "locations in my Saved list had a machine added" and "Machine that I set an alert for (not something we support right now) has been added near me".

I then asked claude wtf is involved in managing push notifications. Here is some of it:

Here's a clear breakdown of what push notifications would actually require for this app.
    
  Architecture Overview
    
  The flow has three layers: client (Expo app), your server (Rails), and notification gateways (Apple/Google).
    
  User's device ←→ APNs (Apple) / FCM (Google)
                         ↑
                Your Rails server
                         ↑
             Expo Push API (optional proxy)
    
  What the App Needs to Do
    
  Relatively small lift:
  1. Request notification permission from the user at an appropriate moment
  2. Get a push token (a unique address for that device)
  3. Send that token to your server when the user logs in / token refreshes
  4. Handle displaying incoming notifications (mostly automatic)
    
  Expo provides expo-notifications which handles the iOS/Android differences. You'd store the token server-side associated with the user's account.
    
  Where the Bulk of the Work Lives
    
  Yes — the server. The app changes are minor. The server needs to:
    
  1. New DB column/table: store one or more push tokens per user (users can have multiple devices)
  2. Token lifecycle: tokens expire or change when users reinstall; you need to handle failed sends by purging stale tokens
  3. Hook into new_lmx creation: after a machine is added, find all users who have that location saved
  4. Batching logic: this is the hard part — a background job (Sidekiq) that collects events within a time window (say, 15 minutes) before firing a single summarized notification
  5. Opt-out management: users need a way to turn this off per-location or globally
  6. Actually sending: POST to Expo's Push API (simplest) or directly to APNs/FCM
    
  The batching job is where your "accidentally sending too many" concern is real. Without it, a bulk import of 10 machines at one location would fire 10 separate notifications per saved
  user.
    
  Costs

  - APNs (Apple) and FCM (Google): free
  - Expo Push API: free — Expo proxies to APNs/FCM at no charge; this is the easiest path
  - Real cost: Sidekiq or equivalent background job infrastructure on your server, which you may already have

  If you go directly to APNs/FCM without Expo's proxy, you'd need to manage Apple developer certificates and Google service accounts separately — more setup, no cost savings.

  The Batching Problem in Detail

  The safest pattern for your use case:

  - When a new_lmx is created, enqueue a delayed job (fire in 30 min)
  - Before sending, query all new_lmx events at that location in the last 30 min
  - Send one notification: "3 machines added to Silverball Retrocade: Medieval Madness, The Addams Family, and 1 more"
  - If someone adds machines to 5 of a user's saved locations in that window, they still get 5 notifications — so you might want a daily digest option too

  My Take on Sequencing

  The server work (batching, token management, opt-outs) is what requires careful design. The app changes are ~1-2 days of work. The server-side is probably 1-2 weeks if done carefully. The
   risk of under-designing the batching/opt-out logic is exactly the "spam users" scenario you're worried about.

  If you want to move forward, the safest first step is adding push token storage to the server and the permission/registration flow in the app — without sending any notifications yet — so
  you're building the infrastructure before committing to a delivery strategy.