UnifiedPush: A decentralized, open-source push notification protocol
91–100 of 150 posts
Re: UnifiedPush: A decentralized, open-source push notification protocol
#92Wow, 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?
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
#93Earlier 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?
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
#94Earlier 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?
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
#95Re: UnifiedPush: A decentralized, open-source push notification protocol
#96Earlier 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?
Re: UnifiedPush: A decentralized, open-source push notification protocol
#97Apps 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…
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
#98This is a nice concept, but I owned more than one Android phone that would ignore the battery optimization settings and kill the applications anyway.
Disclaimer: I am the maintainer of ntfy.
Re: UnifiedPush: A decentralized, open-source push notification protocol
#99Off-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…
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
#100Earlier 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 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.