# IPFS binaries on IPFS? **URL:** \ **Category:** Help\ **Created:** [December 14, 2017, 1:44pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632 "2017-12-14T13:44:34Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![rklaehn](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rklaehn/32/244_2.png) [@rklaehn](https://discuss.ipfs.tech/u/rklaehn)\ **Post date:** [December 14, 2017, 1:44pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/1 "2017-12-14T13:44:34Z")
We have an android application that runs an internal IPFS node. Currently it contains hardcoded binaries of go-ips for all the architectures we want to support (arm and atom/x86). It would be useful to have the IPFS binaries hosted on IPFS, so you can download them using curl `https://ipfs.io/ipfs/QmABCD` instead of having to download and unpack them from `https://dist.ipfs.io`. Are the binaries already being published? If not, could this easily be added to the ipfs build process? Ideally there should be an IPNS name pointing to a manifest with a map of version/architecture → hash. ---
**Author:** ![Magik6k](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/magik6k/32/2318_2.png) [@Magik6k](https://discuss.ipfs.tech/u/Magik6k)\ **Post date:** [December 14, 2017, 2:47pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/2 "2017-12-14T14:47:55Z")
Dists page is already hosted on IPFS: [https://ipfs.io/ipns/dist.ipfs.io](https://ipfs.io/ipns/dist.ipfs.io), and there is a version file for each package [https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/versions](https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/versions) ---
**Author:** ![rklaehn](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rklaehn/32/244_2.png) [@rklaehn](https://discuss.ipfs.tech/u/rklaehn)\ **Post date:** [December 14, 2017, 3:02pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/3 "2017-12-14T15:02:16Z")
Cool. That’s _almost_ what we’re looking for. We would like to have a machine-readable manifest that allows you to get the **go binary** (not the .tar.gz archive) of ipfs for a specific version and architecture. That would allow us to just download the file when installing the apk. Kind of how it is done in [https://github.com/ligi/IPFSDroid/blob/master/app/src/main/java/org/ligi/ipfsdroid/IPFSDaemon.kt#L22](https://github.com/ligi/IPFSDroid/blob/master/app/src/main/java/org/ligi/ipfsdroid/IPFSDaemon.kt#L22) , but with an officially supported mechanism. ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [December 14, 2017, 4:49pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/4 "2017-12-14T16:49:06Z")
> That would allow us to just download the file when installing the apk. Is downloading the archive and extracting it not an option? You can: 1. Get the latest version from the end of `https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/versions`. 2. Figure out the right dist archive for your current architecture/os by reading `https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/$version/dist.json` 3. Download the archive. 4. Extact the ipfs binary from the archive (there are java based tar.gz extractors). ---
**Author:** ![rklaehn](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rklaehn/32/244_2.png) [@rklaehn](https://discuss.ipfs.tech/u/rklaehn)\ **Post date:** [December 14, 2017, 5:13pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/5 "2017-12-14T17:13:44Z")
> [@stebalien](#): > > Is downloading the archive and extracting it not an option? Sure. That is what we will do if there is no direct link to the binary. I just thought that it would be better to directly get the binary, especially given that the binary is all that you need from the archive. ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [December 14, 2017, 5:31pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/6 "2017-12-14T17:31:40Z")
> [@rklaehn](#): > > I just thought that it would be better to directly get the binary, especially given that the binary is all that you need from the archive. 1. The archive offers significant compression (42M versus 12M). 2. _We_ need the license, readme, and install script. ---
**Author:** ![rklaehn](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rklaehn/32/244_2.png) [@rklaehn](https://discuss.ipfs.tech/u/rklaehn)\ **Post date:** [December 15, 2017, 5:31pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/7 "2017-12-15T17:31:28Z")
> [@stebalien](#): > > 1. The archive offers significant compression (42M versus 12M). That is actually a good point. OK, I have now implemented downloading and unpacking of the tar.gz file according to the version. I hope that things like file name and location (go-ipfs/ipfs) as well as the format of the dist json are going to remain standard. p.s. How would one layer compression into ipfs? IPFS could store blocks compressed and serve them compressed when there is an Accept-Encoding: gzip header in the GET request of the API? You would probably not want to compress before hashing, since that would mean that the same data with different compression algos would no longer have the same hash… ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [December 15, 2017, 8:14pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/8 "2017-12-15T20:14:49Z")
> [@rklaehn](#): > > OK, I have now implemented downloading and unpacking of the tar.gz file according to the version. I hope that things like file name and location (go-ipfs/ipfs) as well as the format of the dist json are going to remain standard. We have no plans on changing that layout. ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [December 15, 2017, 8:18pm UTC](https://discuss.ipfs.tech/t/ipfs-binaries-on-ipfs/1632/9 "2017-12-15T20:18:58Z")
> [@rklaehn](#): > > How would one layer compression into ipfs? IPFS could store blocks compressed and serve them compressed when there is an Accept-Encoding: gzip header in the GET request of the API? You would probably not want to compress before hashing, since that would mean that the same data with different compression algos would no longer have the same hash… We’ve considered this but there are a lot of tradeoffs. For one, if we auto-compress blocks in transit, we could reveal information to an attacker. For example, let’s say an attacker can: 1. Monitor the amount of data sent between two peers. 2. Trick one peer into repeatedly downloading `{"secret": "my secret data", "non-secret": "attacker controlled data"}` from the other. The attacker could use this to figure out the secret data by abusing the compression. See: > **[CRIME](https://en.wikipedia.org/wiki/CRIME)** > > CRIME (Compression Ratio Info-leak Made Easy) is a security vulnerability in HTTPS and SPDY protocols that utilize compression, which can leak the content of secret web cookies. When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session, allowing the launching of further attacks. CRIME was assigned CVE-.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{ Th...