daemon naming

[jbenet]

Should we be naming it "daemon" or "ipfsd"? I think "ipfsd" plays more to what people expect.

[jbenet]

cc @whyrusleeping @maybebtc @mappum @cryptix

[btc]

Which of these are you thinking?

a) .../bin/ipfs ipfsd
b) .../bin/ipfsd

[jbenet]

@maybebtc ipfs ipfsd looks weird, so maybe ipfs daemon and ipfsd would be the same?

[jbenet]

But I mean more in general, when referring to it in docs, tour, etc.

[btc]

I don't have any answers... just lenses.

a) is weird. Agreed

b) introduces a new binary. This may introduce complexity to the develop/deploy/use workflow. For instance, In the wild, it would be marginally easier to end up with mismatched versions, daemon/client incompatibility hiccups. On the other hand, ipfsd could make for good documentation.

Would it be referred to as [i] "the ipfsd daemon" or [ii] "ipfsd, the ipfs daemon" or [iii] "ipfsd", omitting the word daemon entirely?

c) ipfs daemon is a bit unorthodox, but certainly friendly and approachable.

d) ipfs -d is used widely and deserves mention, but doesn't address your concern about communication at all.

[fd]

How about having a single binary (as is the case now) which has a daemon command (ipfs daemon). Then allowing a ipfsd symlink to the binary which serves as shorthand for ipfs daemon. Then ipfs only has to check argv[0] for the name of the invoked command.

ls -l bin
ipfs 
ipfsd -> ./ipfs

then the following is equivalent:

ipfs daemon
ipfsd

[whyrusleeping]

im a fan of ipfsdbut i also see how it could get into a weird version mismatch state. So i think that ipfsd should be a shell script that locates the ipfs binary, and runs ipfs daemon with optional parameters

[btc]

Given what I know now, +1 ipfsd