use standard, unassigned ports for the daemon

[anarcat]

port 8080 is often in use on servers. it's the case here, and blocks that part of the daemon from starting up:

anarcat@marcos:~$ ipfs daemon
Initializing daemon...
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
23:18:02.772 ERROR   cmd/ipfs: listen tcp 127.0.0.1:8080: bind: address already in use <autogenerated>:24

IANA allocated port 8080 to web caches:

http-alt        8080/tcp        webcache        # WWW caching service

...but it's frequently squatted by a hodge-podge array of random offenders (e.g. Icecast, in my case, Apache Tomcat, Syncthing, etc). ipfs is the latest addition to the stack. :p

5001 is allocated to an obscure:

commplex-link      5001        tcp

... but it is also used by iperf (oh that could be pretty fireworks), Slingbox and Synology, according to Wikipedia.

the port should at least be customizable, maybe it is, but ipfs daemon --help doesn't tell me how.

i also believe a standard port pair should be requested from IANA, unless an RFC is made for HTTP/3 and the ipfs port becomes 80. :p but maybe that's a separate issue?

at least finding less busy ports would be a good idea. according to wikipedia at least 8082, 8084 and 8085 are free if you like the 80XX range, and 5020+ is also free.

For more sources on ports:

• IANA
• Wikipedia
• FreeBSD's /etc/services
• Debian's

[jbenet]

ports are already customizable. you can change them in the config. See:

ipfs config Addresses.Gateway
ipfs config Addresses.API
ipfs config Addresses.Swarm
ipfs config Addresses

they can be set like:

ipfs config Addresses.Gateway /ip4/0.0.0.0/tcp/9001

the port should at least be customizable, maybe it is, but ipfs daemon --help doesn't tell me how.

Agreed ipfs daemon should note ability to change config values for ports. i've changed the title of this issue accordingly.

[whyrusleeping]

I agree that we should probably avoid 8080

[anarcat]

if you don't mind, i created a PR for documenting the ports changing procedure in #879. we can therefore keep this ticket for changing the default ports to more standard behaviour.

[jbenet]

@anarcat on the ports, the reasoning for 8080 is what a lot of developers use to develop things, so it's a familiar place. agreed that it's annoying to clash-- but i would like to keep the gateway in the 8000/9000 range. 8888 is also typical, but less nice.

I dont care much about it, whatever works and is intuitive to people.

[drathir]

I guess is also needed a change of the default port 5001, because port is used by iperf program by default...

[lidel]

We had a related discussion recently (@batcer in https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-145756135 and myself):

http://localhost:8080

Not a good idea. I have Apache Tomcat on port 8080 and it is by default. Doesn't IPFS deserve dedicated port by default? Why use so common one?

(..)

8080 (..) follows unwritten convention championed by other HTTP proxies (a port in 8xxx range).

(..)

Moving to something like 8001 would unify the 'look and feel' of default ports, and solve us some setup time.

The gist: 8080 is very popular and often clashes with other software, using something else (in 8xxx range) would remove need of changing deault port for a lot of people.

[jbenet]

Yes, ok -- I think we should use something like:

• Swarm: 4737 (IPFS)
• Gateway: 8X80
• API: 8(X + 1)80

Maybe X=1 ?

Some port clashing will be inevitable, and configurability is fine. But making the common case is nice.

One thing to note: lots of ipfs things today assume localhost:8080 so we should itemize them to update them.

On Thursday, October 8, 2015, Marcin Rataj notifications@github.com wrote:

We had a related discussion in #1678 (comment) https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-145756135:

http://localhost:8080

Not a good idea. I have Apache Tomcat on port 8080 and it is by default. Doesn't IPFS deserve dedicated port by default? Why use so common one?

(..)

8080 (..) follows unwritten convention championed by other HTTP proxies (a port in 8xxx range).

(..)

Moving to something like 8001 would unify the 'look and feel' of default ports, and solve us some setup time.

The gist: 8080 is very popular and often clashes with other software, using something else (in 8xxx range) would remove need of changing deault port for a lot of people.

— Reply to this email directly or view it on GitHub https://github.com/ipfs/go-ipfs/issues/874#issuecomment-146769238.

[Artazor]

Get here while googling for a commplex-link (5001) conflict with ipfs daemon. So the problem is actual.

[Kubuxu]

@jbenet 8180 is frequently taken because of same reasoning.

[daveyarwood]

One thing to note: lots of ipfs things today assume localhost:8080 so we should itemize them to update them.

Is this still the case?

[Stebalien]

Nothing has changed here, unfortunately.

[ruverav]

I also have Tomcat installed and I needed to change the default port. So I chose port 6437 for my ipfs gateway.

How did I come to this idea? I converted the lowercase letters of ipfs to their decimal values and just added up the digits.

i = 105 = 6 p = 112 = 4 f = 102 = 3 s = 115 = 7

The fact that apparently this port is unasigned (according to speedguide.net) made me think it was a good alternative port. At least it's not a totally random number.

[Stebalien]

Closing as something we'll have to re-evaluate for a 1.0 release.

[lidel]

Somehow related: a proposal for ipfs-desktop (GUI wrapper for go-ipfs) to automatically pick a free port is discussed in https://github.com/ipfs-shipyard/ipfs-desktop/issues/912

[lidel]

@hsanjuan @Stebalien we may want to address this sooner than later.

Port 8080 is often taken and go-ipfs fails to start – pretty bad first impression when it comes to dev exp.

Thoughts on reopening this?

[autonome]

+1, these are unwinnable situations that only get harder over time and as we grow. Best to cut losses by changing immediately to a port or range that's off the beaten track (do a google search to look for any obvious conflicts) and win back all that future time that will otherwise been spent by us and potential IPFS developer users on it.

[Stebalien]

So, one solution is "do both". That is: try to listen on mulitple ports but succeed if at least one of the listen addresses succeeds.

[hsanjuan]

Related: #7053

So, one solution is "do both". That is: try to listen on mulitple ports but succeed if at least one of the listen addresses succeeds.

This still means that if ipfs manages to occupy :8080 other applications will not be able to use it. And we don't have a predictable port number, and we need to maintain some extra code, and docs, and clients like Companion may need to do guesswork to figure out in which port the gateway managed to run this time...

I'd just change the default port. Having our app listening on multiple ports and not failing unless all fail is just not how I'd expect something to work (https://en.wikipedia.org/wiki/Principle_of_least_astonishment).

[Stebalien]

Having the default port change over night is likely even worse. I'd like to give users a transition period.

[autonome]

@Stebalien this be reopened, or file a new issue?

[lidel]

My thinking is along these lines:

• :8080 is the problem, other ports are fine (i think?)
• the port would not change for existing users – we would not change their configs
• we would only change the default in:
  • go-ipfs-config/init.go, so all new users/installs get something other than 8080
  • all tests, docs and examples – so we remove confusion related to :8080 being something else on users system already

[RubenKelevra]

Why not change the IP instead of the port?

We could just use 127.0.0.80:8080 or something like this :)

[Stebalien]

That will work for IPv4, but not ipv6.

[Stebalien]

Hm. Although I guess we don't even listen on IPv6 by default.

[Stebalien]

Ah, nevermind. The issue is browsers. localhost -> 127.0.0.1 and "localhost" is treated as a secure origin, even without TLS. If we used a non-localhost address, HTTPS websites wouldn't be able to make requests to the IPFS API.

[rpodgorny]

so, i've been just hit by this (a conflict with jenkins port in my case). i think picking a stable non-assigned and non-popular port is a must for further wider adoption of ipfs (especially for the non-savvy).

while a sudden change may (and will) bring confusion for some but this will be time-limited (a month at most? imo it's just about updating the defaults in most popular programs such as ipfs-companion and official documentation) and it in the long term it will settle this issue forever! also, when ipfs is widely adopted, this has to be done anyway so why do it now?

after reading through rfc6335 (iana port number application process) i suggest we come up with:

1) list of ports (currently it's 8080, 4001, 5001 ...anything else?) 2) sensible names for the services (ipfs-gateway, ipfs-node, ipfs-webui ...or something like that) 3) a contact person (i can be the contact but i suppose you'd like to have there someone from the core team)

and fill this form:

https://www.iana.org/form/ports-services

if you provide the information in this issue's comments, i can try to go through the registration process on your behalf.

cheers!

[RubenKelevra]

That will work for IPv4, but not ipv6.

True.

Hm. Although I guess we don't even listen on IPv6 by default.

A thing we might want to change, as the browsers are probably trying both protocols.

Ah, nevermind. The issue is browsers. localhost -> 127.0.0.1 and "localhost" is treated as a secure origin, even without TLS. If we used a non-localhost address, HTTPS websites wouldn't be able to make requests to the IPFS API.

Using non-localhost addresses is difficult since we would need to tweak the dns-calls, since .localhost is basically a catch-all, while something like .local would need to be answered.

I think the port idea 6437 is nice, thanks @ruverav.

Well, no browser show localhost websites as secure:

Click to expand

  

(all freshly installed)

[Stebalien]

Well, no browser show localhost websites as secure:

It's a little more complicated.

• Firefox:
  • localhost:*
  • UI: Not marked as secure but not marked as insecure either.
  • JS APIs: Treated as a "secure" context.
  • *.localhost
  • UI: Marked as insecure.
  • JS APIs: Treated as an "insecure" context.
• Chrome:
  • localhost:*, *.localhost
  • UI: not marked
  • JS APIs: secure context

By "not marked", I mean that the URL bar doesn't explicitly say "Not Secure" or include a lock with a line through it. Try http://example.com for an example.

By "secure context", I mean the website can access APIs reserved for websites running in a secure context (can make requests with HTTPs, can access the web crypto APIs, can access the camera, etc.).

The other half of this is that the subdomain gateway feature only works with localhost (ipfs.io.ipns.localhost`).

[RubenKelevra]

By "not marked", I mean that the URL bar doesn't explicitly say "Not Secure" or include a lock with a line through it. Try http://example.com for an example.

Well, at least Firefox do should an 'insecure' lock.

The other half of this is that the subdomain gateway feature only works with localhost (ipfs.io.ipns.localhost`).

Yeah that's what I meant with catch-all.

---

Is it possible to register new protocols in the modern browsers (like we basically already do with ipfs:// and ipns:// via the addons) but let the browser speak directly to the API instead of redirecting it to the web gateway? 🤔

[RubenKelevra]

@Stebalien

Hm. Although I guess we don't even listen on IPv6 by default.

I've changed that:

https://github.com/ipfs/go-ipfs-config/pull/84

[aidanharris]

Yeah that's what I meant with catch-all.

.localhost isn't a catch-all in Firefox which is probably part of why it's treated as insecure. They don't implement let-localhost-be-localhost which means requests to ipfs.io.ipns.localhost could end up going to a remote server. Chrome forces all requests to .localhost to go over 127.0.0.1 (maybe ::1 in the case of ipv6?).

Example showing what I mean where I've deliberately poisoned my DNS:

Click to expand


[lidel]

@aidanharris Firefox is working on implementing let-localhost-be-localhost as well. Work can be tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c41

---

Is it possible to register new protocols in the modern browsers (like we basically already do with ipfs:// and ipns:// via the addons) but let the browser speak directly to the API instead of redirecting it to the web gateway?

@RubenKelevra Not at the moment, but we hope it will be possible then the last Milestone of protocol-handler-api-for-browser-extensions.md lands in some form in Chromium/Firefox. Right now we are looking into allowing dweb protocols in navigator.registerProtocolHandler – you can track that in https://bugs.chromium.org/p/chromium/issues/detail?id=651311

---

:point_right: Please let's avoid further off-topics, this issue is about picking ports :-)

[RubenKelevra]

How did I come to this idea? I converted the lowercase letters of ipfs to their decimal values and just added up the digits.

i = 105 = 6 p = 112 = 4 f = 102 = 3 s = 115 = 7

The fact that apparently this port is unasigned (according to speedguide.net) made me think it was a good alternative port. At least it's not a totally random number.

I think this would be a neat API-Port.

Swarm should be ideally port 443 UDP+QUIC/TCP for servers, to avoid firewall restrictions. On all other nodes, we should use IMHO a random port (where we don't have any privileges to use 443).

That's what browsers are doing for WebRTC as well, so either this works or we need to use a relay for incoming connections and won't take part on the DHT.

Sure, users could create port forwardings in their routers, but TBH most users don't even know what ports are and why they need to open one. Instead, we could advise them to activate UPnP in their routers.

Furthermore, devices will become more and more mobile so users are switch between their wifi, the wifi of their coffee shop, the wifi at work, and their mobile connection. Most of these connections won't allow any configurations by the users. So we need a solution which just 'works'.

A static port isn't really helpful in those cases, but is prone to blocking and like BitTorrent has seen in the past, getting a lower quality of service when much data is transferred over it.

Since the web gateway port is somewhat of a transition technology, I think we shouldn't give this one that much attention. Just use one which isn't used that much.

The best-case scenario is port 80 in this case, but this is probably hardly possible in most installations.

[lidel]

*.localhost is now marked as a secure context in both Firefox and Chromium: https://blog.ipfs.io/2021-01-15-ipfs-and-igalia-collaborate-on-dweb-in-browsers/

Back to the original topic, CISCO's acwebsecagent seems to like port 5001 (https://github.com/ipfs/go-ipfs/issues/7865#issuecomment-761181698):

Looking at the pid that's using 5001 (3168), I see:

root              3168   0.0  0.0  4758748   8492   ??  S     3:23PM   0:00.23 /opt/cisco/anyconnect/bin/acwebsecagent -console

[RubenKelevra]

@lidel

I think we got two ports now: 4737 from @jbenet and 6437 from @ruverav.

How about using the 4737 for the web gateway function and 6437 for the more technical API port by default?

The swarm port should just be randomly chosen by default to avoid conflicts and avoid that we receive packages from an old instance after a restart of the daemon.

If one of them is blocked, the daemon could just increase both by 1 until both are free. While not ideal this solves the issue with multiple instances running on the same machine without user interventions.

[melroy89]

I still would like to see specifically port 8080 (Gateway) to change for sure (eg. 6547 is fine).

[Winterhuman]

@Stebalien Any update on this?

[lidel]

We have $IPFS_PATH/api for indicating HTTP RPC port. I think we need $IPFS_PATH/gateway proposed in https://github.com/ipfs/go-ipfs/issues/8847 before we start considering any port change (with that, ipfs-desktop and other tools will be able to find the Gateway port no matter what it is). If anyone has bandwidth to implement the above, it will speed up the timeline on this.

[micahscopes]

This would make the "mixing IPFS with torrents" hack more reliable and less dependent on public gateways:

https://www.reddit.com/r/ipfs/comments/qnlrgx/mixing_ipfs_and_torrents/

[Jorropo]

@micahscopes this issue is blocked on #8847

[micahscopes]

@micahscopes this issue is blocked on #8847

Good to know! I was just chiming in with another usecase for this