mastodon-android
mastodon-android copied to clipboard
mastodon
F-Droid packaging
i agree it would be great to see this Android app on F-Droid!
F-Droid is an Android app store specifically for free/libre open-source apps. It would be great if your app could be released there, as it is the number one for getting FLOSS Android apps for many people. F-Droid also builds all apps from source (optionally even reproducible), so downloads from there can be trusted.
The app developer FAQ or the quick start guide may help you to get started.
BTW a release on F-Droid could also bring some (more) popularity (in case that is intended), as it will show up in the app (new apps are featured there).
The official mastodon app appeared in IzzyOnDroid, may be available, also with repo IzzyOnDroid in F-Droid (https://apt.izzysoft.de/fdroid/repo). There also a lot of free software in this repository, too.
In the meantime, is there an APK we can install manually? Maybe generated via CI?
The official mastodon app appeared in IzzyOnDroid, may be available, also with repo IzzyOnDroid in F-Droid (https://apt.izzysoft.de/fdroid/repo). There also a lot of free software in this repository, too.
Anybody know why it has the NonFreeNet label there? I understand that being applied to Twitter apps for example, but I don't get this one
https://apt.izzysoft.de/fdroid/index/apk/org.joinmastodon.android
The official mastodon app appeared in IzzyOnDroid, may be available, also with repo IzzyOnDroid in F-Droid (https://apt.izzysoft.de/fdroid/repo). There also a lot of free software in this repository, too.
Anybody know why it has the NonFreeNet label there? I understand that being applied to Twitter apps for example, but I don't get this one
https://apt.izzysoft.de/fdroid/index/apk/org.joinmastodon.android
Likely because of a reliance on google API
It does not rely on it, it uses it when it's available. And that's reason enough for them to slap a red label on our app.
Wouldn't that be covered by the NonFreeDep label that's already on there?
NonFreeDep: The application depends on a non-free application (usually Google Services)
With software stored on F-Droid's repos I can usually find out why labels are applied by checking the RFP, but for Izzy's repo, idk, I'd have to ask Izzy I guess. https://mastodon.technology/@IzzyOnDroid
He did write an article about Mastodon on his site but it was last updated in 2020: https://android.izzysoft.de/articles/named/fediverse-2
Wouldn't that be covered by the NonFreeDep label that's already on there?
I read the word "depends" as meaning that the app can't function without a non-free dependency, like Google services. However, that's not the case here.
It does not rely on it, it uses it when it's available.
Just say a word, @Gargron (I missed that it's "only used when available"). As you don't use the FCM libs for that, the label is not raised automatically with my repo (and thus my checker does not yell at me when I remove it – which I now just have done). With f-droid.org those labels are set manually in general (when a finding suggests it), but nobody gets "daily alerts" like with my repo. So we can leave it out there as well.
but for Izzy's repo, idk, I'd have to ask Izzy I guess
Usually you find the reason in the libraries section of an app's packages – with a few exceptions (like apps accessing YT or some other non-free service without using a specific library). In case of this app here it wouldn't be obvious either, as Eugen did take care to avoid proprietary dependencies (tapping my hat once more).
Hope I could clarify things a bit, and remove one obstacle caused by myself…
Please add app to F-Droid for us degoogled Android users to be able to install and receive updates
The merge request was submitted ages ago. I don't think there's anything I can do to speed up the process — I'm not downgrading to Java 11 just so their build server can build it without downloading JDK 17 because downloading packages from places other than the debian repository is very very bad and dangerous apparently.
@Gargron what does the app do on a totally degoogled device? I don't seem to be getting push notifications from the app. Does it require GCM (Google Cloud Messenger) as its push service provider?
Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.
Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.
They could impliment a fallback to UnifiedPush. https://unifiedpush.org/ thame requirement of gcm may stop fdroid from including it
@grishka
What else would send it push notifications?
Quoting from my collection:
- @UnifiedPush
- Gotify
- NoProvider2Push
Not on my list:
- XMPP
- MQTT
- probably more, maybe appwrite and Supabase as Firebase replacements include it as well. So there's not exactly a lack of alternatives :wink:
And speaking of UnifiedPush: you could even include their FCM Distributor with your PlayStore build so PlayStore users wouldn't even notice the difference – while omitting it from the F-Droid/FOSS build lets other users choose freely from alternative backends.
Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.
They could impliment a fallback to UnifiedPush. https://unifiedpush.org/ thame requirement of gcm may stop fdroid from including it
Yep, i use ntfy and push support works great
Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.
They could impliment a fallback to UnifiedPush. https://unifiedpush.org/ thame requirement of gcm may stop fdroid from including it
Yes, this is a good idea- I use UnifiedPush for 2 apps and they deliver notifications very timely. I would say that this would be even better than GCM for notifications on an open app.
It should work with open-source replacements like microG, but I haven't tested that myself.
I do use /e/ OS with microG and haven't had any problems with Mastodon so far. 🤷
As an update, there is a new issue on F-Droid for Mastodon Android packaging and they're currently working on reproducible builds: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11874 F-Droid now runs Debian 11, which was a requirement for getting Mastodon Android working on the F-Droid build server
As an update, there is a new issue on F-Droid for Mastodon Android packaging and they're currently working on reproducible builds: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11874 F-Droid now runs Debian 11, which was a requirement for getting Mastodon Android working on the F-Droid build server
From the looks of it has it been merged 4 days ago... Not sure if there is any extra steps/requirements needed for it to appear in F-Droid, as I can't see it right now on it.
Tho, I hope that with this, the app can be updated to allow feeds from other servers to be seen (This from what I understand was a delibarate exclusion as Google's app policy doesn't allow this?).
They wanted reproducible builds from me, though that would require changes to the way I build release builds. I opted not to do that for now. As far as I understand, they've figured everything out a week or two ago in terms of getting the build process to work with their CI system (I did an apparently fairly non-standard thing by requiring JDK 17).
@grishka FYI reproducible builds are only a requirement if you want to publish on f-droid.org using your signatures on the APKs. If you're OK with the APKs being signed by the f-droid.org keys, then you can skip reproducible builds for now. They can always be added later, then new installs will automatically prefer the upstream-signed APKs.
Also, our system has to be non-standard because we build everything from source, and we only use binary packages in the build process that we have confirmed can be built from source. This is the same standard as any reputable GNU/Linux distro (Debian, Ubuntu, Fedora, RHEL, Gentoo, etc). This goes against what Google is trying to with the Android ecosystem since they are pushing hard to get everything using their proprietary bits so that they can control the ecosystem.
https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/
This app has been published in F-Droid 2 days ago. https://f-droid.org/en/packages/org.joinmastodon.android/
@Gargron @grishka as usually shortly after this point I remove apps from my repo (given a 10..14d overlap), time for a short question: As Mastodon is set up for reproducible builds the question was asked whether I shall keep it in my repo, e.g. in case of a "stuck build" or "emergency release" – as my updater picks your APK within 24h of your tagging & attaching, while F-Droid's build cycle will require at least around 2..3 days. Thanks to the reproducible build, such cross-updates are possible.
Would that be in your interest? If you're not opposed to the idea, I would mark it to stay (so my "dupe checker" ignores it).
I thought it wasn't set up for reproducible builds because I didn't want to change the way I sign my release apks? As I understood, the issue was that signing with apksigner (which they use) vs with Android Studio apk export (which I use) apparently produces apks that are equivalent in everything (the content and the signature) except they aren't identical if you compare them byte-by-byte — and that wasn't reproducible enough for them.
I thought it wasn't set up for reproducible builds because I didn't want to change the way I sign my release apks?
Reading above one certainly would get that impression, which is why I cross-checked with the org.joinmastodon.android.yml. And it says:
RepoType: git
Repo: https://github.com/mastodon/mastodon-android.git
Binaries: https://github.com/mastodon/mastodon-android/releases/download/v%v/mastodon-release.apk
The last line means there are upstream binaries to check against – which only makes sense if set up as reproducible builds. With that like, the build would fail if not reproducible. Plus, I've explicitly asked at our last team meeting and was told "yes". So some genius must have found a way :star_struck:
and that wasn't reproducible enough for them.
Looks like it worked out. Let me check the APK from F-Droid.org:
$ wget -q https://f-droid.org/repo/org.joinmastodon.android_39.apk
$ apksigner verify --print-certs org.joinmastodon.android_39.apk
Signer #1 certificate DN: O=Mastodon, C=DE
Signer #1 certificate SHA-256 digest: a3f19b26da3fe12b0285685f6ecc41515e6a9adcc5530b47c95d847cdae4a7e8
Signer #1 certificate SHA-1 digest: 94f3b9548d24a6e8049f7b68d589919f1b9d7dea
Signer #1 certificate MD5 digest: 58593b36a6244c056a1a292598d62be4
Looks like your signature, no? At least it is the same output for the one from my repo, so they match.
So you're OK with me keeping it in my repo then? Or shall I remove it? Guess it cannot hurt keeping it, might even be useful (see above).
@obfusk add support for apks signed with gradle to apksigcopier so it works with mastodon now.