OpenCord
OpenCord copied to clipboard
MateriiApps
Publish in F-Droid.
I'll keep this issue up just to show progress, since I'm planning to publish the app to F-Droid
Hi have not seen any proprietary library nor precompiled jar or aar in the repo, so it should be ok.
Could you please in the meantime tag your releases (have a look here and here for some help), attach a signed release APK to it. It would be helpful for us at F-Droid to include the app, and would allow people to be sure to get a stable app.
OpenCord is still nowhere close to being stable :trollface: We could eventually release the stable release stream to fdroid however there is going to be an in-app updater anyways
literally no new commits since the issue was initially opened
I don't think you understand the difficulty of reverse-engineering apps. Publishing to F-Droid requires OpenCord to have a minimum set of features available and be as stable as possible.
Publishing to F-Droid requires OpenCord to have a minimum set of features available and be as stable as possible.
I don't think so. And F-Droid allows marking packages as previews AFAIK.
I don't think so. And F-Droid allows marking packages as previews AFAIK.
You may not think so but we, maintainers, think so.
Also, once we add notifications this will no longer be eligible for fdroid (at least with notifications) because of gcm libs
Also, once we add notifications this will no longer be eligible for fdroid (at least with notifications) because of gcm libs
I already took a look, and we can't really use that Discord doesn't support it
Could maybe try using a Foreground service that's always connected to the Gateway to get message motifications?
That would drain your battery in 5 seconds Discord's gateway connection is not a lightweight thing (heartbeat, events every 2 seconds) It would prevent your wifi/data reciever from ever going into sleep mode, if the service even lives long enough before android kills it for some reason
If unifiedpush supports having a custom private event emitter, then you could technically self-host a notification proxy that connects to the gateway and emits important events to unifiedpush from your pc
Also, running a foreground service would require OpenCord to dispatch an annoying "I'm running my service" notification, which can't be dismissed (at least until Android 13) as well as constantly apply changes to the DB, as well as causing it to shit itself if Android decides to kill this service for many reasons
@rushiiMachine I don't see why this would be something that's so difficult to implement. I'm not saying that it would be easy because no development is, but other apps have similar notification systems and don't "drain your battery in 5 seconds." Sure, it consumes slightly more power to have every app on your phone listening for notifications, but that's what UnifiedPush is attempting to fix. Even without UnifiedPush, using SSE or WebSockets for push notifications is more than good enough for many users (including myself), and the slightly higher battery usage is just price that you have to pay to not have to depend on Google Play Services (at least for now). There's a good blog post from Tutanota on this (particularly towards the beginning where they talk about alternatives to FCM) that's definitely worth a read if you're interested.
If unifiedpush supports having a custom private event emitter, then you could technically self-host a notification proxy that connects to the gateway and emits important events to unifiedpush from your pc
it does, and yeah could do.
Also, running a foreground service would require OpenCord to dispatch an annoying "I'm running my service" notification, which can't be dismissed (at least until Android 13) as well as constantly apply changes to the DB, as well as causing it to shit itself if Android decides to kill this service for many reasons
it can be dismissed on any android version by manually turning the notification off, and you can prevent android from killing it by prompting the user to turn disable battery optimization for the app
it can be dismissed on any android version by manually turning the notification off, and you can prevent android from killing it by prompting the user to turn off battery optimization for the app.
Still doesn't change the fact that it's a huge memory hog. Also, this would require us to constantly check whether or not the user has muted the channel or not before dispatching a notification, which will result in an additional bandwidth/battery life cost. It's better to just receive from the Firebase or whatever discord is using to dispatch notifications
I'd rather shorten my battery life by 10 minutes than be required to flash proprietary Google spyware for notification support on an open-source Discord client.
@X1nto FCM should be the default for standard releases of the app, no doubt, since it presents the least amount of friction for normal users. However, for an F-Droid build, you could distribute a FOSS flavor which uses SSE or WebSockets for notifications. Yes, it would consume more battery to do so and requires the user to disable the sticky notification stating that OpenCord is listening for notifications in the background, but most F-Droid users would expect this as it's normal behavior for many apps that are distributed on F-Droid already. Technically speaking, how would implementing SSE or WebSockets for push notifications be any different from using GCM? That's a genuine question, since I'm interested to hear the difference in implementation between the two.
I don't see why this would be something that's so difficult to implement.
Have you seen how complex the gateway connection is? Other apps that support notifications through a service like Signal or Whatsapp have their websocket as simple and least resource-intensive as possible. This includes handling blocked messages, silenced channels, etc. before it even reaches the device. Lets walk through how this would be done with the regular gateway in Discord:
- Listen to events (scales MASSIVELY the more servers you are in)
- Heartbeat (again, your wifi can never go to sleep, draining your battery)
- Load the cache DB to check for current user, muted channels, blocked users, etc...
- Only then deploy the notification
This wouldn't just shorten your battery by 10 minutes, not even close And then we would get complaints of opencord being too battery draining. no wonder
you can prevent android from killing it...
No, not really. Some vendors are just pure evil
I'd rather shorten my battery life by 10 minutes than be required to flash proprietary Google spyware for notification support on an open-source Discord client.
We think it's very irrational to use a foreground service, for an optional separate build maybe we could do that, but not for the main build.
@X1nto FCM should be the default for standard releases of the app, no doubt, since it presents the least amount of friction for normal users. However, for an F-Droid build, you could distribute a FOSS flavor which uses SSE or WebSockets for notifications. Yes, it would consume more battery to do so and requires the user to disable the sticky notification stating that OpenCord is listening for notifications in the background, but most F-Droid users would expect this as it's normal behavior for many apps that are distributed on F-Droid already. Technically speaking, how would implementing SSE or WebSockets for push notifications be any different from using GCM? That's a genuine question, since I'm interested to hear the difference in implementation between the two.
Yes we could indeed do a separate build. There's also a possibility of microG if you want to consider that
@rushiiMachine Ok, that all makes sense. But, how is what you described any different than using FCM instead? Does FCM somehow solve all of those problems just by implementing it? Or, am I missing something? Because it seems to me like FCM would have to take the same precautions to avoid excessive battery drain.
As for how it's different from GCM/FCM, first of all, GCM/FCM comes directly from their perspective servers. Those servers check every condition on before sending a notification, meaning the client doesn't have to do anything but display the notification. Such checks include but are not limited to:
- Checking if the user muted the notifications for the discord guild channel.
- Ensuring the notification displays the correct user avatars, guild names, etc by sending those items inside the notification payload. The client only has to build the notification with provided parameters and display it.
- It respects Android's background work properly, which includes battery optimizations.
- It respects the user's bandwidth, as in metered connection, mobile data and etc.
- The setup of GCM/FCM is much easier compared to custom solutions