UnifiedPush - which implementation? - what limitations?

Hello

Which distributor is used by /e/OS for UnifiedPush?
Is the push server internal or uses an external service?
Are there any limitations? For example, if I develop an alert application that sends a push message to all users (5000 for example) at the same time several times a day. Is this possible or is there a message limit? (per day? per minute? per second?)

1 Like

This sounds promising… I have been wondering how reliable push services could be used in /e/OS for open-source builds of FairEmail & Telegram: both of which are (I think falsely) characterised as “battery drainers” when cut off from the Google push service.

I found the beginnings of an answer here :

Thanks to julianfoad

Some limitations here : Sending messages - ntfy

To return to my example, it’s impossible to send 5000 push messages at the same time. Only 60 at the same time, then 1 message every 5 seconds, up to the limit of 250 messages per day :frowning:

In addition, by default ntfy pushes all messages to Firebase Cloud Messaging (FCM) (Sending messages - ntfy). Strange choice from /e/OS to use this service.

Not really. /e/ OS already uses this service. That’s why we’re here instead of using one of the droid builds which don’t come with gapps.

In my opinion the whole point of UnifiedPush is to do without Firebase Cloud Messaging. Using an internal instance of ntfy by cutting the links to googol would seem more relevant to me. (Or use another distributor.)

In the end, the user is free to use the distributor supplied by /e/OS or another of his choice.

Testing with UP-Example shows the parameter up=1 in the URL, so the link to Firebase Cloud Messaging is disabled. (Sending messages - ntfy)