UnifiedPushThank you @notnotrachit for sharing your experience of implementing notifications "the FOSS way" in this blog post!
https://dev.to/dilutewater/implementing-app-notifications-the-foss-way-lc2
Ærion@unifiedpush
Even as a non-developer, I found this well written article of great interest. It explained a few things about #UnifiedPush I wasn't aware of, and has given me better insight into how it functions.
It's clear now that there simply isn't any excuse for developers to use #FCM for notifications. I sincerely hope UnifiedPush will gain traction, not only amongst #FOSS developers, but the Android developer community at large.
It's perhaps worth noting that users of #Conversations (and its forks) already have a distributor included in their client, thus further lowering the bar of entry.
dotslash@aerion @unifiedpush @notnotrachit @daniel @snikket_im This is a really great write-up.
One thing I still don't understand is, how does the backend know which server to send the notification to?
When the user chooses a distributor, is the app sending the distributor's URL to the backend, which then associates the app/user with that URL?
Rachit Khurana@dotslash @aerion @unifiedpush @daniel @snikket_im
Hi, yes, great question, I think I should have cleared it in the blog as well.
Yes, when the device registers for the notifications, it should send the registration data: endpoint, auth token and the p256dh encryption key.
The backend will then use this to send the notification. (you can use any webpush library on the backend to handle this)