Publish in F-Droid.

[KOLANICH]

No description provided.

[X1nto]

I'll keep this issue up just to show progress, since I'm planning to publish the app to F-Droid

[Poussinou]

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.

[rushiiMachine]

OpenCord is still nowhere close to being stable We could eventually release the stable release stream to fdroid however there is going to be an in-app updater anyways

[nyakowint]

I love GitHub

[Mattrazol]

Up

[Ushie]

Down

[nyakowint]

Explode

[Degl1]

literally no new commits since the issue was initially opened

[X1nto]

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.

[KOLANICH]

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.

[X1nto]

I don't think so. And F-Droid allows marking packages as previews AFAIK.

You may not think so but we, maintainers, think so.

[rushiiMachine]

What purpose is a preview package when it's broken
Just use github

[rushiiMachine]

Also, once we add notifications this will no longer be eligible for fdroid (at least with notifications) because of gcm libs

[ashley-graves]

Also, once we add notifications this will no longer be eligible for fdroid (at least with notifications) because of gcm libs

UnifiedPush

[rushiiMachine]

I already took a look, and we can't really use that
Discord doesn't support it

[ashley-graves]

Could maybe try using a Foreground service that's always connected to the Gateway to get message motifications?

[rushiiMachine]

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

[rushiiMachine]

UnifiedPush

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

[X1nto]

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

[mariobrostech]

@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.

[ashley-graves]

UnifiedPush

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

[X1nto]

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

[ashley-graves]

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.

[mariobrostech]

@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.

[rushiiMachine]

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

[X1nto]

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]

@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

[mariobrostech]

@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.

[X1nto]

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

[ashley-graves]

It's just FCM btw, GCM has been deprecated since 2018.

[X1nto]

The first 2 checks are done server side, meaning client doesn't have to waste resources on them. For a custom solution, we'd have to do everything on the client, which would include expensive checks for muted channels (it's API calls. Caching them wouldn't work because it needs to be properly synced between clients).

The most important thing is that Discord's mobile apps don't receive notifications as long as the desktop app is active. Now this is truly impossible for us to check.

[X1nto]

It's just FCM btw, GCM has been deprecated since 2018.

I know, it's just some people still refer to it as GCM.

[mariobrostech]

Yes we could indeed do a separate build. There's also a possibility of microG if you want to consider that

I think that a separate Gradle build flavor would be a good compromise if someone's willing to do the work on implementing it. That way, normal users would have a seamless experience using FCM, and users who desire the open-source build that doesn't rely on GMS can still receive notifications with the FOSS variant. I wouldn't really consider microG an alternative because it needs to be implemented at the OS-level, and many people either can't or won't switch to a custom OS just to remedy this.

[rushiiMachine]

For reference, this is the reciever for FCM events is from Discord in the old android client.

[TheLastProject]

Hey, busy discussion :)

I just want to put a sidenote here that https://unifiedpush.org/developers/embedded_fcm/ option 2 exists, which talks with Google servers but uses a FOSS reimplementation. You're still talking to Google with FCM, but you need no proprietary library included in your app and can publish on F-Droid. I think it still needs Google Play Services or microG though.

IIRC this is based on what the Mastodon Android app does, but the UnifiedPush Matrix surely knows more :)

[X1nto]

I think that a separate Gradle build flavor would be a good compromise if someone's willing to do the work on implementing it. That way, normal users would have a seamless experience using FCM, and users who desire the open-source build that doesn't rely on GMS can still receive notifications with the FOSS variant. I wouldn't really consider microG an alternative because it needs to be implemented at the OS-level, and many people either can't or won't switch to a custom OS just to remedy this.

A custom build flavor is indeed what I'm talking about. But, keep in mind that our priority will be the FCM receiver until it's complete or some FOSS implementation of it appears out of thin air.

[X1nto]

Hey, busy discussion :)

I just want to put a sidenote here that unifiedpush.org/developers/embedded_fcm option 2 exists, which talks with Google servers but uses a FOSS reimplementation. You're still talking to Google with FCM, but you need no proprietary library included in your app and can publish on F-Droid. I think it still needs Google Play Services or microG though.

IIRC this is based on what the Mastodon Android app does, but the UnifiedPush Matrix surely knows more :)

Aaaaand just as I said it, a FOSS impl of FCM just popped up. What a wonderful life it is

[mariobrostech]

@X1nto Thanks for the detailed explanation, I really appreciate it! As an end-user, it's rare to see how FCM actually works from a dev's perspective. I totally understand if implementing a custom solution isn't a priority for the project, but it would certainly be nice to have (and, I know I'm not alone in that thinking, as evidenced by the other activity in this discussion).

[mariobrostech]

The most important thing is that Discord's mobile apps don't receive notifications as long as the desktop app is active. Now this is truly impossible for us to check.

I know it isn't quite the same thing, but Signal's WebSocket implementation manages to not deliver push notifications if the chat was already marked as read or opened on another device. Could a similar implementation work here, or is it more complicated to check if the desktop client is open at all vs. just on a specific chat?

[rushiiMachine]

The most important thing is that Discord's mobile apps don't receive notifications as long as the desktop app is active.

You can listen to sessions_replace, but this means processing more events and caching more things

[ashley-graves]

Hey, busy discussion :)

I just want to put a sidenote here that https://unifiedpush.org/developers/embedded_fcm/ option 2 exists, which talks with Google servers but uses a FOSS reimplementation. You're still talking to Google with FCM, but you need no proprietary library included in your app and can publish on F-Droid. I think it still needs Google Play Services or microG though.

IIRC this is based on what the Mastodon Android app does, but the UnifiedPush Matrix surely knows more :)

The UnifiedPush FCM implementation seems to require a FCM Rewrite proxy, which seems to also need the Firebase Secret Key.

[X1nto]

I know it isn't quite the same thing, but Signal's WebSocket implementation manages to not deliver push notifications if the chat was already marked as read or opened on another device. Could a similar implementation work here, or is it more complicated to check if the desktop client is open at all vs. just on a specific chat?

What we could do is check if the channel is marked read or not, but I'm not sure how awful the synchronization would be with that approach. I honestly don't know as we've never tried it before, but if we ever try that, we would want the core of the app to work flawlessly (as in, current active sessions for example), which will take time before it gets stabilized. This is something I don't really know but trying it out won't be easy either, at least until the core is stable

[mariobrostech]

Fair enough, I totally understand that. If you do end up testing it, though, please report back with your results because I'd be interested to see what the performance impact is like in the real-world. 🙂

[marek22k]

I do not know if you could use it, but there is also https://ntfy.sh/.

[Henry-Hiles]

It would be perfect if ntfy could be used

[rushiiMachine]

You'd need to host a gcm receiver to redirect it to the ntfy server anyways

[ghost]

Hi, I would love to see this app on F-Droid. When is it getting published?

[Henry-Hiles]

Probably won't be until more features are added.

[rushiiMachine]

on fdroid? maybe maybe not
the primary release stream will be through github & inapp updater
fdroid is just a pain

[ghost]

the primary release stream will be through github & inapp updater

If there's an in-built automatic updater within the app, I'm cool with that. I just want my apps to stay up-to-date.

[marek22k]

Is there any news in the meantime?

[X1nto]

The development is on halt.

[marek22k]

The development is on halt.

Is there a special reason for that?

[X1nto]

Is there a special reason for that?

we don't have time (for now) to maintain OpenCord. It also needs a good rewrite from the scratch.

[AkechiShiro]

@X1nto I guess either someone steps in for the rewrite or this project will slowly be archived someday as an attempt go make an open source Discord ?