UnifiedPush: A decentralized, open-source push notification protocol

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

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.

Ah, thanks for the correct term. I am not sure the specification is open enough for other operating systems to support it, which is what I meant.

Among my acquaintances, I can count Apple users on a single hand (There's OWL [1] which looks promising on Linux. I hope Android devices can get something soon. I'm still a bit confused by how Linux drives Wi-Fi radio, and what is and isn't implementable in software: could older Android devices gain support for NAN and OWL through a software update? What about old computers with old Wi-Fi cards?

I first got aware of Wi-Fi NAN by chatting with neilalexander on #yggdrasil:matrix.org :)

It looks promising for advertising capabilities to nearby hosts, allowing to negotiate p2p connections.

[1]: https://owlink.org/

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.

> You seem to not see the forest behind the trees

I almost used my sentence myself. The overlap is almost zero.

> All it needs to reach the final 1% is to send a message with an agreed payload format to a client.

This is the part we're interested in. We standardize this part and make it modular. The core issue is that multiple "client"s that do not interact with each other traditionally each implement their own payload format and background connection. Which drains battery. We propose a mechanism to delegate that to a third-party that can then multiplex those messages. That's all.

It's not a lot of work per se, but coming up with a modular API is not that trivial either, and we have to spread the word so that it can be used by multiple projects.

Lastly, you seem pretty focused on XMPP clients. Unfortunately (or maybe fortunately), not every app uses XMPP. On my phone, apps that could theoretically use UnifiedPush are: NextCloud, Etar Calendar, DavX5 caldav synchronization, K-9 mail, Element & others Matrix clients, HomeAssistant, FindMy & other device locators, covid tracker, Carnet notes application, Fennec (Firefox), KDE Connect, Mobilizon, Peertube Client, UnCiv, and various others, including chat apps and weather apps. XMPP would bring very little to those, especially as they just need that "1%" functionality you quoted.

There is some overlap indeed, as there is a server-server API. However, 99% of the spec you linked is completely useless or overkill for our use-case. We just accept POST requests to an endpoint and forward them to the app running on a user's device.

> As I said, we did it as far back as 2016: a watered-down XMPP client (a "distributor", as you call it) was used to deliver push notifications to a few different apps on devices that didn't have GCM (as it was called then).

That's pretty good indeed; was the specification open so that other apps could join in? Do you mind sharing a link? You can just implement the UnifiedPush specification in that distributor, make sure the server-side part accepts requests in the format specified, and you have a UnifiedPush-compliant application that other apps can use.

I've been looking for such a specification for a while, there's been some talks around the topic for years, including OpenPush [1], but nothing concrete or public that I know of. The link you shared in your previous comment does not address the "distributor" part.

> Someone has to antagonize people who ignore prior art.

Well, please at least try to understand the thing you're criticizing before, that's the bare minimum.

[1]: https://bubu1.eu/openpush/