7 ms·

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-

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
    So what! Few use that. I host a prosody server with lots of plugins and it never occurred to me to use it, let alone use cases outside if the XMPP ecosystem. Can the XMPP implementation fall back to google's push system. Does it have a blog entry, lovely diagrams, comprehensive docs, a nice on-boarding experience for developers? Ideas aren't worth much, implementation--getting things done is what matters.
MayeulC 4y ago
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.
- Andrew_nenakhov 4y ago
  You seem to not see the forest behind the trees. It doesn't do 100% of what your UnifiedPush does, sure, but it does 99%. All it needs to reach the final 1% is to send a message with an agreed payload format to a client. A day of work. 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). > Please make an effort to come across as less antagonizing in the future. Someone has to antagonize people who ignore prior art.
  - MayeulC 4y ago
    > 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/ https://bubu1.eu/openpush/

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
  So what! Few use that. I host a prosody server with lots of plugins and it never occurred to me to use it, let alone use cases outside if the XMPP ecosystem. Can the XMPP implementation fall back to google's push system. Does it have a blog entry, lovely diagrams, comprehensive docs, a nice on-boarding experience for developers? Ideas aren't worth much, implementation--getting things done is what matters.

MayeulC 4y ago

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.

Andrew_nenakhov 4y ago
You seem to not see the forest behind the trees. It doesn't do 100% of what your UnifiedPush does, sure, but it does 99%. All it needs to reach the final 1% is to send a message with an agreed payload format to a client. A day of work. 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). > Please make an effort to come across as less antagonizing in the future. Someone has to antagonize people who ignore prior art.
- MayeulC 4y ago
  > 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/ https://bubu1.eu/openpush/