-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UnifiedPush support #340
Comments
(FTR Element Android already supports |
I've transferred this to sygnal, which is the project which implements push (homeservers talk to a push gateway, which sygnal is one of). |
https://unifiedpush.org/users/gateway/#matrix lists some existing push gateways that support push from Synapse. I'm not convinced we need to complicate Sygnal by bolting in UP support. |
Perhaps the OP's request is to support UP more natively in Synapse so that there is no need for a UP gateway? I think that is a thing that is possible and sensible, but I am not familiar enough with UP to know exactly what is required. This has come up before (matrix-org/synapse#9337) though again that issue didn't make clear exactly what was required. The reason that APNS and GCM push has to go via Sygnal, instead of happening directly from Synapse, is that for APNS and GCM you have to present a secret authentication key specific to the client application. In other words, you have to use a Sygnal instance which is hosted by the client application author, rather than the HS provider (so the instance at With UP, the necessary authentication params can be presented by the client when setting up push -- hence homeservers could do the push themselves rather than delegating to a push gateway hosted by the client authors. |
Ah-ha, I didn't realize this was possible. If this is the request then, I'd say we should move this to matrix-spec...it wouldn't make sense as a Synapse specific feature IMO. |
Yes, I don't understand, what is the use of separate push gateway? Of course with FCM and APNS it's worth, since you don't want propietary crap in Synapse, but with UP the situation is different. I don't know where would be best to target these, but I would like:
|
IMO each server can decide itself how their deliver push notifications. It's unnecessary to include this in the Matrix communication protocol. |
I'm struggling to understand, based on the UP site, exactly what needs to be changed here. Please could you point to a clear spec for what such a push notification looks like? Or give an example HTTP request? |
That is not the reason that Synapse and Sygnal are separate. Sygnal is entirely open-source; there is no "proprietary crap". |
Devices decide where their push notifications should be routed to, not servers. This allows multiple clients to receive push notifications separately using the same homeserver. Note that it is already possible to use UnifiedPush with Element Android. @richvdh pointed to documentation about this above: #340 (comment) |
I tried to setup my own ntfy and it is not working with Element. Looking in synapse-admin the gateway is still matrix.gateways.unifiedpush.org and the key includes the address of my ntfy server. |
Please add support for UnifiedPush push notification protocol/standard.
We need push notifications, but we don’t want use centralized online service that read we all notifications, like Android has Google Firebase Messaging Service and iOS has Apple Push Notification service. UnifiedPush protcol is the solution for this. UnifiedPush is open protocol/standard for connection between online service (Application Server) → notification service (Push Server) and notification service’s client (Push Distributor) → application (End User Application). It enables the user to choose the service through he receives his push notifications.
Especially GNU/Linux on mobile is very big need of push notifications and with UnifiedPush we can fix it.
The text was updated successfully, but these errors were encountered: