Web Push notifications is a web browser messaging protocol defined by the W3C.

Discussions of this interesting technology are clouded because of a terminological
morass.

To understand how Web Push operates, we need to observe that are three (and
potentially four) parties involved. These are:

1) The user's web browser. Let's call that BROWSER
2) The Web Push Service Provider which is operated by the organization controlling the
web browser's source code. Here named PROVIDER. An example of a PROVIDER is
FCM (Firebase Cloud Messaging) which is owned by Google.
3) The Web Application that a user is visiting from their web browser. Let's call this the
SERVICE (short for Web Push application service)
[4) A Custom Web Push Intermediary Service, either third party or self-hosted. Called
INTERMEDIARY here.]

The workflow works like this:

BROWSER visits a website which has a SERVICE.

The SERVICE asks BROWSER for its permission to subscribe to messages coming
from the SERVICE.

The BROWSER receives a data structure from SERVICE called a VAPID (Voluntary
Application Server Identification).

The VAPID is a specification used to identify the application server (i.e. the SERVICE
server) that is sending push messages to a push service. It's an authentication
mechanism that allows the server to demonstrate its identity to the push service, by use
of a public and private key pair. These keys are used by the SERVICE in encrypting
messages being sent to the BROWSER, as well as being used by the BROWSER in
decrypting the messages coming from the SERVICE.

If the BROWSER accepts and grants permission to subscribe to receiving from the
SERVICE Web Push messages, then the BROWSER makes a subscription request to
PROVIDER which creates and stores a special URL for that BROWSER. The
PROVIDER sends this URL back to the BROWSER. The BROWSER will then use that
URL to check for incoming messages by way of a special software named a "service
worker". The BROWSER also sends this URL back to SERVICE which will use that
URL to send messages to the BROWSER via the PROVIDER.

Ultimately, the actual process of receiving messages varies from BROWSER to
BROWSER. Approaches vary from long-polling HTTP connections to WebSockets. A
lot of handwaving and voodoo magic. The bottom line is that the BROWSER itself
manages the connection to the PROVIDER whilst the SERVICE must send messages
via the PROVIDER so that they reach the BROWSER.

Now to address the issue of receiving notification messages on mobile devices.
It should be noted that Web Push messages are only received when BROWSER is
open, except in the cases of Chrome and Firefox mobile BROWSERS. In iOS the
mobile application (in our case a PWA) must be added to the Home Screen and
permissions must be explicitly granted that allow the application to receive push
notifications. Further, with an iOS device the user must enable wake on notification to
have their device light-up when it receives a notification (https://support.apple.com/enus/HT208081).
So what about #4? - The INTERMEDIARY. Well, It is possible under very special
circumstances to create your own Web Push PROVIDER. The only case I've found so
far relates to making an Android Custom ROM. (An Android Custom ROM is a
customized version of the Android Operating System.) There are open source
IMTERMEDIARY products such as UnifiedPush (https://unifiedpush.org/) which can
fulfill this role. If you are using iOS you are not permitted to make or use your own
custom Web Push PROVIDER. Apple will never allow anyone to do that. Apple has
none of its own.

It is, however, possible to have a sort of proxy working between your SERVICE and
FCM (or iOS). Services that mash up various Push notification services (like
OneSignal) can perform in the role of such proxies.

#4 -The INTERMEDIARY- doesn't appear to be anything we should be spending our
time on.