But that's not what we were told. Another admin from espernet basically had us kill the project because they said the way Eirc was using the system constituted a "significant load" and "would not scale well". We were growing really fast and proxying maybe 3-10 users per bot connection on average. I think your team came to us with the problem right as we were really exploding with users.
We basically massively scaled back that deployment of a really cool and interesting feature. Because we didn't want to be an undue burden on our gracious hosts. Now you tell me that this was just some admin giving us an exaggeration?
That's a very frustrating detail to learn. Probably not your fault, but thanks for the clarification I guess.
Additionally, we hesitate to cater to this use-case as it often ends up turning into "we want your network to relay messages between our bots" instead of "we want to talk to other people". We've found that channels used for such bots are typically not sufficiently staffed and frequently a target of abuse, which ends up taking network staff time to resolve.
Lastly, we've had a number of technical issues supporting certain pieces of IRC client software. Older versions of EiraIRC in particular have some nasty bugs; the worst of which is that they tend to get stuck in some state where they hold multiple connections to the network open while continuing to attempt to connect again and again, with no delay. While this doesn't impose load that our servers can't handle, it does generate a lot of administrative log traffic that is bogus and dilutes important log traffic.
Many of these use cases can be covered by IRC, but our network isn't configured to handle such use easily as it often looks very similar to the sort of abuse we usually deal with. The common denominator in most cases like this is that it's taking too much of the staff's time and attention to support the channel and its clients. Our time is finite, and for the health of our network, we'd rather say "no" to a few channels than to make all channels suffer from thinner network staff resources.
Personally, I think that you're describing a lot of limitations that we nearly crashed into with the specific implementations of EsperNet at the time. I think if a more modern system were brought to bear on the problem, they wouldn't exist. But that's all speculation; I don't know EsperNet's current or previous software well enough to say with certainty.
I don't want to sound ungrateful. What we had, and what we still do have to a lesser extent, was amazing. I wish we could have scaled it, because it was well on its way to being a 40000-user-a-day connected gaming chat network expressed via the in-game chat of Minecraft.
Sadly, that's the nature of prototypes and free software. I was willing to work on EiraIRC, but the author... seemed uncomfortable with the idea when we approached them. It's... a strange corner of the world that Minecraft modders live in.
"Your use case would basically break EsperNet (but it's because of our implementation! We have a lot of issues with our implementation but they're not because IRC can't handle it!)."
If the protocol's limitations mean that their use case is not viable due to the strain it places on the administrative side, it's still a limitation.
It certainly is a limitation, but any kind of service needs DDOS mitigation.
The problem is that all traffic has to be carried to all nodes brokering connections for a channel. When you have a LOT of traffic this gets onerous.
You CAN scale these channels. But it requires some experience and most people never even consider that there might need to be action taken. The Freenode admins know what they're doing, and I respect them enormously for keeping freenode as responsive as it is on what amounts of a 25 year old, bad implementation of a distributed algorithm.