Live data from Hacker News

UnifiedPush: A decentralized, open-source push notification protocol

f-droid.org

91–100 of 150 posts

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

#92
post #2

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/ 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, t…

Does the user require to install a separate app to receive UnifiedPush messages?

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?

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

#93

Earlier quoted context omitted.

Does the user require to install a separate app to receive UnifiedPush messages?

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?

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

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

#94

Earlier quoted context omitted.

> 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?

I mean yes, but if Google catches you, you're not going to have a good time. It's also incredibly inconvenient.

Also, you cannot specify the exact time when it's supposed to run, so it's likely they will just run at the same time.

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

#96

Earlier quoted context omitted.

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

Thanks! As I thought. Long lived sticky foreground notifications tend to annoy folks from my experience. Have you seen complaints?

You can easily remove them. There are instructions here: https://docs.ntfy.sh/subscribe/phone/#instant-delivery

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

#97

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…

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

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

#98

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.

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

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

#99

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…

In addition to what the others wrote (a local Matrix server and UnifiedPush provider such as ntfy would work fine), I suggest you look into p2p messaging systems such as Briar. I think Tox is also p2p?

Lastly, Secure Scuttlebutt was actually designed on a boat for sporadic internet connection and local connections, as well as sneakernet, so that would work too, but I don't think it's designed for IM. Perfect for blogs or facebook-like stuff though.

Have a member of the crew go onshore up to a Wi-Fi AP, it will act as an async data transfer for everyone. You can also exhange data with other travellers, including passing boats.

Interestingly, there are a few Matrix p2p experiments. I wish apple opened their Airdrop feature as that would make proximity networking easier, though that should be achievable with Wi-Fi NAN+P2P.

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

#100

Earlier quoted context omitted.

UnifiedPush is compatible with WebPush: both just involve an HTTP POST to a specific URL. If your application server supports WebPush, it can send encrypted notifications to UnifiedPush servers (that is how we're planning to support Telegram, for example). You can then decrypt these notifications in the app [1]. However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix r…

> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for u…

I agree, though it of course it depends on the threat model. As a self hoster, encryption is pretty much irrelevant, as my push server is controlled by myself, and accessible with https. Not having encryption makes it easy to debug and experiment.

I agree encryption should be the default choice though. Maybe we can introduce it in a future protocol revision? Client side, I expect most people use libraries, making this easy. Server side? Not so much.

The main goal was to get it adopted as widely as possible though, and encryption certainly seemed like something that would slow the effort.

Post reply on HN