282-deterministic-builds

[jakubgs]

Please help me to complete this. Not sure what I'm missing, this is the first idea definition I've created.

[status-github-bot]

Hey @jakubgs, and thank you so much for making your first pull request in ideas! ❤️ Please help us make your experience better by filling out this brief questionnaire https://goo.gl/forms/uWqNcVpVz7OIopXg2

Google Docs

Status 1st commit dev survey

First of all thank you so much for taking the time to make your first foray into the world of Status. We want to make sure that your experience with building the future of the decentralized web with us is not only enjoyable but gives you real purpose.

Please check out our wiki at https://wiki.status.im and our Dev forum at https://discuss.status.im for more in depth longform discussion -- You can also join our Riot at https://chat.status.im which has all of our developers to answer any pressing questions you may have.

[maxhora]

Is it about resources from Internet which we do not control or about any resources? For example, desktop builds status-go by doing git clone on-the-go for specific revision. Usually, there is no issue with doing that.

[vkjr]

@jakubgs, during desktop mac build we also download a prepopulated zip file with libraries and frameworks needed to create StatusIm.dmg. Currently, it is stored in a separate github repository. Where should it be stored for a deterministic build?

[maxhora]

I believe that we should be able to automate creation process of prepopulated zip file content. The main concern is ubuntu_server binary with modified realm node-js module.

[jakubgs]

@vkjr is right, this is the kind of external resources I'm talking about. Now as @Maxris said, this should be either:

a) built by us in a deterministic way
b) versioned and checksumed so we know we get the same thing every time

[oskarth]

Seems like it'd be useful to have Clojure/Go devs, or not?

[oskarth]

And perhaps security @corpetty as well, not sure

[jakubgs]

Yes, definiely.

[oskarth]

What's something reasonable that can be done in first iteration? Perhaps something like find out current state of each sub package/component and what biggest blockers are. This way the work can be distributed, so someone might look into JS vendoring, and someone else figuring out how to get out timestamps from some ObjC linked monster config file.

[jakubgs]

That sounds reasonable, thanks.

[oskarth]

Generally looks good, added some comments.

One idea is to ask Clojure/Go people in #core to see if they want to help out with this.

[oskarth]

Awesome to see so many people committed to this

[oskarth]

This can be merged right? Are there more people who want to review? What's the plan for starting it? the timeline/checkpoints seems a bit fuzzy (maybe on purpose)

[arnetheduck]

A way to measure success here would be that apk is available on f-droid - this ensures that someone else can reproduce our build: https://f-droid.org/en/docs/FAQ_-_App_Developers/#will-my-app-be-built-from-source

FAQ - App Developers | F-Droid - Free and Open Source Android App Repository

[jakubgs]

I've added another interested person(@antdanchenko ), I also talked to people interested and we might have to wait a few weeks to start with this for real.
I can start right away by implementing a proof-of-concept for a simple go package, and once that is done we can start by doing the same but for the whole status-go package. I think it would make sense to involve others only once I have a working prood-of-concept for how this kind of build would work.
Not sure if this would be part of the swarm or separate, since initially it would be just me.

[Graeme-Code]

Hi everyone,

I’d like to be apart of this effort. I’m really interested in this because:

1. I believe disruptive dapps will face restrictions on mainstream app distribution channels. Meaning that people will need to download these dapps via channels which don’t have the credibility/trust like a play store or App Store. In the future, deterministic builds will be key to distribution of Dapps.
2. It has interesting UX implications in the sense of just how easily someone can “know” that a build has not been tampered with and is exactly the same as the one produced by a developer.

I can help here by coordinating with core contributors/marketing/UX/community resources to get people excited about deterministic builds and work to improve the users process of knowing their build is deterministic.