Publish app on f-droid

[sedrubal]

Summary

Some users don't have google play store but f-droid. Is it possible to provide free builds (with only free and open source libraries)? I don't know if it's possible to build this app with the tools provided by f-droid...

[enahum]

you could build the app using your own keystore, for now we don't have the apk available for download

[lfbrock]

@sedrubal - apk files are provided now for official released versions on our GitHub releases page: https://github.com/mattermost/mattermost-mobile/releases

[sedrubal]

Thanks, this helps a lot. But bringing the app to fdroid would help even more...

[Poussinou]

Yep an official release on F-Droid would help

[jpggithub]

It seems that there is problems for building mattermost apk on f-droid See https://f-droid.org/wiki/page/com.mattermost.mattermost and https://forum.f-droid.org/t/monthly-development-reports/166/13

[marmistrz]

Does Mattermost depend on GCM/Play Services? It looks like it does.

[enahum]

@marmistrz it does for push notifications

[marmistrz]

@enahum this means that for Mattermost to get accepted into F-Droid it would either have to have another notification system, e.g. by polling, idle TCP or web sockets. (idle TCP is what XMPP uses).

[ArchangeGabriel]

And web sockets are what Signal uses I think. Also Riot. They are a lot of great OSS that use GCM/FCM/Play Services but also have the option to compile for F-Droid without those libs using alternatives implementations. ;)

[Rudloff]

I would be very interested in a version without Play Services, even if it means having no push notifications.

[Poussinou]

Very interested too (even if it's without notification), I use it at school instead of Slack :)

@IzzySoft maybe you could do something in the meantime? ;)

[IzzySoft]

@Poussinou you certainly thought about something like this? Yes, I could indeed. But someone should have an eye on that riskware thingy VT reports, maybe. And as for the official repo: a different flavor without those Google dependencies would certainly help.

[Poussinou]

Yep, that was what I thought about :) @IzzySoft Are you ok if I ping you when I find an Android app that is not (yet) in the official F-Droid repo and has .apk available for download, so that you can include them in your own repo?

[IzzySoft]

@Poussinou sure. Or just go here: https://gitlab.com/IzzyOnDroid/repo and file an issue with the data, like it's done for F-Droid as well :wink:

[Rudloff]

We patched the old Mattermost Classic app to remove Google Play dependencies: https://gitlab.com/fdroid/fdroiddata/blob/f6758e60af063658e8b6d38aa1c3ba1f2a3b718b/metadata/com.mattermost.mattermost/play-services.patch

But the new React app is harder to patch because two libraries require Play services:

• https://github.com/rebeccahughes/react-native-device-info/issues/381
• https://github.com/wix/react-native-notifications/issues/207

Edit: Mattermost Classic has been published on F-Droid.

[Rudloff]

I patched mattermost-mobile so it could be included in F-Droid: https://gitlab.com/fdroid/fdroiddata/blob/ef9895cd885c90fb0d6f4c4b3955f34f61f6ac65/metadata/com.mattermost.rnbeta/play-services.patch I had to remove the native Youtube player and all the GCM (push) functions.

However, the F-Droid team is not willing to maintain this patch in the long run. So would the Mattermost team accept a PR to add a Gradle build flavor that builds without Play dependencies?

[hmhealey]

Hi @Rudloff, if it can be done conditionally, we'd certainly accept a PR for it. Preferably, it would be configured using an environment variable like we use to enable and disable Sentry integration at build time https://github.com/mattermost/mattermost-mobile/blob/master/android/app/build.gradle#L82

[Rudloff]

Great! We usually use build variants but I guess an environment variable would work too. I will try to work on a PR next week if I have enough free time.

[hmhealey]

Those might also work. I'm not too familiar with them myself, so I was just suggesting what I've used in the past.

[drzraf]

Any plan to provide an alternative to GCM? Couldn't MQTT be a promising alternative protocol? AFAIU https://github.com/mattermost/mattermost-webrtc/blob/master/Dockerfile#L32 uses https://github.com/meetecho/janus-gateway --disable-mqtt (which would otherwise provide support for MQTT using https://www.eclipse.org/paho/clients/c/)

But couldn't https://github.com/mattermost/mattermost-push-proxy "simply" use https://github.com/goiiot/libmqtt (MQTT v3.1.1/5.0, Go, Apache2) as a notification backend. That would offer (much) more flexibility way for self-hosted Mattermost instance to provide mobile push-notificaftions ( @coreyhulen) which is currently harmed by the fact that a Firebase key harcodes a unique link between app-id and notification currently. [The alternative would be to open Mattermost push proxy to 3rd-parties Mattermost instances...]

For reference: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers Ability to override GCM key at runtime

Other software, same topic: RocketChat/Rocket.Chat/issues/2071 vector-im/riot-android/issues/1066 signalapp/PushServer/issues/2 / signalapp/Signal-Android/issues/1000 https://ring.cx/en/news#push-notifications-a-new-feature-added-to-ring-project

[dbrgn]

Note that implementing custom push channels is really challenging on newer Android devices (especially Chinese flavors like Xiaomi and Huawei) because of all the energy management functionality, doze mode etc.

Most probably you'll get a lot of complaints of pushes not arriving because the network connection or the push service was killed in the background.

If you provide a version without GCM integration, I think Polling would be the better solution (since it's much easier to debug).

[rugk]

@dbrgn Hi, totally impossible to guess, where you have that knowledge/experience from… :smile:

[Rudloff]

@hmhealey @jasonblais Since you don't want to merge #1686 at the moment, I worked on a different approach for our F-Droid package. We would fetch your source code, remove the non-free dependencies with sed and then build the APK. (You can see the changes we would make here: https://gitlab.com/fdroid/fdroiddata/blob/da75e134e5da9dc20d1b83185e815faa74b38118/metadata/com.mattermost.rnbeta.yml#L39)

Would you be OK with us building and distributing the app this way?

(It is basically the same method we already use for Mattermost Classic.)

[jasonblais]

Thanks @Rudloff - appreciate the thoughtfulness. We'll be meeting to discuss the changes as a team later this week.

[enahum]

Hi @Rudloff - first and foremost, I want to say we all appreciate your thoughtfulness and time you've put in supporting the F-Droid package. It's great to see such dedication from community members like yourself.

To answer your question: building and distributing the F-Droid package as you described is certainly okay.

What we discussed further is what steps can Mattermost take to better support the package distribution. One suggestion is to create a channel on our community server (http://pre-release.mattermost.com/core) for F-Droid. This channel could be used by our team to communicate updates and changes made for the Mattermost mobile apps that might affect the F-Droid package. This has worked quite well with other open-source projects such as Matterhorn, a terminal client for Mattermost.

Would you be open to creating this channel at http://pre-release.mattermost.com/core ?

In the future, if the distribution of the app through f-droid gains a lot of popularity via downloads and upvotes of the UserVoice feature proposal, and is regularly maintained, we can re-consider incorporating the support for f-droid into the Mattermost mobile apps themselves.

Let me know if you have any questions. Thank you again for your eagerness to contribute.

[Rudloff]

Thank you @enahum, I am really glad we could find common ground. We will now proceed to building and publishing the package.

I am totally OK with joining a channel about this. (My username on https://pre-release.mattermost.com/ is rudloff.)

[rugk]

In the future, if the distribution of the app through f-droid gains a lot of popularity via downloads and upvotes of the UserVoice feature proposal

Is not over 100 already quite a lot?

[IzzySoft]

I currently consider removing this app from my repo again. Though I make exceptions now and then for apps exceeding the size limit (which atm is 20M, whith Mattermost using 33M), I have an aversion to trackers. The latest version added Firebase Analytics. Not just tracking but also proprietary. I'd say that doesn't make listing in the official repo easier.

@enahum @lfbrock @jasonblais can you provide a FOSS build or at least remove Firebase Analytics again? Are you still looking to get your app listed in the official repo – or was this a signal that you don't? Honestly, you advert as "open source" and "secure workplace messaging from behind your firewall". Don't you think this is contradictionary? Neither GMS, Playstore nor Firebase or Firebase Analytics are open source. And for "secure workplace messaging from behind my firewall" I certainly wouldn't want to have the app "phoning home" (with proprietary libraries, you cannot guarantee what will be transmitted).

Please let me know which path you decide upon.

@Rudloff Do you know what is the status of the "official inclusion"? Is it still ongoing? Or did adding Firebase Analytics kill that already (if it wasn't dead before – last action here was quite a while ago)?

[IzzySoft]

PS: Until clarification, I've disabled automated updates and rolled back to v1.18.1 in my repo.

[enahum]

@IzzySoft I must say that the only reason we use Firebase at this moment in time and previously GCm is purely because the need for push notifications and we haven’t found a way to get push notifications reliably working without this service as well as APNs for iOS.

Sadly there is no solution for this in our radar, and almost all users expect push notifications to work.

If you know of a solution then please share.

[IzzySoft]

@enahum Firebase has been in there for some time, and I'm aware of that. But the latest release introduced Firebase Analytics as well, which is what I just complained about. Could it be you just switched from GCM to FCM and weren't aware that this step sneaks in Analytics if not explicitly prevented – so adding that wasn't intended but an accident? In that case I gladly re-enable auto-updates once there's a fixed version available.

As for alternatives with push notifications: I'm no dev, so I cannot say how well some solutions work. To my knowledge there are at least 2 alternatives. One is what Tutanota switched to, the other I unfortunately do not remember (actually there are several more, but those would mean replacing one devil by another, like Amazon Device Messaging (ADM)).

Ah wait, the other one was based on MQTT, see eg this Gist. And some other alternatives are listed here (just found that now, hope it helps!) – where you can also find the links on Tutanota.

[enahum]

@IzzySoft we were definitely not meaning to include Firebase Analytics probably included by a dependency or something like that I did file a ticket to get rid of it https://mattermost.atlassian.net/browse/MM-15959

as for the push notifications thanks for the references, we will definitely look into it.

[Rudloff]

@Rudloff Do you know what is the status of the "official inclusion"?

We have had a working build recipe for quite some time but it always fails to build on our build server with some out of memory error: https://f-droid.org/wiki/page/com.mattermost.rnbeta/lastbuild

No one understands why this happens and I can't reproduce it locally with a similar amount of RAM.

[enahum]

@Rudloff the memory issue can be solved by adding this env var export NODE_OPTIONS=--max_old_space_size=12000

[IzzySoft]

@enahum Great, thanks! Please ping me when a new APK without Analytics has been attached to a (new) release, I'll fetch it then ASAP.

[enahum]

PR submitted to disable Firebase Analytics https://github.com/mattermost/mattermost-mobile/pull/2854

[IzzySoft]

Thanks for the fast reaction ( tapping my hat ), I'm honestly impressed! Am curious what my scanner will say for the next version – i.e. if disabling it the way it's done will cause the relevant code not to be included (so the scanner doesn't see the analytics classes), or just not to call to it (so the scanner will still yield a warning)…

[IzzySoft]

PS: Last version w/o Analytics is 1.16.1 currently – 1.17.0 introduced it (just to let you know – and in case you want to understand what might have caused the issue). I'm confused why my "watchdog" didn't bark earlier.

[enahum]

That’s the moment when we switch from GCm to Firebase as GCM was being removed

[IzzySoft]

Ah, then it was the usual culprit which hit so many apps (and which I already suspected above) – thanks for confirming! Ugly move by big G. Well, I reset my repo to 1.16.1 for now (to offer the "cleaner version"). As soon as the PR was merged, a new version is released and I get to know, I'll close the gap ASAP and re-enable auto-updates then.

[Rudloff]

the memory issue can be solved by adding this env var export NODE_OPTIONS=--max_old_space_size=12000

Thanks for the help! Using an environment variable did not work, but adding it to nodeExecutableAndArgs did the trick (similar to https://github.com/mattermost/mattermost-mobile/issues/2327#issuecomment-459432932).

(It is annoying that max_old_space_size is some kind of hard limit that makes Node crash instead of just making it use less memory...)

[licaon-kter]

Published already, pull to refresh your F-Droid repos in client.

(Website will be updated later)

You can close this.

@Rudloff Can we name it properly now? And the icon? Beta is no fun :P

[Rudloff]

Can we name it properly now? And the icon? Beta is no fun :P

Well, the app is actually named like that in the code: https://github.com/mattermost/mattermost-mobile/blob/d1532b651eb96e7d0c129d697c24ec88169983e5/android/app/src/main/res/values/strings.xml#L2

Upstream uses a Fastlane script to change it before build: https://github.com/mattermost/mattermost-mobile/blob/d1532b651eb96e7d0c129d697c24ec88169983e5/fastlane/Fastfile#L429 We don't use Fastlane, but I guess we could do something similar with sed. (But, as usual, the more we change we change the code, the more likely it is to break on updates.)

[licaon-kter]

Yeah, so better upstream these changes ;)

[PanderMusubi]

Can this issue be closed? See https://f-droid.org/en/packages/com.mattermost.rnbeta/

[licaon-kter]

I'd rather not, those patches are not in this repo, right?

Also, it fails to build after 1.19.0 :(

[PanderMusubi]

I have no idea. See also https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/com.mattermost.rnbeta.yml Hope to see next version with merged patches in F-Droid soon.

[licaon-kter]

Could someone take a look at the fail log? Any tips help... https://f-droid.org/wiki/page/com.mattermost.rnbeta/lastbuild_230

[licaon-kter]

Any news?

[jasonblais]

@Rudloff Wondering if you would know on the above?