Secure, resilient resubscription for push notifications in service workers - meteor

Question

I am attempting to implement a service worker that performs push notifications for a web app. I'd like for the system to be resilient in that it keeps sending push notifications without the user needing to regularly interact with the app. To that end, I'm eyeing the pushsubscriptionchange event, but am not sure how to work within the service worker's limited constraints.
Method 1: post back to my app
My current code captures this event, creates a new subscription and sends it back to the client via postMessage. The client then calls my back-end and registers the new subscription endpoint.
This seems like the most elegant way, except I assume it would require an open tab. If the user doesn't check in for a few days but is still interested in getting push notifications, the existing subscription would eventually time out, and there would be no way to notify the app about the newly-acquired endpoint.
Method 2: securely call a REST endpoint
I then had the idea to add a REST endpoint to my app that accepts an updated subscription. One complication is that the app uses Meteor, so there's a substantial bit of its own infrastructure (the DDP protocol, for instance) that service workers don't have access to.
My thought was to generate a UUID as a token whenever a new subscription is added. Service workers could then fetch an endpoint passing this token as a query parameter and sending a new endpoint/key. A new token is then created, the old one deleted, and the new push endpoint is registered.
Unfortunately, I'm not sure how to store the token in a way that the clients and service workers could share. Local storage isn't available to service workers. The cache API seems targeted at actual requests, not at simple key/values. IndexDB is available to service workers, but I literally just want to store a UUID keyed off of something like "pushEndpointToken". Do I really have no other option than opening a database and declaring a schema for this single key/value?
Is there some third method I'm not considering? I just want to ensure that my app always has a valid push endpoint for as long as the user wants to receive notifications from it.
Thanks.

Answer 1

Update
Runtime variables are lost when service worker is stopped and woken up later. You need to use persistent storage such as IndexedDB or cookies (to append token to requests).
I can recommend idb-keyval - I'm sharing one database with between app (write) and service worker (read).
old answer:
You can use PostMessage API to send token into service worker
This is a concept, I'm still working on it
service-worker.js:
const runtimeVars = {
token: undefined,
}
self.addEventListener('message', event => {
// Probably no need for this check
if (event.origin !== self.origin) {
return
}
if (event.data.token) {
runtimeVars.token = event.data.token
}
})
self.addEventListener('pushsubscriptionchange', event => {
// Fire unregister request with runtimeVars.token
})
app.js
const controller = window.navigator.serviceWorker.controller
if (controller)
// At app dispatch
controller.postMessage({token: localStorage.getItem('token'})
// After login pass API token to service worker
controller.postMessage({token})
// After logout, nullify token
controller.postMessage({token: undefined})
}