[HN Gopher] Conversations (XMPP Client) is now a UnifiedPush dis...
___________________________________________________________________
Conversations (XMPP Client) is now a UnifiedPush distributor
Author : karmanyaahm
Score : 94 points
Date : 2023-01-14 16:42 UTC (6 hours ago)
(HTM) web link (unifiedpush.org)
(TXT) w3m dump (unifiedpush.org)
| aguywithguile wrote:
| I've been using this for a day or so since it came out as a
| replacement for ntfy. It's been really solid so far and means I
| only have 2 apps that wake my phone up -- conversations (provides
| notifications for irc and fediverse stuff) and fair email.
|
| I'm really hoping something comes along to provide email with
| webpush/unifiedpush notifications.
| inputmice wrote:
| JMAP (IMAP+Submission replacement) has support for WebPush. If
| I have a minute I'll implement UnifiedPush in https://Ltt.rs -
| Sadly JMAP doesn't have a lot of server implementations. (Yet?
| Maybe)
| aguywithguile wrote:
| That'd be quite cool :) I've been using maddy for a self
| hosted mail server, itd be nice to replace it with stalwart
| and give ltt.rs a try... and convince the hosted mail i use
| to start using a JMAP supported server
| gary_0 wrote:
| I'm not a mobile developer (or heavy mobile user). Can someone
| ELI65?
| karmanyaahm wrote:
| My recent F-Droid blog post explained what UnifiedPush is in
| detail, basically:
|
| > until now, the only option for push notifications was
| Google's proprietary service, Firebase Cloud Messaging (FCM).
| UnifiedPush is a new alternative that allows you to get push
| notifications without being tied to a single company.
|
| > Applications that support UnifiedPush can receive
| notifications via a dedicated UnifiedPush application that
| maintains a single server connection to receive all
| notifications. We call this "UnifiedPush application" a
| distributor;
|
| Conversations is now a distributor, and UnifiedPush-supporting
| apps like Element or Tusy can receive notifications through it.
|
| https://f-droid.org/en/2022/12/18/unifiedpush.html
| codetrotter wrote:
| Does this work on iOS also?
| gary_0 wrote:
| Nope: https://unifiedpush.org/users/faq/#will-unifiedpush-
| ever-wor...
| Spivak wrote:
| It seems kinda silly to just not provide an abstraction
| over Apple/Google notifications like Pushover does and
| then provide opportunistic use of new network.
|
| If you compromise your ideals like a tiny bit you can
| build your network and be ubiquitous.
| MattJ100 wrote:
| It's not about ideals, but technical limitations.
| UnifiedPush isn't an app like Pushover. It's
| plumbing/APIs for delivering notifications to apps, and
| it replaces the plumbing provided by the OS vendors.
| However, that's simply not possible on iOS (or if it is,
| as they say in the FAQ entry, please share how!).
|
| If all you want is to get a generic message in front of a
| user, UnifiedPush isn't what you're looking for - just
| use Pushover, ntfy.sh apps or whatever for that. They use
| Apple's push notification APIs.
| resonator wrote:
| I don't have or want a Google or Apple account. I use a
| de-googled android phone running Lineage with MicroG. I'm
| glad for Unified Push because it means i can now get
| instant message notifications for supported apps, without
| which I would need to rely on SMS which can take up to 15
| minutes to appear.
|
| I am not willing to compromise my ideals. It there were
| no unified push, I would just live with delayed
| notifications of SMS, but this is better.
|
| edit: corrected that I would have no notifications, not
| delayed notifications without unifid push.
| karmanyaahm wrote:
| For cross platform UnifiedPush libraries, such as
| Flutter, it totally makes sense to support iOS by
| wrapping APNS. Unfortunately, most people on the UP team
| don't have Apple devices, or iOS development experience.
| Maybe someday...
| [deleted]
| [deleted]
| MattJ100 wrote:
| Mobile OSes (such as Android and iOS) heavily restrict what
| apps can do in the background, or even terminate them entirely
| when they are not in the foreground. This is to increase
| battery life, etc.
|
| For many apps, notifications are important. Using Mastodon as
| an example - if someone mentions you on Mastodon, your app
| should tell you. But unless you actually have the app open, it
| won't be able to receive any notification from your Mastodon
| server due to the OS restrictions.
|
| As a solution, the OS vendors created special services embedded
| into the OS that are allowed to maintain a persistent network
| connection to the OS vendor's cloud servers.
|
| Then if an app developer wants their app to display a
| notification, they obtain an API key from the OS vendor and
| connect to the OS vendor's API and submit their notification to
| it.
|
| The OS vendor's servers will then deliver the notification to
| the notification service on the device, the notification
| service will display it to the user or wake up the app.
|
| Google's service (Firebase Cloud Messaging (FCM)) and Apple's
| Push Notification Service are proprietary things.
|
| On Android, there are free and open-source apps that don't link
| to Google's proprietary components, including their
| notification service. F-Droid is an FLOSS "app store" that will
| not distribute apps using Google's APIs in their repository.
| Some "de-Googled" Android flavours remove the component
| entirely from the OS.
|
| However some developers still would like a way for their app to
| receive notifications without constantly polling (repeatedly
| making requests to check for new data) in the background. It's
| annoying and not very efficient (for network usage or battery).
|
| UnifiedPush is an open API/specification that provides an
| alternative to the proprietary APIs. It allows you to set up a
| "distributor" app which will relay notifications to the other
| apps on your device. The distributor app generally keeps a
| single open connection to a server, and waits for notifications
| to come in.
|
| App developers can deliver notifications to the user's chosen
| notification server using a standard API, and know that it can
| reach their device. The OS vendors are no longer in the loop.
|
| Conversations is a messaging app, usually used for chats/calls
| like any other. It uses an open messaging protocol called XMPP,
| which has a bunch of open-source servers and clients, and can
| be self-hosted. Conversations already maintains a connection to
| the XMPP server, and XMPP already has various optimizations to
| minimize network activity and battery usage.
|
| The Conversations developer has developed a way to re-use the
| existing XMPP connection for notifications, as well as your
| messaging traffic. Conversations acts as a "distributor" and
| will relay notifications to other apps on your device that
| support UnifiedPush.
|
| Hope this helps! It can be a lot to take in :)
| jesprenj wrote:
| Why is a separate notification proxy better than letting apps
| run in background and take care of their notifications? A
| simple poll() shouldn't waste much CPU, right? I think that
| is what my IMAP client and the mentioned conversations XMPP
| client do.
|
| Is the overhead of having 1 TCP connection in idle state
| really noticably better than having ~20, each for every app?
| How does UnifiedPush work with apps with traditional
| protocols, e. g. IMAP/XMPP - I assume the remote server
| itself must be logged in to your IMAP/XMPP.
|
| I never fully understood Google's mobile notifications.
| MattJ100 wrote:
| If every app held open a truly idle TCP connection, only
| exchanging data when necessary, you're right. Open idle
| connections are pretty lightweight.
|
| There are a number of problems. One is that apps weren't
| doing that. It's too tempting for app developers to do
| things like HTTP polling instead. Then you have apps all
| polling at different intervals, and then on average the
| phone's radio is constantly in an active state even if the
| user isn't doing anything.
|
| Even if apps correctly used persistent connections, it's
| actually tricky to maintain a persistent connection. There
| is a balance between reducing traffic and detecting that
| the connection has failed (using keep-alives, etc.). After
| a network transition, connections must be re-established.
| Doing that once is cheaper than doing it N times, once per
| app.
|
| XMPP servers do support push notifications (e.g. via
| Apple/Google), though they aren't usually necessary on
| Android unless you have an overly aggressive one (
| https://dontkillmyapp.com ). On iOS they're practically
| essential.
|
| It makes less sense for XMPP clients to use UnifiedPush,
| because if you're in an environment where you are able to
| have something constantly running as a UnifiedPush
| distributor and maintaining a persistent connection, you
| might as well make that something be your XMPP app, which
| can reuse the same connection for more than one thing.
| another_story wrote:
| Really great explanation. Thank you.
| ryukafalz wrote:
| This is amazing! I love to see things like this, because push
| notifications are always a sticking point on mobile devices that
| aren't tied to Apple or Google. And this looks like it'll make it
| easier to get started if you already have an XMPP account.
| Reitet00 wrote:
| Indeed. It seems FluffyChat (Matrix client) can now use
| Conversations for push notifications delivery.
| ralls_ebfe wrote:
| That's an interesting development, thank you.
___________________________________________________________________
(page generated 2023-01-14 23:00 UTC)