Web Push escapó de los silos de las tiendas de aplicaciones al estandarizar la identidad del remitente

Web Push funcionaba en Chrome desde sus inicios, pero la ruta del backend seguía pasando por Firebase Cloud Messaging y requería credenciales de proyecto específicas de Google. Eso hacía que la API abierta pareciera menos abierta para los desarrolladores que atendían a más de un navegador.

La nota de interoperabilidad de Chrome de 2016 describió la solución: FCM comenzó a aceptar el Protocolo Web Push estándar, y VAPID aportó la autenticación del remitente mediante un par de claves pública/privada en lugar de un ID de remitente de GCM y una cabecera Authorization propietaria.

El resultado práctico fue una sola ruta de código. La propia guía de Chrome indicaba que VAPID significaba que los desarrolladores ya no necesitaban un proyecto de Firebase y podían usar el mismo flujo de suscripción y envío en Chrome y Firefox.

WebKit de Apple se sumó más tarde a la vía estándar en Safari 16 en macOS Ventura. WebKit indicó que Web Push se habilita conjuntamente mediante Push API, Notifications API y Service Workers, y que los sitios conformes con los estándares podían llegar a los usuarios de Safari sin unirse al Apple Developer Program.

Hacer portátil la identidad del remitente de push

Mantuvo descentralizado el push del navegador: cada navegador podía ejecutar su propio servicio mientras las aplicaciones usaban un único protocolo.

Sustituyó el registro con el proveedor por una identidad criptográfica incluida en la solicitud.

Alineó el push con el modelo de permisos de la web al exigir notificaciones visibles para el usuario.

Un estándar web gana cuando elimina el paso de registro con el proveedor de la ruta habitual.

Tras VAPID, Chrome y Firefox compartieron la misma ruta de envío basada en estándares, y Safari añadió compatibilidad con Web Push en 2022. Las aplicaciones web podían notificar a los usuarios en los principales motores sin crear una aplicación nativa únicamente para el push.