Telegram FOSS

[yu-re-ka]

Telegram-FOSS-Team/Telegram-FOSS#497
Telegram-FOSS-Team/Telegram-FOSS#468

[karmanyaahm]

The Telegram server does not support push services other than fcm

Telegram-FOSS-Team/Telegram-FOSS#468 (comment)

So, this is dependent on upstream telegram or #17

[karmanyaahm]

https://bugs.telegram.org/c/20254

[karmanyaahm]

Progress: Telegram-FOSS-Team/Telegram-FOSS#577 (comment)

@danog Feel free to join the UnifiedPush Matrix/IRC chat if you're implementing this. There are some resources in Tusky for implementing WebPush decryption

[p1gp1g]

WIP: Telegram-FOSS-Team/Telegram-FOSS#715

With this fork already available : https://github.com/drizzt/Mercurygram/

[p1gp1g]

It would be nice to contact telegram to ask for WebPush (RFC) support.
They seem pretty open to push mechanism: https://core.telegram.org/api/push-updates
They have wrongly stated Firefox's simple push as compatible with UnifiedPush (it sends a PUT)
They currently support the 4th draft of WebPush

Does any of you wants to contact them ? @karmanyaahm @drizzt @quqkuk

[danog]

Note when updating the push-updates article, I explicitly mentioned SimplePush to be UnifiedPush-compatible even if a PUT request is used, because at least ntfy supports PUT requests (as well as POST).

Personally I could try to ask to add support for UnifiedPush, but quite frankly I think that (and I already mentioned this in the UnifiedPush matrix group) it would make much more sense to modify the UnifiedPush spec to provide compatibility with WebPush.

I like UnifiedPush as a project, it gives users freedom of choice and privacy, but making it (partially) incompatible with the industry standard that is WebPush was a big mistake IMO.

Adding support for (all versions of) WebPush (at least in the sense of modifying the UnifiedPush specification to force servers to also pass on request headers, without requiring them to handle decryption) will allow one-step, proxy-less UnifiedPush integration with practically all IM applications, since all of them already offer web apps with web push notification delivery.

[danog]

Ref #15

[p1gp1g]

Note when updating the push-updates article, I explicitly mentioned SimplePush to be UnifiedPush-compatible even if a PUT request is used, because at least ntfy supports PUT requests (as well as POST).

We should probably open a PR on ntfy to refuse PUT for UnifiedPush requests to avoid this confusion.

Personally I could try to ask to add support for UnifiedPush, but quite frankly I think that (and I already mentioned this in the UnifiedPush matrix group) it would make much more sense to modify the UnifiedPush spec to provide compatibility with WebPush.

I like UnifiedPush as a project, it gives users freedom of choice and privacy, but making it (partially) incompatible with the industry standard that is WebPush was a big mistake IMO.

Adding support for (all versions of) WebPush (at least in the sense of modifying the UnifiedPush specification to force servers to also pass on request headers, without requiring them to handle decryption) will allow one-step, proxy-less UnifiedPush integration with practically all IM applications, since all of them already offer web apps with web push notification delivery.

I know everything is complicated when we talk about WebPush because its adoption has started while the spec was being writing and there is a lot of confusion about the actual webpush and the draft many app supports.

So : UnifiedPush IS compatible with WebPush (RFC), that's why we should ask telegram to support WebPush. They currently support a 7yo deprecated draft of WebPush (the 4th draft).

Do you think you can ask them to support WebPush (RFC) as a 13th supported protocol ? Clients supporting the 4th draft will be able to migrate smoothly, and it will add a protocol fully UnifiedPush compatible.

[danog]

Do you think you can ask them to support WebPush (RFC) as a 13th supported protocol

Sure, I can do that, not sure if they'll actually do that though, as I can already see a reason against doing that: doing that would be a BC-break, removing support for legacy web push servers which only support the legacy aesgcm mode.

In general, since UnifiedPush is a somewhat minor project without even an RFC, I find it a bit weird that it is applications that should adapt to it, rather than the other way around (of course, I would love for the opposite to be true, but this is the current state of things; mine is not a criticism of the project, but rather a consideration that this can greatly increase adoption with a small change on UnifiedPush's side, which can turn in a positive feedback loop of adoption and more serious consideration due to larger adoption).

[p1gp1g]

Adding WebPush (RFC) as a 13th protocol won't break clients using the draft (their 10th protocol) since it will still be available.

I don't see the point about asking support for it. WebPush is a standard (RFC), not a minor project. They do not (really) support WebPush atm: they never have upgraded to the released version.

[quqkuk]

Sure, I can do that, not sure if they'll actually do that though, as I can already see a reason against doing that: doing that would be a BC-break, removing support for legacy web push servers which only support the legacy aesgcm mode.

Most platforms that support the WebPush draft are browsers that also support the standard defined in the final document (just to give a date, the document was standardised June 2017)

In general, since UnifiedPush is a somewhat minor project without even an RFC, I find it a bit weird that it is applications that should adapt to it

If a project such as UnifiedPush has to bend over backwards to support different message standards then it may never spread and thus be standardised by the IETF, as it will always be seen as glue, glue that has to play a cat-and-mouse game to adapt to what services use today.
Having a gateway that transforms aesgcm payloads allows for a patch to be worked on while Telegram fixes their server (or changes their documentation, which currently points to the RFC, not the draft)

I could contact Telegram, but I don't currently have a lot of time in my hands, so consider me as a last resort

[p1gp1g]

Codeberg issue: https://codeberg.org/UnifiedPush/wishlist/issues/13