In the firebase case the notification_token is a separate token that identifies the channel to the device. We could implement the same abstraction I suppose:

• The device registers with a separate "client_id" as notification token.
• We use the client_id that is stored in the notification token instead of the device_id.

There's currently a 1:1 mapping between notification tokens and deviceid, so it doesn't buy us anything atm, but may provide more flexibility in the future?

I don't think there is a way to reliably detect dropped connections without sending some data (there's tcp keepalive, which sends data, but I'm not sure we can rely on that here).

If we want to guarantee delivery of notifications there needs to be a protocol for acknowledgement from the client and retransmission otherwise.

We can get the user from the guard, but if we want device/client specific notifications I think we need an id (The companion app code uses device_id rather than client_id, and until we have multiple clients on the same device they are probably going to be the same). I don't think we initially have device specific notifications, but one could foresee the need based different purposes.

I suppose we could map this to oauth scopes, but then again, we already have the companion app entry with some config, so I suggest to leave the id in there.