---
# System prepended metadata

title: Untitled

---

\>>>>>>

(off topic)

Instead of using a hard-coded JSON file, you can lookup XKCD comics on IPFS at /ipns/xkcd.hacdias.com/NNNN/`. In each comic directory, there's:

- An index.html file (the comic's page).
- An info.js file with the title, alt text, date, etc.
- An image.png file (the comic itself).

<<<<<<

At the beginning I listed the image CIDs by doing a `refs -r` on the base CID of the XKCD folder, but the operation was too slow, especially on a cellular connection. I'm not sure about the behavior of the `refs` command but I have the impression that under the hood, it downloads all the blocks in the local repo (this may not be true and there may be a way to avoid this).

The `ls` command was much faster but I was afraid to make the code less readable by implementing recursion + image filtering directly in Java and Swift.

I then chose as a compromise to list the CIDs in a JSON so that the application can download a random image directly which makes the operation much faster and the demo more pleasant to use (even if it bothered me to be less in line with the IPFS philosophy and the application couldn't get an up-to-date list of XKCD CIDs).

If there's a faster way to list the image CIDs directly from IPFS, I'll be really happy to get rid of JSON. I could come back to the idea of using recursive ls? Or maybe there's a trick I don't know to quickly list using IPNS?

---

\>>>>>>

I'd take a look at the command builder in go-ipfs-api. Passing in commands as strings is going to get tedious. It's also likely to cause security issues (string interpolation).

<<<<<<

You're right, we hesitated at the beginning to use the request builder (it's already exposed on the Golang side), but in order to implement a v1 simply and quickly, we chose to use strings instead.

We will try to replace the command methods quickly so that they wrap/use or expose the request builder.

---

\>>>>>>

This should probably take in some form of stream (or there should be an alternative that takes a stream).

Also, all of these commands should likely return streams. Otherwise, there's no way to get streaming progress information.

<<<<<<

You're right about that too, but for the same reasons, we chose to skip the implementation of the streams between Golang <-> Swift and Golang <-> Java.

@gfanton is working on a similar issue for Java/Swift to be able to use libp2p streams directly, we will probably be able to use the same logic for the command inputs/outputs.

Does it seem ok to you to do this in another PR?


---

\>>>>>>

I'm not familiar with android, but why the 10.* addresses?

<<<<<<

Both addresses are used by Android emulators as aliases to the host loopback interface (`10.0.2.2` for the official emulator, `10.0.3.2` for Genymotion).

That said, it's probably not useful to keep them even though I don't think they represent a risk.

--- 

\>>>>>>

note: you can leave the zero values out.

<<<<<<

We have put the values explicitly to make it easier to understand when reading the code.

But if you think it's a bad idea we can remove them.

---

\>>>>>>

Hm. We should probably expose the default config in go-ipfs-config. Want to file a PR for that?

<<<<<<

For the moment it's still WIP, we continue to make tests and changes, so wouldn't it be better to wait until it's a little more stable before merging this with go-ipfs-config?

---

\>>>>>>

I'd set this to 2048. This won't affect bootstrapping.

<<<<<<

Okay we'll reset it to 2048, I probably modified it when I was struggling with the bootstrap problem.

---

\>>>>>>

This code probably belongs in go-ipfs-api (PRs appreciated).

<<<<<<

Ok we'll submit a PR as soon as possible then.

---

\>>>>>>

I really recommend that you make the Java API use the go request builder and not the other way around.

<<<<<<

Ok we'll do that.