> However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix respectively
While I understand that some developers may think of security as wasteful, having unencrypted data be the default relies on every developer to spend much more time considering the possible threat models and how . Case in point here is Matrix—the IDs they send aren't random at all, they actually send full room IDs and event IDs for each message, so you'd be able to build up someone's entire social graph just from reading their unencrypted push notification data and looking up room IDs on the Matrix server in question or even correlating room IDs across different Element installs. This also hurts users, since they're not in a position to inspect the source code and understand how or whether they need to trust their "push provider" with whatever data the app developers might have chosen to regard as "less sensitive"—WebPush's encryption-by-default design removes trust from the equation entirely and prevents of these sorts of "passive surveillance" attacks (except those based on timing or message length)
> You can then decrypt these notifications in the app
This pushes all of the complexity of supporting encryption onto the app developer, instead of having it be provided by the platform where it can be centrally audited and securely managed.
> However, we don't use the WebPush API between the push server and distributor since there is a lot of scope for innovation in that space (for example Google's FCM uses a custom XMPP based protocol).
Why not do this innovation in an open standards body like the IESG where other stakeholders can give feedback and review? The web push standard does allow for Push Servers to use other custom wire protocols besides the default RFC8030, but having open and standards-based discussion of the possible performance improvements would "lift all boats" in terms of being able to provide low-power devices with timely push notifications