FOSS Version

[shtrophic]

Hi, I wanted to raise some awareness for some objectives that the Android-FOSS community would enjoy seeing. Those are:

1. Support for ntfy-push. This should count as the greatest FOSS-priority.
2. Non-Fdroid FOSS releases, preferrably on GitHub
3. Split APKs

About Nr. 2: While Element-Android has github releases that one can use, they only provide the playstore version of the app. Furthermore, the version available on fdroid often lags behind playstore by a significant timespan. You might make the argument that fdroid only receives stable versions of the app after being tested by playstore users; However for pre-releases, github already provides the necessary facilities.

I hope this could gain some traction in the early development of Element-X.

[bmarty]

Hello,

This is the tasks to achieve to be able to publish on F-Droid:

• [x] Add gradle flavorDimensions store with two values gplay and fdroid
• [x] Update all the CI script so that it understand this new flavorDimensions and build both variant
• [x] Assign value to BuildMeta.flavorDescription and BuildMeta.flavorShortDescription (here)
• [x] Bug report: uncomment builder.addFormDataPart("label", buildMeta.flavorDescription) (here)
• [x] Make sure the fdroid variant does not include the module pushproviders.firebase
• [ ] Make sure the fdroid variant configure properly the unified push provider. UnifiedPush support has been implemented and has to be used at this point. Note: if there is no installed distributors, no pusher will be registered. There is no UI to select a push provider and a distributor for now, this is out of scope of this issue.
• [ ] When it's ready, ping the F-Droid team to make them build the app and publish it.
• [ ] Check the user agent value. Maybe use a different one depending on the flavor.

Already done:

• [ ] The store assets are already committed in the project, this must be used to publish to the F-Droid store. (English only for now)

In the long term: Element X Android codebase will be used to upgrade Element Android (the existing app). So at some point this work has to be done, to be able to release the new Element Android to F-Droid

[licaon-kter]

Current status is rather clean ( ahem https://gitlab.com/fdroid/rfp/-/issues/2556#note_1593343486 ), I mean one rm and 3 seds, but yeah, a flavor would be nicer so we don't need to hunt down future changes :wink:

[Mynacol]

I'd like to encourage you to try to realize reproducible builds. It eliminates trust in F-Droid and ensures you are in control of the published software. It avoids issues when end users are using multiple stores for updates, but the same app is signed with different keys (assuming you'd/can use the same key for the play store and F-Droid variants). Publishing to F-Droid first non-reproducible and later turning on reproducible builds has its drawbacks, a cleaner approach would be to publish reproducibly from the start.

For that you have to add the required code changes (new flavor, removed unfree dependencies, only/additionally building split APKs) and publishing those APKs somewhere (GitHub releases?). And maybe some compilation adjustments to make it reproducible.

[licaon-kter]

@Mynacol think you are missing some context.

If this app is repro, great.

But this app will die after a while and current app (non X) will be replaced with this one.

Yet, to have that reproducible then, all the current users will need to uninstall & reinstall.

There's no UI that informs as such and guide the users, at least not yet.

The TWIF (this week in fdroid) blog posts are used to inform about such changes but not sure everybody is RSS subscribed to that :)

[K4LCIFER]

It looks like Element X is to be published to F-Droid, with support for UnifiedPush, for the release of v0.4.2:

Next release 0.4.2 should also be published on F-Droid with push support using UnifiedPush.

Related PR: https://github.com/element-hq/element-x-android/pull/2248

[Guanran928]

@linsui told me they (fdroid) are still waiting for Element team to publish FOSS flavor's apk, so they can do reproducible build.

https://matrix.to/#/!JqpjuzzVfwdybKQWQg:f-droid.org/$Z2CIcmMm-uvxvnp1keBP7DADRsuPAStDG5eWEC8Y3E4?via=mozilla.org&via=t2bot.io&via=matrix.org

[licaon-kter]

@K4LCIFER read this thread at least https://gitlab.com/fdroid/fdroiddata/-/merge_requests/13829#note_1595843143 maybe https://gitlab.com/fdroid/rfp/-/issues/2556 too

[Mek101]

Only another 20 thousand years...

[SamyDjemai]

Hi @bmarty, from what I see in LoggedInPresenter.kt and in my tests, the UnifiedPush provider seems to be properly working now. Are there any other steps we can help you with before pinging the F-Droid team? :)

[licaon-kter]

@SamyDjemai ping who about what? https://gitlab.com/fdroid/fdroiddata/-/merge_requests/13829

[SamyDjemai]

@licaon-kter I was referencing this message which seems to be outdated: https://github.com/element-hq/element-x-android/issues/1418#issuecomment-1752465669 I've only now noticed that builds were already in progress on the F-Droid side :sweat_smile: Any blockers there? I'm noticing that the checkupdates GitLab CI job is failing, would we need to change something in this repo to comply?

[licaon-kter]

Expand the threads and read F-Droid feedback and ara4n's answers, that's the status I guess...

would we need to change something in this repo to comply?

yes, a place for F-Droid to grep the versionName and versionCode

[SamyDjemai]

I think that instead of hardcoding the versionName and versionCode in this repo, we could use UpdateCheckData in HTTP mode and scrape the GitHub API for latest releases. As an example, we could have:

UpdateCheckMode: HTTP
UpdateCheckData: 'https://api.github.com/repos/element-hq/element-x-android/releases?per_page=1|"name": "(\d+)|.|"tag_name": "v((?:[0-9]\d*)\.(?:[0-9]\d*)\.(?:[0-9]\d*))"'

This way, the release process stays unchanged, and we can dynamically fetch versionCode and versionName from the latest GitHub release

[licaon-kter]

@SamyDjemai that line yields ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this context so it might need some tweaking :)

[jspricke]

This works for me:

UpdateCheckData: 'https://api.github.com/repos/element-hq/element-x-android/releases?per_page=1|"name":"(\d+)|.|"tag_name":"v((?:[0-9]\d*)\.(?:[0-9]\d*)\.(?:[0-9]\d*))"'

[SamyDjemai]

I've also reworked mine with simpler matching :)

UpdateCheckMode: HTTP
UpdateCheckData: https://api.github.com/repos/element-hq/element-x-android/releases/latest|"name":"(\d+)-|.|"tag_name":"v(\d+\.\d+\.\d+)"

I'd suggest using https://api.github.com/repos/element-hq/element-x-android/releases/latest instead of using the ?per_page=1.

I'm getting this error:

2024-03-22 12:32:41,036 ERROR: ...checkupdate failed for io.element.android.x : current version is newer: old vercode=40004064, new vercode=40004060

@licaon-kter would we track specific commits of the repo, or only releases? If we do the latter, we should clean up the Builds section of the manifest file

[licaon-kter]

I'm getting this error:

I've fixed that, let me test the rest

would we track specific commits of the repo, or only releases?

we usually get a Tag on checkupdate and use the commit hash

but, with HTTP we can't get commit...

[SamyDjemai]

What if we use AutoUpdateMode: Version v%v? According to this documentation, we can directly use the version tag, and we don't need the commit hash

[licaon-kter]

there's no v in versionName: https://github.com/element-hq/element-x-android/blob/v0.4.6/plugins/src/main/kotlin/Versions.kt#L63

this works if we just ignore versionName (high goal: https://gitlab.com/fdroid/fdroidserver/-/issues/1047) or if upstream has Tag = versionName

[SamyDjemai]

But the Git tags are in the vX.X.X format, hence the need for v%v if I'm not mistaken, since according to the doc:

The pattern is used to generate a value (tag name) used for the commit: property of new build blocks. It is simply text in which %v and %c are replaced with the required version name and version code respectively. The resulting string must match an existing tag in the app’s repo, which then will be used by F-Droid to build the corresponding version.

[licaon-kter]

yup that does it

...
AutoUpdateMode: Version v%v
UpdateCheckMode: HTTP
VercodeOperation:
  - 1 + %c
  - 2 + %c
  - 3 + %c
  - 4 + %c
UpdateCheckData: https://api.github.com/repos/element-hq/element-x-android/releases/latest|"name":"(\d+)-|.|"tag_name":"v(\d+\.\d+\.\d+)"
CurrentVersion: 0.4.6
CurrentVersionCode: 40004064

[SamyDjemai]

Great, thanks! From what I've assessed, in order to be compliant with F-Droid's inclusion policy, we still need to do the following:

• [x] build F-Droid version without proprietary components
  • [x] Sentry: ~remove services/analyticsproviders/sentry in the F-Droid manifest~ Sentry SDK is open source
  • [x] Mapbox: Maplibre is used
• [ ] get approval from the upstream team for F-Droid release (clear up the existing confusion regarding release)

@licaon-kter do you see any other blockers? do we want reproducible builds? @bmarty is the Element X team OK for F-Droid release?

[licaon-kter]

build F-Droid version without proprietary components

current recipe does that

Sentry: remove services/analyticsproviders/sentry in the F-Droid manifestJ

not a NEED, if it's on by default or opt-out, it will get a Tracking anti-feature, if it's off by default and opt-in, it will get nothing

get approval from the upstream team for F-Droid release (clear up the existing confusion regarding release)

mostly this yes

reproducible builds

the big IF

[SamyDjemai]

Nice catch, forgot that the Sentry SDK is open source :facepalm: There is an opt-in screen for tracking when first logging into the app, so there won't be a Tracking anti-feature.

reproducible builds

The "current" Element app currently doesn't have reproducible builds, but there will be no need to uninstall and reinstall for users as you mentioned here if we implement them later and publish both developer-signed and F-Droid-signed APKs, right?

In my opinion, reproducible builds are a nice-to-have feature regarding the "temporary" nature of this app, but they aren't a priority. The 52 people that liked the issue's first message probably just want to try out Element X, no matter if it has reproducible builds or not.

[Mek101]

The 52 people that liked the issue's first message probably just want to try out Element X, no matter if it has reproducible builds or not.

I just want to try Element X without having the burden of keeping track of each release

[Mynacol]

Reproducible builds are always "nice to have."

However, there is exactly one time slot to determine which type of reproducible builds we choose for this app: before the first release in F-Droid. Adding reproducible builds from the start on means there is never a F-Droid signed build around, which reduces confusion of users (trying to update the F-Droid build with a GitHub release fails and users don't know why). It also preserves auto update functionality at F-Droid (adding reproducible builds later requires to manually add signature information for each new release). There is a decision to be made now. I hope the description above highlights the tradeoffs.

[SamyDjemai]

However, there is exactly one time slot to determine which type of reproducible builds we choose for this app: before the first release in F-Droid.

While I agree with that, the plan for this app is for its codebase to replace the existing Element app in app stores and in F-Droid, so even if we set up reproducible builds here before first release, we're still going to have to deal with an existing app that was already built and deployed before reproducible builds were set up.

That's why, in my opinion, they are nice-to-have, especially in this repo which is meant to be temporary.

adding reproducible builds later requires to manually add signature information for each new release

That's problematic, but from what I understand based on the GitLab pull request, updates won't be automated anyways

[ildar]

Let me comment as a user. Element (and X) is by its nature cloud-based. And local data is near zero. So uninstall+install is quite painless. I.e. reproducible builds aren't important. Thank you.

[linsui]

Reproducible Build doesn't only allow the user to install the apk from different channels, but also make sure that the apk built by F-Droid has no bug introduced by F-Droid. So F-Droid doesn't need to set a user agent for bug reports.

Please can you ensure that you set a user agent which clearly identifies the app as being the Fdroid build (so we can differentiate bug reports & debug appropriately)

[bmarty]

@licaon-kter I have published 4 APKs for F-Droid in the release 0.4.13: https://github.com/element-hq/element-x-android/releases/tag/v0.4.13

Let me know if it's OK and if you need anything else.