Now I want this even more:
https://www.reuters.com/technology/cybersecurity/governments-spying-apple-google-users-through-push-notifications-us-senator-2023-12-06/
3 Likes
Glad to see UnifiedPush is now being considered for /e/OS, as described (but not named) in the /e/OS 2024 roadmap blog post which shows a screen-shot from a proof-of-concept with a “ntfy.sh” icon showing.
Can someone describe or link to the proof-of-concept work that is now being done?
1 Like
@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.