9 ms·

UnifiedPush: A decentralized, open-source push notification protocol

741 points by mikece 4y ago

geokon 4y ago
Does anyone know how de-Googled Chinese phones work? How do programs like Wechat go about it?
MayeulC 4y ago
Wow, that was submitted here quicker than we could do it! UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/ https://unifiedpush.org/ With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP. UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, that anyone can self-host or any OS can provide without compatibility issues. It does require small adjustments server-side and client-side for applications assuming Google services. There is also a Matrix room at #unifiedpush:matrix.org and a Mastodon account at https://fosstodon.org/@unifiedpush https://fosstodon.org/@unifiedpush Note: we'll be monitoring this topic for a while, you don't have to reply to this thread. † karmanyaahm and S1m are main authors
- ajvs 4y ago
  Thanks for your great work creating this protocol. Hope more app developers add support for it, especially for privacy focused apps like Signal which by relying on Google servers are leaking metadata.
  - MayeulC 4y ago
    Regarding Signal, I don't think they have been approached yet... https://github.com/UnifiedPush/wishlist/issues/8 https://github.com/UnifiedPush/wishlist/issues/8 I think the consensus was that we wanted to wait for UnifiedPush to be more mature before approaching them, but it's probably about time. S1m made an interesting implementation for the (compatible) Signal fork Molly: https://github.com/mollyim/mollyim-android/pull/152 https://github.com/mollyim/mollyim-android/pull/152 The implementation is quite interesting: it adds a linked device that does not receive encryption keys, but sends push notifications to the client.
  - seizethegdgap 4y ago
    The team has been working to get UP support added to Molly, a fork of Signal for Android. https://molly.im/ https://molly.im/ https://github.com/mollyim/mollyim-android/pull/152 https://github.com/mollyim/mollyim-android/pull/152
  - EGreg 4y ago
    If you deliver notifications, you are always leaking metadata around timing. A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off. If you want real anonymity on the Internet, never use push notifications. Always “pick up your mail” periodically from random endpoints on the Web.
    - michaelmior 4y ago
      In theory, if you were worried about this, I think you could get around that problem by just constantly send fixed sized encrypted messages large enough to hold any potential notifications. When a notification needs to get sent, you add it to the next outgoing encrypted message. Of course, now the delay for notifications is now coupled to the rate of these messages being sent.
      - EGreg 4y ago
        The messages can still be traced to the client picking them up. Cut their networking and the client doesn’t receive the messages anymore… this shows up as a bounced message. You can accumulate encrypted messages at random urls instead
        michaelmior 4y ago
        I guess I initially misunderstood what you meant by timing, but that makes sense.
        skybrian 4y ago
        If nobody in the chat room can know that you lost connectivity, that means you can't do real time chat and might as well use email instead. Note that a similar thing happens with any two-way conversation; if an immediate reply is expected and there's no reply, it's not a conversation anymore. (For more possible reasons, though.) Disappearances can't have good error messages if you want plausible deniability. This will make any UI much less user-friendly.
    - dismalpedigree 4y ago
- ilyt 4y ago
  Uh, the site doesn't load...
  - MayeulC 4y ago
    Looks like IPv6 is broken :/ The AAAA record was temporarily removed to try to mitigate.
    - miyuru 4y ago
      Interested to know what happened here. Shouldn't Happy eyeballs fall back to IPv4 when IPv6 is broken?
      - MayeulC 4y ago
        They should, which is why nobody noticed it was broken. Someone told us IPv6 was broken after we submitted here, as they use an IPv6-only network, apparently. I just posted that up there in case that was the actual issue encountered by the commenter. We're not sure why it broke yet, but we'll fix it when there's less traffic.
- dncornholio 4y ago
  Does the user require to install a separate app to receive UnifiedPush messages?
  - MayeulC 4y ago
    Yes, they need to have a UnifiedPush distributor on their device, that acts like Google services. OS makers could install a default UnifiedPush distributor though. Lastly, the Embedded FCM UnifiedPush library (to be embeded into a client app) handles UnifiedPush over FCM (Google-provided push notifications), so that a server only has to handle the UnifiedPush API (with a rewrite proxy for UP->FCM). https://unifiedpush.org/developers/embedded_fcm/ https://unifiedpush.org/developers/embedded_fcm/
  - ehutch79 4y ago
    We can't get users to understand that the ceo isn't sending them mail from giftcards563@gmail.com to go and buy giftcards, and not to ask any questions. What's the actual likely hood that the average end user is going to install a random service?
    - karmanyaahm 4y ago
      > What's the actual likely hood that the average end user is going to install a random service? For now, UnifiedPush is targeted towards De-Googlers, self-hosters and FOSS enthusiasts, not average users.
      - ehutch79 4y ago
        Except, in the threads here, this is called out repeatedly as a replacement for push notifications on phones, replacing webpush, apple push notifications, and whatever google is calling it. Which implies the use case people are seeing is phone apps. Unless people are building one off apps for themselves, you've got end users in the mix. I don't see how this can be positions as much outside of phone apps, as txt messages or emails would be easier and more universal. Being that they're probably going to be supported here. To note, i haven't see anyone talking about this being replacement for the part of webpush that handles registration for notifications or whatnot, but as a whole separate channel/technology. Not 'install this to avoid using google/apple for webpush' but 'use this in your app, and have your users install the service'.
- lern_too_spel 4y ago
  Congrats! It's always surprised me that Amazon or one of the other Android vendors didn't do this themselves to make porting to FireOS or other services-included Android distributions easier, but I hope you get funding from them for doing their job for them.
  - MayeulC 4y ago
    Everyone wants to be Google, and I bet most managers see lock-in to their platform as a good thing, and ease of porting to competitors a bad thing. At least, if they feel big enough to gain initial traction... Huawei is pushing their own thing, alternative to Firebase[1]; Amazon as well[2]. There's a dozen services that provide cloud-based services to send push notifications to various services. I think the incentive to gain subscription revenue was greater than the opportunity to make these partially redundant. I'm not sure why it took so long for something like UnifiedPush to appear. It took a fair bit of debugging, but ultimately, it was mostly up to one dedicated individual (S1m) with Android experience. Before UnifiedPush, there was OpenPush[3], but it never materialized. [1]: https://developer.huawei.com/consumer/en/hms/huawei-pushkit https://developer.huawei.com/consumer/en/hms/huawei-pushkit [2]: https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-applica... [3]: https://bubu1.eu/openpush/ https://bubu1.eu/openpush/
    - RainaRelanah 4y ago
      I would imagine Huawei is doing that moreso due to sanctions, no?
- EGreg 4y ago
  Sorry if I’m not understanding something but… Doesn’t Apple and Google on the OS level only allow push notifications to come from its own services? Like, they look for the signature to be compatible with https certificate etc. Otherwise the phone could have a ton of push notifications incoming from anywhere on the Internet. The APN service for instance would only route notifications to a phone if it came from a registered website. How do you get around this? As far as I know, even for VOIP permissions, iOS only wakes your code up if ITS APNS SERVICE sends the notification. How are you able to install a long-lived application in the background on iOS? Similarly, the phone radio is listening for calls from the nearby cell towers in the network, not from absolutely any tower. I guess a Stingray can impersonate one, but they would probably need to fake the attestation, right?
  - sandos 4y ago
    I believe the notifications used to be delivered by a very long-lived TCP connection, and there probably is no limit to those on Android. The reason to use the google services is mostly touted as for battery savings, I believe.
    - teknopaul 4y ago
      Afaik Google and Apple just discount their own poller. It still has to wake up and check periodically.
      - est31 4y ago
        They have special deals with the telcos that TCP connections to their servers can have longer TTLs. Plus of course, even if you do polling, if you have 5 different apps that connect every 10 minutes to their own respective services with different offsets, you have the device waking up every 2 minutes, with a potential latency of up to 10 minutes for each individual service. If it uses a central push service, you can set it to 5 minutes, the device would therefore wake up less than half of the time, and maximum latency would be 5 minutes, not 10. Thus, it makes total sense to have one mechanism for push messages for the entire device. It's great to have degoogled alternatives here.
- alwayslikethis 4y ago
  Is there any plan to have a method available for patching proprietary apps to work with this? Notifications is the only reason I still have Goolag services on my phone's work profile, and having an alternative to that would be great for privacy.
  - lern_too_spel 4y ago
    The sender needs to know which push service to send the message to, so no.
  - seba_dos1 4y ago
    > Notifications is the only reason I still have Goolag services on my phone's work profile Wouldn't microG be enough for that?
  - MayeulC 4y ago
    As a sibling commenter said, those proprietary apps have a server part that sends notifications to Google's server. If UnifiedPush were to gain enough traction (say it would be adopted on FireOS, HuaweiOS and whatever platform don't use Google services), those apps would likely start to support it directly. Another possible avenue is to add UnifiedPush support to push libraries used by these apps both server and client-side. Multiple libraries (Google FCM included, I linked at least two others from Amazon and Huawei in another comment here) abstract push notifications away so the developer gets a single server to talk to, and a unified API across iOS, Android, Web, etc. If these libraries started supporting UnifiedPush, adoption could increase a lot, without involving any developer effort for these proprietary apps.
- POPOSYS 4y ago
  Thank you very much for your hard and important work! And a special thanks for not forcing us to use a slack channel! Hopefully other OS projects will follow. Good health and all the best for 2023!
- 12907835202 4y ago
  The home page you've given is a little confusing to me and I'm not sure if it's confusing or just not aimed at me. Is this just for mobile (android only?) developers, or is it for any push notifications e.g. browser. Could I use this with PHP or JavaScript for example?
notwokeno 4y ago
>However, if each app actively maintains a server connection, the OS cannot suspend them. This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.) This works on Linux if you don't have the extra Android crap getting in the way. It's kind of a bummer to see bad OS architecture feed into over-complicated protocol/application design. EDIT: I guess I wasn't clear here. In my experiments I had the background wake up service wake the device up once and applications had just that singular window for all of them to service their connections. The problem with Android is instead applications either keep the phone from suspending entirely or (apparently) have some API allowing them to register their own periodic wake up that isn't shared. EDIT2: I also want to be clear that this isn't a criticism of NTFY. The developers behind it deserve congratulations for solving a serious problem with FOSS Android apps. My complaint is that the poor architecture and unescisary inflexibility of Android made this such a complex problem in the first place.
- MayeulC 4y ago
  You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections open. I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level. Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.
  - londons_explore 4y ago
    Google famously tried allowing app keepalives to be synchronised... The scheduler allowed a wakeup in 'approximately' X minutes, and the OS would wake up and run all apps callbacks at once. If any app needed a wakeup at a precise time, then other callbacks at nearby approximate times would be run at the same time too. Overall, the thought was that wakeups are expensive, wakeups that involve the network are particularly expensive, so might as well run them all at once (they tend not to be CPU bound - often much of the wakeup handler is spent waiting for the network to connect and send a packet or an ack to arrive back). This turned out to be a very very bad idea. All it takes is some app to have a 'wake up exactly on the hour', and now all other app callbacks will also run exactly on the hour. End result: Mobile networks get 10 million phones all waking up within a few milliseconds of one another, and everyone wanting to connect, and the whole mobile network fails because it was never designed to have 10 million phones all trying to connect within a few milliseconds. That idea was scrapped.
eternityforest 4y ago
Looks like a cool solution to one of the biggest issues in FOSS on Android.
- alwayslikethis 4y ago
  the main issue isn't with the foss apps though. Those usually support polling. The actual problem is with other proprietary spyware apps that you're forced to use but they are locking you in with google's FCM. Until there's an easy way to patch those apps we can't really solve this problem
  - eternityforest 4y ago
    Yeah, I wouldn't even think about a degoogled phone at this point, none of my downloadable wiretaps would work, and I use a lot of them. But this at least gives FOSS a chance to compete on battery life without FCM fallback like some do. Most likely FOSS will never get full parity, Android might be gone and replaced long before then, but the ability to make an app that's F-droid legal is still a big deal.
    - alwayslikethis 4y ago
      hmm, I think most spyware apps still work without google services (on GrapheneOS), but you'll have to go without notification, among a few other things. If you need a tracking devi.. cough.. googled phone for work only, you can consider using a separate phone for it, and a personal degoogled phone.
      - eternityforest 4y ago
        I use a googled for both home and work pretty extensively, including Google Calendar, Keep, and Assistant, plus Tile and YoLink(Which loses most of it's value without notifications). Carrying two phones seems like a lot of stress, I generally like to minimize the number of objects in my life as much as I can.
nightpool 4y ago
Why use a new custom-built protocol instead of adding support for the Web Push protocol already supported by Firefox, Chrome, Safari and others? https://web.dev/push-notifications-web-push-protocol/ https://web.dev/push-notifications-web-push-protocol/. Now backend developers have Yet Another Push Notifications Protocol to build support for, instead of being able to just easily plug into their existing code. As a benefit, since all notifications through the Web Push protocol are end-to-end encrypted, there's no concern about "trusting" the distributing server like there seems to be in this protocol (based on https://unifiedpush.org/spec/server/ https://unifiedpush.org/spec/server/)
- dijit 4y ago
  This isn't just for notifications to clients themselves, this would handle the federation of notification's. Similar to how Apples push notification service works already (APN: https://en.wikipedia.org/wiki/Apple_Push_Notification_service https://en.wikipedia.org/wiki/Apple_Push_Notification_servic...)
  - nightpool 4y ago
    Yes, the WebPush standard provides protocols for both. This is necessary because otherwise there wouldn't be an intercompatible way for backends to send notifications to different browsers. The protocol for the federation of notifications would be the most useful for other non-JS projects to reuse, so that backend developers can plug any native app in their existing webpush support without coding yet another system.
    - mananaysiempre 4y ago
      I think GP got it backwards, actually: Web Push seems to have a wire interface for submission and a JavaScript API for subscription, while the internals of how the notifications get from e.g. the FCM backend to the notification drawer on your Android phone remain unspecified (and partly secret). UnifiedPush has a wire interface for both submission and subscription+reception, plus an Android(?) intent API for interacting with the client for the latter that’s running on your phone. It looks like the submission side of UnifiedPush could indeed have been Web Push-compatible but isn’t, though.
seydor 4y ago
I wish we could extend SMTP to support notifications as self-expiring emails
- MayeulC 4y ago
  It would also be nice to extend IMAP to support UnifiedPush... The use-case would be new mail notifications; it wouldn't be too hard to do, and would be quite useful, as I typically have multiple e-mail accounts. You could however build a UnifiedPush-compliant SMTP-based or IMAP-based distributor.
  - karmanyaahm 4y ago
    JMAP has a push implementation I really like, and it's natively compatible with UnifiedPush. Would be nice to see more adoption there. https://jmap.io/spec-core.html#push https://jmap.io/spec-core.html#push
- gsich 4y ago
  Notifications would work (and does), maybe a sieve rule for deleting old messages?
afandian 4y ago
The headline got my attention. I'm looking for a standard for subscribeable notifications / callbacks to update users of data changes in an API. Bonus point for federated. But server to server, not server to client. Double bonus points for connecting to consumer services like Zapier or IFTTT. I'm planning to use WebSub and/or RSS, but on the look out for others. Any pointers?
- MayeulC 4y ago
  That use-case sounds a bit similar to Webmentions: https://en.wikipedia.org/wiki/Webmention https://en.wikipedia.org/wiki/Webmention See also... The See also section in that article :) You say it would be server to server, but are both publicly reachable?
  - afandian 4y ago
    We're running an API, we want to say to users e.g. "we finished processing your submission" or "this API resource changed". And offer pull (e.g. RSS) and push flavour. > You say it would be server to server, but are both publicly reachable? So yes, the user would have to run a public server. But only for practical reasons, otherwise how can you push. Webmention isn't quite it, we're notifying about our own API Resources. Websub (FKA PubSubHubub) does. It just doesn't seem to be widely adopted for some reason.
- kevincox 4y ago
  WebSub + RSS/Atom is a good option for relatively slowly changing data. (Maybe at most a couple of times an hour). It is nice because it is opt-in and an enhancement on the regular polling API. Using WebSub or UnifiedPush would technically very similar but you need a way for the client to pass you the subscription information. WebSub has a standard discovery process to manage this.
  - afandian 4y ago
    The WebSub spec looks disarmingly simple but also complete for everything I can think of. I've not yet tried to implement it, but I'm waiting for the catch! Thanks for the confirmation.
rgovostes 4y ago
Off-topic: Sometimes I work on ships that have Wi-Fi for talking to local services, but due to strict metering, Internet access is usually disabled. So most of the time there's no way to get notifications from monitoring systems and your fellow crew, let alone shoreside team members. It would be nice to have a solution for delivering pushes internally, and also hold open a best-effort connection to a remote server that allows some notifications through. The last solution I considered was running a Matrix homeserver on the ship with some local channels, and another instance on shore, and using federation to connect them when the uplink is available. Monitoring systems could send their alerts as DMs or to a shared channel. Then for the notifications, Apple has its Local Push Connectivity API you might be able to use to send notifications within the ship network. I'm not sure if this UnifiedPush would solve the problem on Android. Either way, though, it seems like a lot of engineering effort just for a chatroom.
- karmanyaahm 4y ago
  One of the first uses of UnifiedPush was to self-host the whole Matrix messaging stack. In fact, we have already had someone in the UnifiedPush chat set this up on their ship [1]. Matrix + UnifiedPush would be perfect for a disconnected situation on ships (or Mars colonies :) [1] https://matrix.to/#/!vwmBiTqilorqNCbGab:matrix.org/$hJpXxhVRhxMEJavlgsIFt-QyV3xCuMsveMl2dWRBUfk?via=libera.chat&via=matrix.org&via=envs.net https://matrix.to/#/!vwmBiTqilorqNCbGab:matrix.org/$hJpXxhVR...
  - wereallterrrist 4y ago
    I'm a huge fan of Matrix and the idea of UnifiedPush, but I don't quite grok what this means (and I'm reluctant to fire up my Matrix client because I'm avoiding some things). Is there any chance you can elaborate on what "self-host the whole Matrix stack" means?
    - eternalban 4y ago
      I read the thread just now: ~" Self hosted matrix + UP. Nothing special there. Only issue is cert expiration for setups without connections that result in expired certs for https. That requires some work. "~
Andrew_nenakhov 4y ago
Oh gosh, a wheel reinvented again? XMPP did it ~7 years ago [0] and we have used it for quite a few applications already. [0]: https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html
- binwiederhier 4y ago
  Please be nice. You can convey your information without the snarky tone. You may be factually correct, but your comment comes across quite rude. From the HN guidelines [1]: > Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- kirimita 4y ago
  From the blog post: > One key feature of UnifiedPush is that the communication between the push server and the distributor is not specified. This means that a variety of technologies can be employed, such as WebSockets, Server-Sent Events, *XMPP*, raw TCP, or even SMS, whatever works best for the user.
  - Andrew_nenakhov 4y ago
    Sigh. What you miss is that this protocol introduces nothing that already isn't done by XMPP push notifications. It is decentralized, it can deliver to different endpoints, etc. You only need to create a dispatcher app that will relay the notifications to third party apps. Again, this too was done years ago.
    - kirimita 4y ago
      > You only need to create a dispatcher app that will relay the notifications to third party apps. That part is what specify UnifiedPush. It does not specify the communication between the push server and the distributor.
    - jacob019 4y ago
deleted 4y ago
[deleted]
mixtur2021 4y ago
AFAIK Modern Android (>= 8.0) reserves the right to kill your app when running in the background unless there's a foreground toast bound (even then, can still be killed in low memory situations). How does this solution work around that? Is there a need to opt into the legacy "battery saver disabled" mode for the app which more closely mirrors <= 7.0 execution model?
- karmanyaahm 4y ago
  Most distributors both show a foreground notification at all times and require exempting them from battery optimization. Because of its efficient design, something like ntfy only uses a few percent of battery per day [1]. System-level integration into Android ROMs would eliminate the need for those things. [1] https://docs.ntfy.sh/faq/?h=battery#how-much-battery-does-the-android-app-use https://docs.ntfy.sh/faq/?h=battery#how-much-battery-does-th...
  - mixtur2021 4y ago
    Thanks! As I thought. Long lived sticky foreground notifications tend to annoy folks from my experience. Have you seen complaints?
    - MayeulC 4y ago
      I haven't seen any complaints, but folks who set this up are usually used to having persistent notifications (I currently have 6) without Google services. At least I replaced the one from my Matrix client with the UnifiedPush-enabled ntfy. Hopefully it'll replace Signal too at some point. KDE Connect? Why not. K-9 mail? I hope, but that would require JMAP or IMAP adjustments. One option would be to install the distributor as a system app.
    - binwiederhier 4y ago
      You can easily remove them. There are instructions here: https://docs.ntfy.sh/subscribe/phone/#instant-delivery https://docs.ntfy.sh/subscribe/phone/#instant-delivery
solarkraft 4y ago
Apps draining your battery to check for notifications is the worst thing about degoogled Android. With notifications enabled my telegram client can drain my battery in a very low number of hours (got suggestions here? any client supporting UnifiedPush?) So this is welcome, but it requires application support. And if apps on your phone use both GCM and UnifiedPush you still end up with multiple providers. But at least I think I can trust UnifiedPush to be light on my battery.
- karmanyaahm 4y ago
  > telegram client can drain my battery in a very low number of hours (got suggestions here? any client supporting UnifiedPush?) It's possible. There is nothing ready right now. [1] https://github.com/UnifiedPush/wishlist/issues/18 https://github.com/UnifiedPush/wishlist/issues/18 [2] https://github.com/Telegram-FOSS-Team/Telegram-FOSS/issues/577#issuecomment-1285880888 https://github.com/Telegram-FOSS-Team/Telegram-FOSS/issues/5...
- binwiederhier 4y ago
  It's really not that bad. It uses 1% of battery for 17h. Sometimes even less than that and it shows 0% after the entire day. So it's a hypothetical problem IMHO. There are very few cases or phones i see these days where people complain about battery: https://docs.ntfy.sh/faq/#how-much-battery-does-the-android-app-use https://docs.ntfy.sh/faq/#how-much-battery-does-the-android-...
  - solarkraft 4y ago
    The reason I said it is that it's a problem for me. Notifications on/off makes a night and day difference. Did you link ntfy because that's what Telegram FOSS uses?
janosdebugs 4y ago
This is a nice concept, but I owned more than one Android phone that would ignore the battery optimization settings and kill the applications anyway.
- binwiederhier 4y ago
  I have been working and running ntfy [1] on my phone for a year now (ntfy is a UnifiedPush distributor), and it is true that Android does kill the app every now and then. But it is instantly restarted. Usually ntfy delivers notifications much much much faster than Google's FCM, especially in doze mode. FCM seems to try and conserve battery much more. Disclaimer: I am the maintainer of ntfy. [1] https://github.com/binwiederhier/ntfy https://github.com/binwiederhier/ntfy
  - janosdebugs 4y ago
    Sadly, I had phones where I couldn't keep anything running. Not sure what the manufacturer did there. Even the normal notifications didn't arrive at times. (E.g. Signal)
satvikpendem 4y ago
I'm using Google Firebase Cloud Messaging [0] which allows pushing notifications to devices even if they're asleep, unlike local notification services where the device must be awake and the app must be active. Will this service allow the same thing FCM does, including waking up the device? I'm looking at both iOS and Android devices, I see there's Flutter available but not iOS necessarily in the docs [1]. Related question, will the Flutter version also work for iOS devices? I know FCM (and its Flutter SDK) works for both, as well as web. [0] https://firebase.google.com/products/cloud-messaging https://firebase.google.com/products/cloud-messaging [1] https://unifiedpush.org/developers/intro/ https://unifiedpush.org/developers/intro/
- karmanyaahm 4y ago
  Yes, this is an FCM replacement on Android (and it can easily fall back to FCM if the user doesn't have UnifiedPush). There is no native UnifiedPush on iOS because Apple doesn't allow background services. The server side to support both is simple, but on the client you would need code for both FCM (for iOS) and UP (for Android). It would be interesting to build an FCM wrapper for iOS into the UP Flutter library.
  - satvikpendem 4y ago
    I don't know too much about this, but is this not APNs [0]? I see there is a FCM integration (which is how I assume FCM does it anyway) [1] as well as a standalone Flutter implementation [2]. How would iOS native only apps on Swift do push notifications, surely Apple has their own service and everyone doesn't use Firebase? [0] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns https://developer.apple.com/documentation/usernotifications/... [1] https://firebase.flutter.dev/docs/messaging/apple-integration/ https://firebase.flutter.dev/docs/messaging/apple-integratio... [2] https://pub.dev/packages/flutter_apns https://pub.dev/packages/flutter_apns
    - karmanyaahm 4y ago
      I recommended FCM for iOS instead of APNS because OP is already using it. For iOS clients, FCM just forwards notifications to APNS.
mgaunard 4y ago
There are two things I still don't get about software development: - why is web development such a big thing - why is app development a thing at all
- Alifatisk 4y ago
  I believe web dev is huge because it’s cross-platform by default & easy to get started with.
- palata 4y ago
  You mean "why is software development a thing" there? Not sure what your point is...
anotherevan 4y ago
Any possibility this will mean I can push a notification from my home automation that gets displayed on my Google TV?
- artificialLimbs 4y ago
  If it can call a site, it can use ntfy.
MinaMe 4y ago
[flagged]
sohkamyung 4y ago
Interesting. This could have interest from China, since they have to use Android without the Google push service, causing battery drain issues. They are trying to come up with their own push notification service. The issue is highlighted in this article [1]. [1] https://www.sixthtone.com/news/1011308/the-real-story-behind-chinas-battery-draining-push-notifications?source=channel_home https://www.sixthtone.com/news/1011308/the-real-story-behind...
w4eg324g 4y ago
Why is it named decentralized when it uses a central server to route/distribute the messages?
- LinAGKar 4y ago
  Because you can host your own server, rather than everyone using the same server
deleted 4y ago
[deleted]
javaunsafe2019 4y ago
Please don’t get me wrong but I wonder what is the use case for this. First of all this tries to solve a problem that has already been solved by the mobile device OS layer within IOS and Android and furthermore is only working for Android. Why should anyone use this?
- agsnu 4y ago
  It looks like this aims to be a replacement for people want to use an Android-based OS but don't want to rely on Google services, normally for reasons of philosophical objection to big tech's de facto surveillance capabilities. So presumably users of GrapheneOS, CalyxOS, LineageOS, etc. Also since Google is blocked in China, Firebase Cloud Messaging doesn't work there. Android has something like a 75% market share in that market. Some vendors have their own offerings (e.g. Xiaomi MiPush, Huawei PushKit) etc, I could buy that a popular centralised solution would be more attractive than doing N integrations.
  - MayeulC 4y ago
    This. It also works without internet connection if you want push notifications within a LAN. The vision is that you only need to implement support for 1 integration: UnifiedPush, possibly by embedding one of the libraries that manage it and fallbacks. You automatically gain support for compatible alternatives. There's a variety of reasons why people can't or don't want to rely on Google services. Before UnifiedPush, one would have to "hardcode" an alternative, or more commonly implement a persistent connection within the app. This also has some potential for more efficient push implementation: for instance, if you have access to an SMS gateway, you could use that to push notification without enabling data connection. The specification also makes it easier to support third-party operating systems and clients.
  - javaunsafe2019 4y ago
    Thanks for explaining and giving context - I was totally not aware of this total block of Google in the Chinese market.
joelthelion 4y ago
Would this be vulnerable to spam?
- MayeulC 4y ago
  Each application gets a unique URL, that is supposedly kept secret from any other party. They are also very easy to rotate, as the specification advises to ask for a new one (that could be the same) on every app launch. Moreover, when something is sent to that URL, it gets forwarded to the application, which then interprets it before displaying a notification (for most apps). By spam, I think you meant someone sending messages to random people's notification area. No, this is highly unlikely.
amelius 4y ago
This sounds like it could be the reverse of REST, so could be pretty important and perhaps it can grow into a W3C spec.
- MayeulC 4y ago
  That's an interesting thought, but currently the Server-Server specification is quite trivial, the more complicated part is the Android (and Linux) API, which I don't think the W3C would cover. There's definitely room for adoption within the freedesktop.org umbrella for the Linux part, once this part is a bit more mature.

741 points by mikece 4y ago

Does anyone know how de-Googled Chinese phones work? How do programs like Wechat go about it?

Wow, that was submitted here quicker than we could do it! UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/ https://unifiedpush.org/ With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP. UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, that anyone can self-host or any OS can provide without compatibility issues. It does require small adjustments server-side and client-side for applications assuming Google services. There is also a Matrix room at #unifiedpush:matrix.org and a Mastodon account at https://fosstodon.org/@unifiedpush https://fosstodon.org/@unifiedpush Note: we'll be monitoring this topic for a while, you don't have to reply to this thread. † karmanyaahm and S1m are main authors

ajvs 4y ago
Thanks for your great work creating this protocol. Hope more app developers add support for it, especially for privacy focused apps like Signal which by relying on Google servers are leaking metadata.
- MayeulC 4y ago
  Regarding Signal, I don't think they have been approached yet... https://github.com/UnifiedPush/wishlist/issues/8 https://github.com/UnifiedPush/wishlist/issues/8 I think the consensus was that we wanted to wait for UnifiedPush to be more mature before approaching them, but it's probably about time. S1m made an interesting implementation for the (compatible) Signal fork Molly: https://github.com/mollyim/mollyim-android/pull/152 https://github.com/mollyim/mollyim-android/pull/152 The implementation is quite interesting: it adds a linked device that does not receive encryption keys, but sends push notifications to the client.
- seizethegdgap 4y ago
  The team has been working to get UP support added to Molly, a fork of Signal for Android. https://molly.im/ https://molly.im/ https://github.com/mollyim/mollyim-android/pull/152 https://github.com/mollyim/mollyim-android/pull/152
- EGreg 4y ago
  If you deliver notifications, you are always leaking metadata around timing. A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off. If you want real anonymity on the Internet, never use push notifications. Always “pick up your mail” periodically from random endpoints on the Web.
  - michaelmior 4y ago
    In theory, if you were worried about this, I think you could get around that problem by just constantly send fixed sized encrypted messages large enough to hold any potential notifications. When a notification needs to get sent, you add it to the next outgoing encrypted message. Of course, now the delay for notifications is now coupled to the rate of these messages being sent.
    - EGreg 4y ago
      The messages can still be traced to the client picking them up. Cut their networking and the client doesn’t receive the messages anymore… this shows up as a bounced message. You can accumulate encrypted messages at random urls instead
      - michaelmior 4y ago
        I guess I initially misunderstood what you meant by timing, but that makes sense.
      - skybrian 4y ago
        If nobody in the chat room can know that you lost connectivity, that means you can't do real time chat and might as well use email instead. Note that a similar thing happens with any two-way conversation; if an immediate reply is expected and there's no reply, it's not a conversation anymore. (For more possible reasons, though.) Disappearances can't have good error messages if you want plausible deniability. This will make any UI much less user-friendly.
  - dismalpedigree 4y ago
ilyt 4y ago
Uh, the site doesn't load...
- MayeulC 4y ago
  Looks like IPv6 is broken :/ The AAAA record was temporarily removed to try to mitigate.
  - miyuru 4y ago
    Interested to know what happened here. Shouldn't Happy eyeballs fall back to IPv4 when IPv6 is broken?
    - MayeulC 4y ago
      They should, which is why nobody noticed it was broken. Someone told us IPv6 was broken after we submitted here, as they use an IPv6-only network, apparently. I just posted that up there in case that was the actual issue encountered by the commenter. We're not sure why it broke yet, but we'll fix it when there's less traffic.
dncornholio 4y ago
Does the user require to install a separate app to receive UnifiedPush messages?
- MayeulC 4y ago
  Yes, they need to have a UnifiedPush distributor on their device, that acts like Google services. OS makers could install a default UnifiedPush distributor though. Lastly, the Embedded FCM UnifiedPush library (to be embeded into a client app) handles UnifiedPush over FCM (Google-provided push notifications), so that a server only has to handle the UnifiedPush API (with a rewrite proxy for UP->FCM). https://unifiedpush.org/developers/embedded_fcm/ https://unifiedpush.org/developers/embedded_fcm/
- ehutch79 4y ago
  We can't get users to understand that the ceo isn't sending them mail from giftcards563@gmail.com to go and buy giftcards, and not to ask any questions. What's the actual likely hood that the average end user is going to install a random service?
  - karmanyaahm 4y ago
    > What's the actual likely hood that the average end user is going to install a random service? For now, UnifiedPush is targeted towards De-Googlers, self-hosters and FOSS enthusiasts, not average users.
    - ehutch79 4y ago
      Except, in the threads here, this is called out repeatedly as a replacement for push notifications on phones, replacing webpush, apple push notifications, and whatever google is calling it. Which implies the use case people are seeing is phone apps. Unless people are building one off apps for themselves, you've got end users in the mix. I don't see how this can be positions as much outside of phone apps, as txt messages or emails would be easier and more universal. Being that they're probably going to be supported here. To note, i haven't see anyone talking about this being replacement for the part of webpush that handles registration for notifications or whatnot, but as a whole separate channel/technology. Not 'install this to avoid using google/apple for webpush' but 'use this in your app, and have your users install the service'.
lern_too_spel 4y ago
Congrats! It's always surprised me that Amazon or one of the other Android vendors didn't do this themselves to make porting to FireOS or other services-included Android distributions easier, but I hope you get funding from them for doing their job for them.
- MayeulC 4y ago
  Everyone wants to be Google, and I bet most managers see lock-in to their platform as a good thing, and ease of porting to competitors a bad thing. At least, if they feel big enough to gain initial traction... Huawei is pushing their own thing, alternative to Firebase[1]; Amazon as well[2]. There's a dozen services that provide cloud-based services to send push notifications to various services. I think the incentive to gain subscription revenue was greater than the opportunity to make these partially redundant. I'm not sure why it took so long for something like UnifiedPush to appear. It took a fair bit of debugging, but ultimately, it was mostly up to one dedicated individual (S1m) with Android experience. Before UnifiedPush, there was OpenPush[3], but it never materialized. [1]: https://developer.huawei.com/consumer/en/hms/huawei-pushkit https://developer.huawei.com/consumer/en/hms/huawei-pushkit [2]: https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-applica... [3]: https://bubu1.eu/openpush/ https://bubu1.eu/openpush/
  - RainaRelanah 4y ago
    I would imagine Huawei is doing that moreso due to sanctions, no?
EGreg 4y ago
Sorry if I’m not understanding something but… Doesn’t Apple and Google on the OS level only allow push notifications to come from its own services? Like, they look for the signature to be compatible with https certificate etc. Otherwise the phone could have a ton of push notifications incoming from anywhere on the Internet. The APN service for instance would only route notifications to a phone if it came from a registered website. How do you get around this? As far as I know, even for VOIP permissions, iOS only wakes your code up if ITS APNS SERVICE sends the notification. How are you able to install a long-lived application in the background on iOS? Similarly, the phone radio is listening for calls from the nearby cell towers in the network, not from absolutely any tower. I guess a Stingray can impersonate one, but they would probably need to fake the attestation, right?
- sandos 4y ago
  I believe the notifications used to be delivered by a very long-lived TCP connection, and there probably is no limit to those on Android. The reason to use the google services is mostly touted as for battery savings, I believe.
  - teknopaul 4y ago
    Afaik Google and Apple just discount their own poller. It still has to wake up and check periodically.
    - est31 4y ago
      They have special deals with the telcos that TCP connections to their servers can have longer TTLs. Plus of course, even if you do polling, if you have 5 different apps that connect every 10 minutes to their own respective services with different offsets, you have the device waking up every 2 minutes, with a potential latency of up to 10 minutes for each individual service. If it uses a central push service, you can set it to 5 minutes, the device would therefore wake up less than half of the time, and maximum latency would be 5 minutes, not 10. Thus, it makes total sense to have one mechanism for push messages for the entire device. It's great to have degoogled alternatives here.
alwayslikethis 4y ago
Is there any plan to have a method available for patching proprietary apps to work with this? Notifications is the only reason I still have Goolag services on my phone's work profile, and having an alternative to that would be great for privacy.
- lern_too_spel 4y ago
  The sender needs to know which push service to send the message to, so no.
- seba_dos1 4y ago
  > Notifications is the only reason I still have Goolag services on my phone's work profile Wouldn't microG be enough for that?
- MayeulC 4y ago
  As a sibling commenter said, those proprietary apps have a server part that sends notifications to Google's server. If UnifiedPush were to gain enough traction (say it would be adopted on FireOS, HuaweiOS and whatever platform don't use Google services), those apps would likely start to support it directly. Another possible avenue is to add UnifiedPush support to push libraries used by these apps both server and client-side. Multiple libraries (Google FCM included, I linked at least two others from Amazon and Huawei in another comment here) abstract push notifications away so the developer gets a single server to talk to, and a unified API across iOS, Android, Web, etc. If these libraries started supporting UnifiedPush, adoption could increase a lot, without involving any developer effort for these proprietary apps.
POPOSYS 4y ago
Thank you very much for your hard and important work! And a special thanks for not forcing us to use a slack channel! Hopefully other OS projects will follow. Good health and all the best for 2023!
12907835202 4y ago
The home page you've given is a little confusing to me and I'm not sure if it's confusing or just not aimed at me. Is this just for mobile (android only?) developers, or is it for any push notifications e.g. browser. Could I use this with PHP or JavaScript for example?

notwokeno 4y ago

>However, if each app actively maintains a server connection, the OS cannot suspend them. This is a limitation with Android and not a fundamental network/OS limitation. As long as your protocol allows for long enough keep alive latency you can periodically wake up for a short period and allow apps to service their connections (which is what I'd imagine this does anyway just with a singular app.) This works on Linux if you don't have the extra Android crap getting in the way. It's kind of a bummer to see bad OS architecture feed into over-complicated protocol/application design. EDIT: I guess I wasn't clear here. In my experiments I had the background wake up service wake the device up once and applications had just that singular window for all of them to service their connections. The problem with Android is instead applications either keep the phone from suspending entirely or (apparently) have some API allowing them to register their own periodic wake up that isn't shared. EDIT2: I also want to be clear that this isn't a criticism of NTFY. The developers behind it deserve congratulations for solving a serious problem with FOSS Android apps. My complaint is that the poor architecture and unescisary inflexibility of Android made this such a complex problem in the first place.

MayeulC 4y ago
You can do that, but if keep alive are not synchronized (I don't think there is a mechanism to do so), you will wake more often if you keep more connections open. I think the OS could synchronize them if keep alive packets are sent at the TCP level, but that would be hard to do at a higher level. Letting a single program handle persistent connections leaves a lot more potential for energy efficiency optimizations.
- londons_explore 4y ago
  Google famously tried allowing app keepalives to be synchronised... The scheduler allowed a wakeup in 'approximately' X minutes, and the OS would wake up and run all apps callbacks at once. If any app needed a wakeup at a precise time, then other callbacks at nearby approximate times would be run at the same time too. Overall, the thought was that wakeups are expensive, wakeups that involve the network are particularly expensive, so might as well run them all at once (they tend not to be CPU bound - often much of the wakeup handler is spent waiting for the network to connect and send a packet or an ack to arrive back). This turned out to be a very very bad idea. All it takes is some app to have a 'wake up exactly on the hour', and now all other app callbacks will also run exactly on the hour. End result: Mobile networks get 10 million phones all waking up within a few milliseconds of one another, and everyone wanting to connect, and the whole mobile network fails because it was never designed to have 10 million phones all trying to connect within a few milliseconds. That idea was scrapped.

eternityforest 4y ago

Looks like a cool solution to one of the biggest issues in FOSS on Android.

alwayslikethis 4y ago
the main issue isn't with the foss apps though. Those usually support polling. The actual problem is with other proprietary spyware apps that you're forced to use but they are locking you in with google's FCM. Until there's an easy way to patch those apps we can't really solve this problem
- eternityforest 4y ago
  Yeah, I wouldn't even think about a degoogled phone at this point, none of my downloadable wiretaps would work, and I use a lot of them. But this at least gives FOSS a chance to compete on battery life without FCM fallback like some do. Most likely FOSS will never get full parity, Android might be gone and replaced long before then, but the ability to make an app that's F-droid legal is still a big deal.
  - alwayslikethis 4y ago
    hmm, I think most spyware apps still work without google services (on GrapheneOS), but you'll have to go without notification, among a few other things. If you need a tracking devi.. cough.. googled phone for work only, you can consider using a separate phone for it, and a personal degoogled phone.
    - eternityforest 4y ago
      I use a googled for both home and work pretty extensively, including Google Calendar, Keep, and Assistant, plus Tile and YoLink(Which loses most of it's value without notifications). Carrying two phones seems like a lot of stress, I generally like to minimize the number of objects in my life as much as I can.

nightpool 4y ago

Why use a new custom-built protocol instead of adding support for the Web Push protocol already supported by Firefox, Chrome, Safari and others? https://web.dev/push-notifications-web-push-protocol/ https://web.dev/push-notifications-web-push-protocol/. Now backend developers have Yet Another Push Notifications Protocol to build support for, instead of being able to just easily plug into their existing code. As a benefit, since all notifications through the Web Push protocol are end-to-end encrypted, there's no concern about "trusting" the distributing server like there seems to be in this protocol (based on https://unifiedpush.org/spec/server/ https://unifiedpush.org/spec/server/)

dijit 4y ago
This isn't just for notifications to clients themselves, this would handle the federation of notification's. Similar to how Apples push notification service works already (APN: https://en.wikipedia.org/wiki/Apple_Push_Notification_service https://en.wikipedia.org/wiki/Apple_Push_Notification_servic...)
- nightpool 4y ago
  Yes, the WebPush standard provides protocols for both. This is necessary because otherwise there wouldn't be an intercompatible way for backends to send notifications to different browsers. The protocol for the federation of notifications would be the most useful for other non-JS projects to reuse, so that backend developers can plug any native app in their existing webpush support without coding yet another system.
  - mananaysiempre 4y ago
    I think GP got it backwards, actually: Web Push seems to have a wire interface for submission and a JavaScript API for subscription, while the internals of how the notifications get from e.g. the FCM backend to the notification drawer on your Android phone remain unspecified (and partly secret). UnifiedPush has a wire interface for both submission and subscription+reception, plus an Android(?) intent API for interacting with the client for the latter that’s running on your phone. It looks like the submission side of UnifiedPush could indeed have been Web Push-compatible but isn’t, though.

seydor 4y ago

I wish we could extend SMTP to support notifications as self-expiring emails

MayeulC 4y ago
It would also be nice to extend IMAP to support UnifiedPush... The use-case would be new mail notifications; it wouldn't be too hard to do, and would be quite useful, as I typically have multiple e-mail accounts. You could however build a UnifiedPush-compliant SMTP-based or IMAP-based distributor.
- karmanyaahm 4y ago
  JMAP has a push implementation I really like, and it's natively compatible with UnifiedPush. Would be nice to see more adoption there. https://jmap.io/spec-core.html#push https://jmap.io/spec-core.html#push
gsich 4y ago
Notifications would work (and does), maybe a sieve rule for deleting old messages?

afandian 4y ago

The headline got my attention. I'm looking for a standard for subscribeable notifications / callbacks to update users of data changes in an API. Bonus point for federated. But server to server, not server to client. Double bonus points for connecting to consumer services like Zapier or IFTTT. I'm planning to use WebSub and/or RSS, but on the look out for others. Any pointers?

MayeulC 4y ago
That use-case sounds a bit similar to Webmentions: https://en.wikipedia.org/wiki/Webmention https://en.wikipedia.org/wiki/Webmention See also... The See also section in that article :) You say it would be server to server, but are both publicly reachable?
- afandian 4y ago
  We're running an API, we want to say to users e.g. "we finished processing your submission" or "this API resource changed". And offer pull (e.g. RSS) and push flavour. > You say it would be server to server, but are both publicly reachable? So yes, the user would have to run a public server. But only for practical reasons, otherwise how can you push. Webmention isn't quite it, we're notifying about our own API Resources. Websub (FKA PubSubHubub) does. It just doesn't seem to be widely adopted for some reason.
kevincox 4y ago
WebSub + RSS/Atom is a good option for relatively slowly changing data. (Maybe at most a couple of times an hour). It is nice because it is opt-in and an enhancement on the regular polling API. Using WebSub or UnifiedPush would technically very similar but you need a way for the client to pass you the subscription information. WebSub has a standard discovery process to manage this.
- afandian 4y ago
  The WebSub spec looks disarmingly simple but also complete for everything I can think of. I've not yet tried to implement it, but I'm waiting for the catch! Thanks for the confirmation.

rgovostes 4y ago

Off-topic: Sometimes I work on ships that have Wi-Fi for talking to local services, but due to strict metering, Internet access is usually disabled. So most of the time there's no way to get notifications from monitoring systems and your fellow crew, let alone shoreside team members. It would be nice to have a solution for delivering pushes internally, and also hold open a best-effort connection to a remote server that allows some notifications through. The last solution I considered was running a Matrix homeserver on the ship with some local channels, and another instance on shore, and using federation to connect them when the uplink is available. Monitoring systems could send their alerts as DMs or to a shared channel. Then for the notifications, Apple has its Local Push Connectivity API you might be able to use to send notifications within the ship network. I'm not sure if this UnifiedPush would solve the problem on Android. Either way, though, it seems like a lot of engineering effort just for a chatroom.

karmanyaahm 4y ago
One of the first uses of UnifiedPush was to self-host the whole Matrix messaging stack. In fact, we have already had someone in the UnifiedPush chat set this up on their ship [1]. Matrix + UnifiedPush would be perfect for a disconnected situation on ships (or Mars colonies :) [1] https://matrix.to/#/!vwmBiTqilorqNCbGab:matrix.org/$hJpXxhVRhxMEJavlgsIFt-QyV3xCuMsveMl2dWRBUfk?via=libera.chat&via=matrix.org&via=envs.net https://matrix.to/#/!vwmBiTqilorqNCbGab:matrix.org/$hJpXxhVR...
- wereallterrrist 4y ago
  I'm a huge fan of Matrix and the idea of UnifiedPush, but I don't quite grok what this means (and I'm reluctant to fire up my Matrix client because I'm avoiding some things). Is there any chance you can elaborate on what "self-host the whole Matrix stack" means?
  - eternalban 4y ago
    I read the thread just now: ~" Self hosted matrix + UP. Nothing special there. Only issue is cert expiration for setups without connections that result in expired certs for https. That requires some work. "~

Andrew_nenakhov 4y ago

Oh gosh, a wheel reinvented again? XMPP did it ~7 years ago [0] and we have used it for quite a few applications already. [0]: https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html

binwiederhier 4y ago
Please be nice. You can convey your information without the snarky tone. You may be factually correct, but your comment comes across quite rude. From the HN guidelines [1]: > Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
kirimita 4y ago
From the blog post: > One key feature of UnifiedPush is that the communication between the push server and the distributor is not specified. This means that a variety of technologies can be employed, such as WebSockets, Server-Sent Events, *XMPP*, raw TCP, or even SMS, whatever works best for the user.
- Andrew_nenakhov 4y ago
  Sigh. What you miss is that this protocol introduces nothing that already isn't done by XMPP push notifications. It is decentralized, it can deliver to different endpoints, etc. You only need to create a dispatcher app that will relay the notifications to third party apps. Again, this too was done years ago.
  - kirimita 4y ago
    > You only need to create a dispatcher app that will relay the notifications to third party apps. That part is what specify UnifiedPush. It does not specify the communication between the push server and the distributor.
  - jacob019 4y ago

deleted 4y ago

[deleted]

mixtur2021 4y ago

AFAIK Modern Android (>= 8.0) reserves the right to kill your app when running in the background unless there's a foreground toast bound (even then, can still be killed in low memory situations). How does this solution work around that? Is there a need to opt into the legacy "battery saver disabled" mode for the app which more closely mirrors <= 7.0 execution model?

karmanyaahm 4y ago
Most distributors both show a foreground notification at all times and require exempting them from battery optimization. Because of its efficient design, something like ntfy only uses a few percent of battery per day [1]. System-level integration into Android ROMs would eliminate the need for those things. [1] https://docs.ntfy.sh/faq/?h=battery#how-much-battery-does-the-android-app-use https://docs.ntfy.sh/faq/?h=battery#how-much-battery-does-th...
- mixtur2021 4y ago
  Thanks! As I thought. Long lived sticky foreground notifications tend to annoy folks from my experience. Have you seen complaints?
  - MayeulC 4y ago
    I haven't seen any complaints, but folks who set this up are usually used to having persistent notifications (I currently have 6) without Google services. At least I replaced the one from my Matrix client with the UnifiedPush-enabled ntfy. Hopefully it'll replace Signal too at some point. KDE Connect? Why not. K-9 mail? I hope, but that would require JMAP or IMAP adjustments. One option would be to install the distributor as a system app.
  - binwiederhier 4y ago
    You can easily remove them. There are instructions here: https://docs.ntfy.sh/subscribe/phone/#instant-delivery https://docs.ntfy.sh/subscribe/phone/#instant-delivery

solarkraft 4y ago

Apps draining your battery to check for notifications is the worst thing about degoogled Android. With notifications enabled my telegram client can drain my battery in a very low number of hours (got suggestions here? any client supporting UnifiedPush?) So this is welcome, but it requires application support. And if apps on your phone use both GCM and UnifiedPush you still end up with multiple providers. But at least I think I can trust UnifiedPush to be light on my battery.

karmanyaahm 4y ago
> telegram client can drain my battery in a very low number of hours (got suggestions here? any client supporting UnifiedPush?) It's possible. There is nothing ready right now. [1] https://github.com/UnifiedPush/wishlist/issues/18 https://github.com/UnifiedPush/wishlist/issues/18 [2] https://github.com/Telegram-FOSS-Team/Telegram-FOSS/issues/577#issuecomment-1285880888 https://github.com/Telegram-FOSS-Team/Telegram-FOSS/issues/5...
binwiederhier 4y ago
It's really not that bad. It uses 1% of battery for 17h. Sometimes even less than that and it shows 0% after the entire day. So it's a hypothetical problem IMHO. There are very few cases or phones i see these days where people complain about battery: https://docs.ntfy.sh/faq/#how-much-battery-does-the-android-app-use https://docs.ntfy.sh/faq/#how-much-battery-does-the-android-...
- solarkraft 4y ago
  The reason I said it is that it's a problem for me. Notifications on/off makes a night and day difference. Did you link ntfy because that's what Telegram FOSS uses?

janosdebugs 4y ago

This is a nice concept, but I owned more than one Android phone that would ignore the battery optimization settings and kill the applications anyway.

binwiederhier 4y ago
I have been working and running ntfy [1] on my phone for a year now (ntfy is a UnifiedPush distributor), and it is true that Android does kill the app every now and then. But it is instantly restarted. Usually ntfy delivers notifications much much much faster than Google's FCM, especially in doze mode. FCM seems to try and conserve battery much more. Disclaimer: I am the maintainer of ntfy. [1] https://github.com/binwiederhier/ntfy https://github.com/binwiederhier/ntfy
- janosdebugs 4y ago
  Sadly, I had phones where I couldn't keep anything running. Not sure what the manufacturer did there. Even the normal notifications didn't arrive at times. (E.g. Signal)

satvikpendem 4y ago

I'm using Google Firebase Cloud Messaging [0] which allows pushing notifications to devices even if they're asleep, unlike local notification services where the device must be awake and the app must be active. Will this service allow the same thing FCM does, including waking up the device? I'm looking at both iOS and Android devices, I see there's Flutter available but not iOS necessarily in the docs [1]. Related question, will the Flutter version also work for iOS devices? I know FCM (and its Flutter SDK) works for both, as well as web. [0] https://firebase.google.com/products/cloud-messaging https://firebase.google.com/products/cloud-messaging [1] https://unifiedpush.org/developers/intro/ https://unifiedpush.org/developers/intro/

karmanyaahm 4y ago
Yes, this is an FCM replacement on Android (and it can easily fall back to FCM if the user doesn't have UnifiedPush). There is no native UnifiedPush on iOS because Apple doesn't allow background services. The server side to support both is simple, but on the client you would need code for both FCM (for iOS) and UP (for Android). It would be interesting to build an FCM wrapper for iOS into the UP Flutter library.
- satvikpendem 4y ago
  I don't know too much about this, but is this not APNs [0]? I see there is a FCM integration (which is how I assume FCM does it anyway) [1] as well as a standalone Flutter implementation [2]. How would iOS native only apps on Swift do push notifications, surely Apple has their own service and everyone doesn't use Firebase? [0] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns https://developer.apple.com/documentation/usernotifications/... [1] https://firebase.flutter.dev/docs/messaging/apple-integration/ https://firebase.flutter.dev/docs/messaging/apple-integratio... [2] https://pub.dev/packages/flutter_apns https://pub.dev/packages/flutter_apns
  - karmanyaahm 4y ago
    I recommended FCM for iOS instead of APNS because OP is already using it. For iOS clients, FCM just forwards notifications to APNS.

mgaunard 4y ago

There are two things I still don't get about software development: - why is web development such a big thing - why is app development a thing at all

Alifatisk 4y ago
I believe web dev is huge because it’s cross-platform by default & easy to get started with.
palata 4y ago
You mean "why is software development a thing" there? Not sure what your point is...

anotherevan 4y ago

Any possibility this will mean I can push a notification from my home automation that gets displayed on my Google TV?

artificialLimbs 4y ago
If it can call a site, it can use ntfy.

MinaMe 4y ago

[flagged]

sohkamyung 4y ago

Interesting. This could have interest from China, since they have to use Android without the Google push service, causing battery drain issues. They are trying to come up with their own push notification service. The issue is highlighted in this article [1]. [1] https://www.sixthtone.com/news/1011308/the-real-story-behind-chinas-battery-draining-push-notifications?source=channel_home https://www.sixthtone.com/news/1011308/the-real-story-behind...

w4eg324g 4y ago

Why is it named decentralized when it uses a central server to route/distribute the messages?

LinAGKar 4y ago
Because you can host your own server, rather than everyone using the same server

deleted 4y ago

[deleted]

javaunsafe2019 4y ago

Please don’t get me wrong but I wonder what is the use case for this. First of all this tries to solve a problem that has already been solved by the mobile device OS layer within IOS and Android and furthermore is only working for Android. Why should anyone use this?

agsnu 4y ago
It looks like this aims to be a replacement for people want to use an Android-based OS but don't want to rely on Google services, normally for reasons of philosophical objection to big tech's de facto surveillance capabilities. So presumably users of GrapheneOS, CalyxOS, LineageOS, etc. Also since Google is blocked in China, Firebase Cloud Messaging doesn't work there. Android has something like a 75% market share in that market. Some vendors have their own offerings (e.g. Xiaomi MiPush, Huawei PushKit) etc, I could buy that a popular centralised solution would be more attractive than doing N integrations.
- MayeulC 4y ago
  This. It also works without internet connection if you want push notifications within a LAN. The vision is that you only need to implement support for 1 integration: UnifiedPush, possibly by embedding one of the libraries that manage it and fallbacks. You automatically gain support for compatible alternatives. There's a variety of reasons why people can't or don't want to rely on Google services. Before UnifiedPush, one would have to "hardcode" an alternative, or more commonly implement a persistent connection within the app. This also has some potential for more efficient push implementation: for instance, if you have access to an SMS gateway, you could use that to push notification without enabling data connection. The specification also makes it easier to support third-party operating systems and clients.
- javaunsafe2019 4y ago
  Thanks for explaining and giving context - I was totally not aware of this total block of Google in the Chinese market.

joelthelion 4y ago

Would this be vulnerable to spam?

MayeulC 4y ago
Each application gets a unique URL, that is supposedly kept secret from any other party. They are also very easy to rotate, as the specification advises to ask for a new one (that could be the same) on every app launch. Moreover, when something is sent to that URL, it gets forwarded to the application, which then interprets it before displaying a notification (for most apps). By spam, I think you meant someone sending messages to random people's notification area. No, this is highly unlikely.

amelius 4y ago

This sounds like it could be the reverse of REST, so could be pretty important and perhaps it can grow into a W3C spec.

MayeulC 4y ago
That's an interesting thought, but currently the Server-Server specification is quite trivial, the more complicated part is the Android (and Linux) API, which I don't think the W3C would cover. There's definitely room for adoption within the freedesktop.org umbrella for the Linux part, once this part is a bit more mature.