IPFS cluster applications namings about ipfs-cluster

[hsanjuan]

Yes, which is why I never understood that one either

[hsanjuan]

why do we call it clusterd if its not a daemon? Can't we call it simply ipfs-cluster?

[whyrusleeping]

clusterd will be a daemon, in the same way that ipfs daemon is a daemon

[hsanjuan]

But it doesn't daemonize ? The daemon terminology has pretty strong implications (https://en.wikipedia.org/wiki/Daemon_(computing))

[Kubuxu]

as a matter of fact go-ipfs doesn't demonize either.

[jbenet]

• Terminology is not always super precise. the word daemon is used for all sorts of things.
• For example, etcd is a "daemon", but i believe it also works like go-ipfs. What about the httpd variants? what about systemd and variants? There's definitely other <thing>ds out there that expect you to damonize it. Many tools don't daemonize themselves at all, or have flags not to do it. because "how to daemonize" is not a simple topic-- there's lots of complicated devops concerns there, and developers have learned to leave it up to you / the packagers / the OS.
• Terminology is created by mortals, and is often laden with historical decisions, some of them mistakes, some of them changing over time. Names are meant to convey a set of ideas. when the ideas change, or the names apply to more or less ideas, the strictness of a name loosens or tightens. The word daemon has been so over used that it no longer means something as specific as "a set of tools that run themselves as background processes". Certainly colloquially, daemon is way more general these days. It usually just means "a service meant to be run behind the scenes" (which is ironically what it meant in the very beginning, before it grew more specific, and then less specific), and doesn't mean all of https://en.wikipedia.org/wiki/Daemon_(computing)#Creation .
• Name alternatives include: "daemon", "server", "service", ... any others?
• Server is a worse name here because "server" specifically calls in a bunch of other definition problems, in huge centralized web client-server design space. Thus renaming ipfs daemon as ipfs server would be a bad idea. we want to encourage people to think about peer <-> peer and nodes, not client->server.
• Service may be ok. it's a bit to enterprisey and not unixey, but if we think this would make an important difference, and we should start calling tools <thing>s or <thing>-service and <thing>-ctl, it may be ok. <thing>s has obvious problems.

[hsanjuan]

Thanks for jumping in @jbenet . These are valid reasons . I wanted to have this conversation (its related to IPFS cluster user-interfaces as a whole, including APIs). It is important that we choose wisely and I'm happy to give up on my preferences. The important thing is that we can find a formula that is meaninful in our ecosystem (or in our future ecosystem).

So the question is: which one would you [and others] prefer?

• ipfs-clusterd
• ipfsclusterd
• clusterd
• ipfs-cluster-service
• ipfscluster-service
• ...?

Same for the client tool?

• ipfscluster-ctl
• ipfs-cluster-ctl
• ipfscluster

[Kubuxu]

Most tools don't separate the ctlwith dash.

[hsanjuan]

In offline discussion with @jbenet we settled for:

• ipfs-cluster-service
• ipfs-cluster-ctl

This can still be changed in the future but I'll move forward with that for the moment.