@julianfoad don’t know what endpoint/transport ntfy in the screenshot uses. UnifiedPocReceiver should be a demo app consuming events received via ntfy.
It’s not necessarily UnifiedPush alone that is moving the ecosystem, WebPush is another element. You also need appservers [1] support to create the events to be published to push servers. If you read [2] you’ll see implementers also need clarification on unified-/webpush before writing their spec. Ideally (as @helicase alluded to) things end up at a message mechanism with e2ee. Webpush has it, Unifiedpush by virtue of supporting Webpush.
- [1] Nextcloud https://github.com/nextcloud/server/issues/22379#issuecomment-1558739274 → https://github.com/nextcloud/server/pull/40464
- [2] davx5 https://github.com/bitfireAT/webdav-push/discussions/21 (and spec at https://github.com/bitfireAT/webdav-push/blob/main/webdav-push-draft.md)
My guess is /e/ will host a transport server and incorporate its use once their core ecosystem arrived at that support. Why should they sooner if the default apps cannot make use of a push messaging system.