ipfs-http: manual testability or discoverability

[koivunej]

This was cut from the v0.2.0 release for present time constraints however making ipfs-http more accessible as "the" ipfs binary would make the project more accessible to anyone just wanting to try it out. At the moment I see the following obstacles:

• http/README.md has no tutorial on how to try out ipfs-http
• ipfs-http supports only init --profile test --bits b where b >= 2048
• ipfs-http only binds to ephemeral localhost port for http
• ipfs-http currently by default uses ~/.ipfs which is go-ipfs uses
• ipfs-http is "a bit incompatible" with go-ipfs 0.6 CLI at least, which Improve /add interop #380 started to explore
• there is no repo locking to prevent trying to connect two peers with same ids: Repo locking #243

The tutorial could be simple one which would show how to interact using go-ipfs CLI with the ipfs-http, something along the lines of:

1. install rust (link to book)
2. clone repo
3. cargo run -p ipfs-http -- init
4. cargo run -p ipfs-http -- daemon
5. in other terminal: IPFS_PATH=~/.rust-ipfs go-ipfs-binary-somewhere id

ipfs-http supporting only the init --profile test --bits b where b >= 2048 would be quite easy to fix so that it would support init and init --bits b where b >= 2048 by adding a profile abstraction or even a simple if-tornado in place of:

rust-ipfs/http/src/config.rs

Lines 68 to 74 in 722d41a

	if profiles.len() != 1 || profiles[0] != "test" {
	// profiles are expected to be (comma separated) "test" as there are no bootstrap peer
	// handling yet. the conformance test cases seem to init `go-ipfs` in this profile where
	// it does not have any bootstrap nodes, and multi node tests later call swarm apis to
	// dial the nodes together.
	return Err(InitializationError::InvalidProfiles(profiles));
	}

(I haven't really looked at go-ipfs init profiles, they might have more in-depth features but the "test or default" would most likely be enough here.)

The ipfs::config::BOOTSTRAP_NODES would need to be populated whenever in this "default" or not given profile along with listening address of /ip4/0.0.0.0/tcp/4004. Also the http API port would need to be specified as it is quite frustrating to copy and paste the multiaddr from the stdout produced by cargo run -p ipfs-http -- daemon and convert it to normal address for curl by hand. The ipfs-http::config::CompatConfigFile does not currently have any field(s) for configuring the API listening address. The API listening address needs to remain random for the --profile test usage in conformance tests.

The "a bit incompatible" can be seen by trying to go-ipfs-0.6 add stuff in; I was being too conservative here and go-ipfs probably uses just small variation to "file" as the field name:

rust-ipfs/http/src/v0/root_files/add.rs

Lines 148 to 153 in 722d41a

	// files are of the form "file-{1,2,3,..}"
	let _ = if field_name != "file" && !field_name.starts_with("file-") {
	Err(AddError::UnsupportedField(field_name.to_string()))
	} else {
	Ok(())
	}?;

The repo directory set by default is just wrong: we are not aiming for repo compatibility and as such, the we should be following js-ipfs lead and use ~/.rust-ipfs by default (js-ipfs uses ~/.jsipfs).

This has many parts and is well suited to be implemented in quite atomic PRs. If you are interested in working on any part of this, please leave a comment below.

[koivunej]

Above I mentioned the [swarm] listening address of 0.0.0.0:4004 with the logic of: go-ipfs uses 4001, js-ipfs takes over 4002 and 4003, so unless I missed something this should be free in the ipfs sphere.

[koivunej]

The #406 made the ipfs::config module pub, which is a small step towards init without --profile test, even if it is perhaps not the best idea to reference the list of bootstrap peer(s) in a real world application.