Push notifications

[paolo-caroni]

What about use unified notification ?https://unifiedpush.org/

[2743ab2]

What about use unified notification ?

Strongly against!
FOSS has gone from one unified google push notification service to come to another?!
What for? So that now another service knows what software I use? I do not like it. My use of Telegram, it's only mine and Telegram!
In addition, the Telegram FOSS background service does not cause any problems with device autonomy. In the absence of Google services, my Android 9 smartphone works confidently for at least 5 days on a single charge.
If you have problems with this, then it is logical for you not to use FOSS, but to pay attention to the official Telegram client, whose notifications are based on a unified push service from Google.

On the contrary, I would add a line to manifest.xml to request to ignore battery optimization "android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" so that all sorts of Chinese shells do not kill the background process.

[vfosnar]

Well, you can always self-host your notification server. My opinion is there should be at least an option for using the unified push system because as I said some people host their own instances and I don't see any problem there.

[2743ab2]

My opinion is there should be at least an option for using the unified push system because as I said some people host their own instances and I don't see any problem there.

On your part, there is an unreasoned exchange of opinion, a wish.
You do not answer the main question - "What for?".
What "FOSS client" problem do you want to solve by adding a unified push service?
Why should it be exactly https://unifiedpush.org/ and not something else like https://openpush.io ?
Who will guarantee that these services will continue to exist and work tomorrow?, and not disappear like hundreds of xmpp-servers (maintained by both individuals and groups of enthusiasts)?
If you have a clear vision for the implementation, you can develop your own "fork" individually or together with like-minded people.

[AlbanBedel]

@2743ab2 not having a framework for push notifications in the FOSS android ecosystem is definitely a long standing pain point. Sure if you only use a single messenger, and it implement its background sync correctly, you probably don't see a problem. But as you add more apps it start to crumble because all these background processes keep constantly waking your phone and all together they do consume quiet some power.

Now if you take a look at what unifiedphush is about you will see that it is basically an API, it doesn't mandate how the push system is to be implemented. So it neither lock you with a vendor, nor with a specific push transport technology.

I don't think anybody is asking to drop the current background sync implementation and switch to UP only, just to have optional support.

[astein248]

I'll bump this request - I'm trying to de-google and having a bunch of messengers syncing in the background is neither pleasant nor good for battery. I just set up my own ntfy server to handle unifiedpush notifications (as well as other push notifications from my own alerts), and it was very simple to do.

[white-gecko]

Here is some information on how the matrix client element does it: https://github.com/vector-im/element-android/blob/16ca26569f99df230888f78a8e2529c5e385ddda/docs/unifiedpush.md

[q7nm]

Any news?

[neutralinsomniac]

I am all for this, however, I believe in order to do this properly, you would need something on the server side to actually publish notifications to the client(s). There is a zero percent chance that Telegram themselves will do it, so that leaves someone to write a middle-layer service that would run on a server somewhere, logged into your Telegram account, that will handle pushing notifications to your other client(s) when you get a new message. It's not as easy as setting this up on something like Matrix, where they control the server implementation and have a system in place for setting up arbitrary notification systems already.

So the tldr; this would require a server component to be written in addition to client changes, which is probably out-of-scope for this project.

[ildar]

I agree. UnifiedPush has no chance to work on Telegram. Yet FOSS implementation of FCM would help a lot. There are some in the hood.

[danog]

Telegram allows sending push notifications to arbitrary HTTPS endpoints using the web push protocol: https://core.telegram.org/api/push-updates (type=10).

I might give a go at writing a web-push=>unifiedpush proxy this weekend, which should solve this issue.

[danog]

Turns out no proxy is needed, Telegram's implementation is lax enough and doesn't check the return code of the push endpoint, for example pushing to ntfy works OK even if the return code is 200 and no Link header is present.
Unifiedpush can be directly integrated in the app, no proxy required.

[martin-braun]

@2743ab2 Sorry if I sound harsh, but it seems you have not spend a dime looking into https://unifiedpush.org/, have you? This is not a "service", it's an open-source library that can be implemented in any app and it allows the user to decide themselves what push server to pick (self-hosted like ntfy or NextCloud or FCM etc.) by installing the proper push client on his/her device for it. The user could even select an open-source FCM push client (which could also be embedded, since it's not official proprietary stuff), but this makes no sense here, because people could just get the official Telegram app for that, if they really want Google to be involved.

Take a look:

The green parts are installed by the user, the app registers itself through his/her push client with the push server (own infrastructure) and passes the received endpoint to the Push Server, afaik. When the App Server wants to push the message, it just sends it to the endpoint, which points to your Push Server (or a proprietary Push Server like FCM, if the user has chosen to).

There is just a thing to be mind of: The "App-Server" would be the Telegram server in this case, which won't happen. So, there has to be something in between. Since we don't want to introduce another to-be-trusted dependency that our messages have to go through, the "App Server" needs to be a self-hosted gateway as well, so it really only makes sense to consider for self-hosting.

The benefit is huge though. For all apps that implement Unified Push you only have to have one Push Client and its notifications run through your infrastructure, your battery will thank you without relying on any other dependency.

[danog]

The only things Telegram-FOSS has to do to use unified push are:

1. Get a push endpoint from the library
2. Generate ECDH key material according to RFC-8291
3. Call account.registerDevice with the generated public key and the received endpoint
4. Decrypt received notifications first with ECDH, then with MTProto
5. Handle decrypted notifications.

[martin-braun]

@danog I wasn't talking to you, I was talking to @2743ab2, but it's nice to get some more insight about what actually need to be done on Telegram-FOSS by someone who is even deeper into the specs, I scratched the surface so far.

I actually missed your last comment. Wow this is good news, but kinda unsupported. A proxy would make this stable and prevent things from breaking for long if they decide to change something. But it's great to know that this would work without a proxy.