diff --git a/web-push.md b/web-push.md
new file mode 100644
index 0000000..1a68c19
--- /dev/null
+++ b/web-push.md
@@ -0,0 +1,70 @@
+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.