Rename `Swarm` to `Switch` due to changing specification naming.

[Jerrody]

If we look at the specification page where describes concepts how works libp2p we can see this:

The term “swarm” was previously used to refer to what is now called the “switch”, and some places in the codebase still use the “swarm” terminology.

[mxinden]

In my opinion implementations don't need to be consistent on the API level, only on the network level. In this concrete case, I don't think renaming just for the sake of consistency is worth it.

That said, I am in favor of renaming Swarm to something more intuitive. I don't think Switch is more intuitive than Swarm. Rather I would expect Endpoint to be more self-explanatory.

What do folks think?

[Jerrody]

In my opinion implementations don't need to be consistent on the API level, only on the network level. In this concrete case, I don't think renaming just for the sake of consistency is worth it.

That said, I am in favor of renaming Swarm to something more intuitive. I don't think Switch is more intuitive than Swarm. Rather I would expect Endpoint to be more self-explanatory.

What do folks think?

Well, I'm a man for which following certain conventions is one of the most important things. If they said that this is should be like this I will do this. What about naming: Swarm, in my opinion, is a tunnel, pool, handler, or something in this way. I would name it like a Network, Port, Thread, Tunnel, Handler, or Gateway. It has more information on what is this. For me, Handler is a good and interesting variant for naming. But I can be not right because I worked with libp2p for one day :D

[rkuhn]

The term “swarm” is getting more and more established for peer-to-peer networks, even outside non-technical communities (it is used for example by the EU commission).

When naming an API, my first question is “what problem does it solve?” Formulated differently, when using this API, what will it do for me or give me access to? As such, the current Swarm is aptly named, since it is my handle for and window into the peer-to-peer network. swarm.events() and swarm.find_peer() and swarm.gossip() are operations that make sense to me. We could rename it to “colony” to push it more onto the engineering side, “school” if the nodes are all just replicating each other, or “clowder” while it isn’t really working in the sense that we want :-)

[thomaseizinger]

I've always struggled with the term Swarm because it sounds to me like I am instantiating a "swarm" of something, yet an application is actually part of a swarm and what you are creating is just one instance. Perhaps we should rename it to Bee? :P

In other projects, I've called the wrapper struct around Swarm:

• Node
• Network

[Jerrody]

I've always struggled with the term Swarm because it sounds to me like I am instantiating a "swarm" of something, yet an application is actually part of a swarm and what you are creating is just one instance. Perhaps we should rename it to Bee? :P

In other projects, I've called the wrapper struct around Swarm:

• Node
• Network

For me it's associates more likely with Swarm in malware's world.

[dadepo]

In my opinion implementations don't need to be consistent on the API level, only on the network level

What do folks think?

From an outsider trying to get into rust-libp2p, having some form of consistency helps.

When I initially dug into the code, I was not really sure where swarm fits into the picture, until I read in the spec/documentation about switch and that this was previously named swarm.

So given the fact that the spec/documentation is going to be one of the places someone new is going to consult to know more about how the library works, it definitely helps to see similar concepts bear the same name.

[thomaseizinger]

I think go-libp2p calls this Host so this might be a good candidate.

[thomaseizinger]

Closing as stale.