Live data from Hacker News

UnifiedPush: A decentralized, open-source push notification protocol

f-droid.org

81–90 of 150 posts

Re: UnifiedPush: A decentralized, open-source push notification protocol

#81

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 que…

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.

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/...

[1] https://firebase.flutter.dev/docs/messaging/apple-integratio...

[2] https://pub.dev/packages/flutter_apns

Re: UnifiedPush: A decentralized, open-source push notification protocol

#82

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 th…

I've been using NNTP as a Gossip-type protocol for eventually-consistent pub/sub telemetry, monitoring, and notifications between partially-connected nodes in an unstable mesh since about 1995.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#83
post #33

Earlier quoted context omitted.

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.

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…

I would imagine Huawei is doing that moreso due to sanctions, no?

Re: UnifiedPush: A decentralized, open-source push notification protocol

#84

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

It seems like you have misunderstood something.

I just read the specification you linked. If I understand it right, it just specifies what we call a "Push gateway" in our last diagram in the "under the hood" section.

As in, it specifies how multiple servers can connect to a single (XMPP-speaking) push server. This is also evident from the excerpt I'm quoting:

    >XMPP Push works between the user's XMPP server and two push notification services in tandem:

    >    The user's XMPP server publishes notifications to the XMPP Push Service of each of the user's client applications.
    >    The XMPP Push Service (as defined here) for a client application then delivers the notification to a third-party notification delivery service.
    >    The third-party (and potentially proprietary or platform-dependent) push service delivers the notification from the client application's backend service to the user's device.

UnifiedPush is the third-party push (or notification delivery) service here. Please make an effort to come across as less antagonizing in the future.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#85

Earlier quoted context omitted.

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.

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/... [1] https://firebase.flutte…

I recommended FCM for iOS instead of APNS because OP is already using it. For iOS clients, FCM just forwards notifications to APNS.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#86

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 th…

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/$hJpXxhVR...

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?

Re: UnifiedPush: A decentralized, open-source push notification protocol

#88

Earlier quoted context omitted.

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/$hJpXxhVR...

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?

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. "~

Re: UnifiedPush: A decentralized, open-source push notification protocol

#89

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

I believe web dev is huge because it’s cross-platform by default & easy to get started with.

Re: UnifiedPush: A decentralized, open-source push notification protocol

#90

>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 i…

> 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.) The protocol does not specify how the distributor and push server communicate or keep a connection going. It'…

could the 15 minute limit be circumvented with multiple identical apps (different package names) installed?
Post reply on HN