O Web Push escapou dos silos das lojas de aplicativos ao tornar a identidade do remetente um padrão

O Web Push inicial funcionava no Chrome, mas o caminho de backend ainda passava pelo Firebase Cloud Messaging e exigia credenciais de projeto específicas do Google. Isso fazia a API aberta parecer menos aberta para desenvolvedores que atendiam mais de um navegador.

A nota de interoperabilidade do Chrome de 2016 descreveu a correção: o FCM passou a aceitar o Web Push Protocol padrão, e o VAPID forneceu autenticação do remetente com um par de chaves pública/privada em vez de um ID de remetente do GCM e um cabeçalho Authorization proprietário.

O resultado prático foi um único caminho de código. A própria orientação do Chrome dizia que o VAPID significava que os desenvolvedores não precisavam mais de um projeto do Firebase e podiam usar o mesmo fluxo de inscrição e envio no Chrome e no Firefox.

O WebKit da Apple mais tarde aderiu ao caminho dos padrões no Safari 16 no macOS Ventura. O WebKit disse que o Web Push é habilitado pela Push API, pela Notifications API e pelos Service Workers em conjunto, e que sites compatíveis com os padrões podiam alcançar usuários do Safari sem aderir ao Apple Developer Program.

Tornar portátil a identidade do remetente de push

Manteve o push do navegador descentralizado: cada navegador podia executar seu próprio serviço enquanto os aplicativos usavam um único protocolo.

Substituiu o registro no fornecedor por uma identidade criptográfica carregada na requisição.

Alinhou o push ao modelo de permissões da web ao exigir notificações visíveis ao usuário.

Um padrão web vence quando remove a etapa de cadastro no fornecedor do caminho comum.

Depois do VAPID, o Chrome e o Firefox passaram a compartilhar o mesmo caminho de envio baseado em padrões, e o Safari adicionou suporte ao Web Push em 2022. Aplicativos web puderam notificar usuários nos principais motores sem construir um aplicativo nativo apenas para push.