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?
S1mThe application sends it. For example, on mastodon this is with this API: https://docs.joinmastodon.org/methods/push/#create
We can see that the field subscription[endpoint] is required (as well as the keys to encrypt the notifications)
@S1m so the flow is like this:
1. An app asks the user to choose a distributor like ntfy.
2. The app requests an unique URL from the ntfy-app.
3. It sends this unique URL to its own backend server. For mastodon this would be the API method you provided.
4. When there is a event, the mastodon backend sends the notification via web push to the unique URL.
Did I get this right?
@dotslash Exactly