Hey guys, I’ve been wondering if something needs to be implemented into the diaspora code or if it’s already capable of android notifications. Currently the dandelion app does not feature notifications, and the dev has given up. Is it just a matter of implementing Google Firebase or does the diaspora code itself not make it possible yet?
Mobile notifications are essential to social media sites, so to be honest I don’t see my pod lasting long without it. Is this something that someone with experience with diaspora objects could put together or give a general guidance that maybe even I could attempt to put together? I’m not a dev, more of a script runner, but like I said my pod surviving is in the hands of this feature so I must try if no one else can.
Appreciate this platform, really do prefer it to other private self-hosted platforms, which also end up without an API for mobile notifications…
Sorry to hear that the Dandleon app gave up.
There is an official Diaspora app inspiration* for Android and iOS. The iOS Version is even in the App Store. You can load the Android Version by F-Droid repo, just read the readme.
However neither apps still support push notification, although the app is prepared for them.
What it needs is not a trivial task, Pods can not communicate directly with the app but must use a broker (Firebase for example) for sending out notifications to the android and iOS system.
On the Diaspora site there should be some kind of hook when a web-notification is created to send out to the service.
A Mapping User → device ID must be set. This can be done in the App, when the app starts and initially connects to a pod.
Both FCM and APNS require secret tokens we can not and would not be allowed to publish, this means true push notifications are only possible with a central broker per application. This is a little against the design philosophy of diaspora*, not to speak of potentially high operational costs that would need to be footed by the app developers. The only real “decentral” solution I see is having a background tasks that polls for notifications every now and then. Of course that’ll incur a slightly higher battery and data usage.
True third party email applications usually face the same challenge and choose a background polling approach.
XMPP applications are another example facing this, the probably most popular one, Conversations, chooses the broker approach. See XEP-0357 for the technical details.