Submit Status to F-Droid

[step21]

Some work as been done to be able to publish to F-Droid, but still we have some google dependencies left:

#8512 (comment)

This task would involve finding out those dependencies and how/why they are pulled in so that those strings don't show in the build anymore, and we should get a green light for F-Droid.

More details on:

#8512

@jakubgs can assist with the details

Old issue

Note: this issue has been edited

Acceptance criteria

1. Identify obstacles for F-Droid Inclusion
2. Create issues and prioritize them
3. Submit proposal to be included

4 (possibly orthogonal/enhancement): Reproducible builds

Original issue

Just fyi, I opened an issues on f-droid to ask for inclusion of status (https://gitlab.com/fdroid/rfp/issues/121). I assume this is fine as this in the Todo/on the Readme anyway. (under 'Give me Binaries') This is subject anyway to their system being fine with Gradle and no external/proprietary libraries/jars being included or other issues that would go against their inclusion policy (https://f-droid.org/wiki/page/Inclusion_Policy).

[0xc1c4da]

the important thing is to state that it is alpha software.

as for externalities it's about building status-go first and referencing that in gradle.

[0xc1c4da]

I'm curious why you created the issue on fdroid but didn't fill out their requirements properly? could you please close the issue so we can make a correct submission.

Ideally we only submit to F-Droid with everything ready to go

[step21]

Well, sure, you could always state it is alpha, they do not have a policy against that. I filled out their requirements to the best of my knowledge at the time. Of course if you would only want to submit once everything is ready I do not want to interfere with that, just thought I'd see how far I would get.

[mulles]

As the app is still in alpha the above seems to be still valid. Looking forward to future f-droid submission, so one does not need to install from "unknown sources" anymore.

[status-github-bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[status-github-bot]

This issue has been automatically closed. Please re-open if this issue is important to you.

[leafcutterant]

Request for re-open. Bad bot, by the way. It's erroneous to close issues based on (the lack of) recent activity. Signal has been doing the same, very annoying.

This IS a very important issue. One has to make a pilgrimage or build from source to get access to Status outside Google Play. Sorry, but this is ridiculous. Status says it wants to become the operating system of the web3.0. I support that vision, but then please, mean it.

Conforming to walled gardens and excluding users won't propagate that vision.

[mulles]

Sharing the opinion of @leafcutterant. An app sharing FOSS ethics, should try to be distributed openly. And including it in F-droid or providing an F-droid repository seems to be mandatory for this right now.

Moreover, the App is now in Beta, does this mean we are ready or one step further to: "Ideally we only submit to F-Droid with everything ready to go" ?

[oskarth]

Agree with both of you, thanks for being vocal about this! Reopening.

In order to be on F-Droid IIRC we need deterministic builds (this might be wrong though?). This is a challenge but it's definitely needed in order to be a trust-minimized OS. Here's the most recent state of deterministic builds: https://github.com/status-im/swarms/blob/master/ideas/282-deterministic-builds.md (though AFAIK not much has happened lately).

Pinging @jakubgs @mandrigin @corpetty @Graeme-Code about this for most recent state.

EDIT: Looking at https://gitlab.com/fdroid/rfp/issues/121 I don't see determinstic build as requirement, so it might be a slightly orthogonal problem. Scanning inclusion criteria briefly, there might be some stuff re use of Firebase for push notifications (though we explicitly removed analytics package from this).

GitHub

status-im/swarms

Swarm Home. New, completed and in-progress features for Status - status-im/swarms

[0xc1c4da]

This is an opportune time to revisit this, since we need, deterministic builds is necessary for us to get our dependencies in check and actually care about allowing other people to build Status.

[mandrigin]

@oskarth @jarradh I'm 100% up for that. do we know the exact steps on what needs to be done to be included or should I research it?

[oskarth]

Swarm linked above did initial investigation and had some kick off call. It isn’t clear to me what happened after this or where this was documented (this was around the time we moved from Slack).

[jakubgs]

Yeah, it all happened shortly before the hackathon and there were so many things going on the swarm was kinda forgotten. Now we can go back to working on this I guess.
As I remember it the first step was to make status-go builds deterministic, which was supposed to be easy because Go was supposed to ship with functionality for doing that soon. I'm not sure where to find info on that feature and whether it was already released or not. I can research.

[mandrigin]

@jakubgs it would be awesome! can you keep us updated on your research in this issue?

[Graeme-Code]

I dropped the ball here. Arranged for a technical writer (can't remember his name) we hired to review and document all moving parts for status go and status react. He then went AWOL and was unable to secure technical writing resources. I turned all my focus to the voting dapp.

…

On Mon, Dec 3, 2018 at 11:46 AM Igor Mandrigin ***@***.***> wrote: @jakubgs <https://github.com/jakubgs> it would be awesome! can you keep us updated on your research in this issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHjHZRTNAeZQKMKvdXlIstoo0fjDQLjSks5u1Q8PgaJpZM4NMZzx> .

-- I respond faster on Status, use my contact code below to add me: https://get.status.im/user/0x040c839802425169b0dd575059a2897a76f14a0cf325521b8f4a439f679560c508e7dc74b5e06432e2c70cec2d745d06948d9a77fec8a6572c1938c063141499da

[mandrigin]

@Graeme-Code so, I think @jakubgs is right and we can start with just making status-go deterministic, it wouldn't hurt anyway.

[jakubgs]

I found a pretty sweet tool here:
https://reproducible-builds.org/tools/
Which is:
https://salsa.debian.org/reproducible-builds/diffoscope
It can generate diff reports on various formats, including APK files.

Example diff between two builds of the same commit(and) generated with:

diffoscope --debug \
  --max-report-size=0 --html-dir=40aff1 \
  --jquery='https://code.jquery.com/jquery-3.3.1.min.js' \
  StatusIm-190112-031332-40aff1-nightly.apk \
  StatusIm-190113-032212-40aff1-nightly.apk

https://examples.status.im/diffs/40aff1/

I intend to make an automation that will generate comparisons of build artifacts in PRs.

[mandrigin]

@jakubgs didn't we submit it at least once? :)

[jakubgs]

@mandrigin no clue.

[pedropombeiro]

The Android build (both status-react and status-go) have been deterministic since Q2 2019, so I think we have what we need to move forward on this.

[jakubgs]

I spent a fair bit researching how to build for F-Droid in #8512 but their tooling is pretty trash, as is their documentation. I'll get back to it eventually.

[flexsurfer]

https://f-droid.org/en/packages/im.status.ethereum/