I used to work customer service at a Fortune 500 company, and on nights and weekends the calls went to call answering service where they’d take all the request info/complaints/issues/whatever down and then enter it into a system that sent my department an e-mail, but there was no instant, right then service.
I think your expectations are unrealistic. Few things besides true emergency services such as police, fire, and medical truly run 24/7/365.
Well, a person made the decision to have that server downtime script function as it does, so… gotta give the humans SOME credit, man. 
Well… unless CCP has done some truly groundbreaking AI work and the AI now controls our downtimes… that’d be pretty cool, I guess, but they probably shouldn’t keep such news under wraps, eh?
Come PVE in wormholes. You’ll never be 100% safe, but there’s no local for the attackers OR the defenders and your can roll holes for a slightly safer environment to shoot lasers at rocks and/or rats.
Sorry to be blunt, but you’ve just made clear you simply don’t know what you are talking about.
To finish on a lighter note without entering into a worthless argument, “those are not the services you’re looking for” - and it would seem you’d be surprised to learn how many systems are indeed required to run 24/7/365, with little or no downtime.
Correct; but it is not the leaving/joining in isolation but also because the game cluster must announce every pilot in local channels (through admin messages that all clients pick up and process but do not display) even if the client of that pilot has not joined that local channel.
A practical example: You are jumping from A to B.
In normal chat the game cluster would call the chat cluster and revoke your access to local A and grant you access to local B. The chat cluster would in response kick you from local A and notify you and all clients in local A. It would then wait for your client to connect to local B and then announce you in local B. For large channels you would not get the full member list and any member list updates might be batched and/or delayed. All very minimal and moderately time critical; very chill.
In EVE chat the game cluster calls the chat cluster, revokes your access to local A, grants you access to local B and then through admin messages immediately announces you having left local A and joined local B. The chat cluster kicks you from local A and notifies your client and other clients in local A. It then waits for your client to connect to local B and then announces you in local B (again; these action/messages may happen in various order since this is a distributed system, but there is always double notification). For large channels you get the full member list when you join and any member list changes are broadcasted immediately. Care must be taken in heavy traffic channels to ensure that you get all individual changes compared to the full member list set you received at the beginning; if the list is snapshotted at time X then you must receive all individual updates at X+ even if you haven’t received the full list yet (you might not have received the list because it takes time to transmit that large list and process it compared to the smaller individual notifications).
Recently we have been looking at the performance of ejabberd, e.g. how it caches data and performance optimizing ejabberd code, and have been deploying such improvements regularly.
Today at downtime (16 Jan) we deployed a rewrite of this snapshotting and transmitting of the initial full member list because the previous implementation was causing issues (including blocking of subsequent actions).
So…
If Local ceased being a thing and all chat happened at the Constellation chat level (which already exists)
We would have far less of an issue even though we had bigger chat rooms, because the leave/joins would be less frequent.
And if we went to delayed local or delayed constellation… I believe constellation is already delayed, that would also pretty much resolve the issue?
I realise that this would be a feature change, but there are some pretty strong arguments in favour of such a change especially given how much it exposes bots who are far less able to accurately interpret Dscan reports and intel channel warnings accurately compared to a player.
Do I understand this correctly? For an average not-jita system, you don’t mind seeing and typing at 50 pilot names that MIGHT or might not be able to interact with you? Imagine the insults being hurled for a fight 3 systems away, maybe two simultaneous fights, all comments overlapping and more confusing than usual.
But I have a fix! Just prefix system name in front of pilot name, like we do with structures. THEN optionally add a client-side filter button …
You understand correctly. I think it’s great that I don’t know who is in my system and could be in warp to me right now, but that I only know who is in the vicinity and within 60 seconds if me if they are an inti.
Murky intel is great in my book. You know some useful things, but not everything.
So I very specifically think we shouldn’t know the persons system.
It would still give useful information like spikes from cynos off grid or roaming fleets, but no longer instantly so Dscan would be needed.
And it would still be different to WH’s where you don’t get any chat based intel at all.
N.B. Obviously murky intel is only great if everyone is under it. I’m not going to deliberately handicap myself while others get perfect intel.
Who said anything about client integration?
Most IRC servers use TLS with SASL nowadays. Then again, abuse depends on the level of authority you delegate to the client. In case of EVE, it is minimal.
P.S.
Much to your surprise, old internal chat in EVE was using a modified IRC protocol.
I mean, I wasn’t claiming my personal anecdote covers all cases, and I wasn’t working in IT or software development or anything to do with servers, but it was still a case where the service you get during business hours on M-F was/is more prompt than the service you get over nights and weekends, which is the case with a lot of businesses. Not all, ofc, but a lot.
As for systems and services that run all the time–they may be required by their companies to run 24/7/365, but that doesn’t mean they’re as essential as things like police/fire/medical in a big picture sense was my point. And thus the need for an instant response is lesser. Even if people don’t sometimes act like it is. But, as always, YMMV, and different customers have different thresholds for patience.
Interesting. I miss the ol’ IRC days. I think I used mIRC back in the 90s, myself.
I do not want to play D-Scan Online
Firstly, if CCP were to remove local, they would need to have a replacement. Null sec pvp and pve is not really something that can be done without local. You need some sort of intel on what is in the system and DSCAN is not enough.
Secondly, I’m still amazed that CCP doesn’t have a form of intel other than us getting into a single channel and posting it ourselves. Personally, if CCP were to do such things then maybe local wouldn’t actually be needed.
Sure it can. 0eople have been all through the chat disruption for the last six months.
If your statement was true no one would have ratted since the new chat because you can never know when your local is incorrect.
WH also can rat so its clearly a false claim.
As for a replacement, we already have delayed constellation in game. Just make it compulsory to be in it, not optional. And problem solved.
A. Do you even live in NULL Sec?
B. Do you not think that Local is a great form of intel whether you are PvP’ing or PvE’ing?
C. What are you talking about by, delayed constellation in game as a replacement? (seriously, i’d like to know)
And WH Space == DSCAN Space. No thank you!
A. Not currently, have in the past just don’t have the time required for null atm. Would impact me regardless.
B. Yes it is, it’s too good Intel that it invalidates everything else. For both sides pretty much.
C. I believe some Intel is good. Constellation chat allows you to know what is in your area without being as precise as local, so you still have to use other mechanics to exactly locate but you get some Intel. It is currently delayed which also allows a window for fast movers to get in or through unnoticed.
And the fact that you dont have to bother deep scanning at all is what I consider a bad thing.
I’ve got mixed feelings on that one. Removing it would disincentivize roaming as a form of PVP, and it would incentivize targeting rookies who haven’t quite figured out dscan. I don’t think either of those outcomes is desirable. It might temporarily make it easier to hunt bots until they adapt, but I’m legitimately not sure if that helps as much as the other hurts. If local gets removed for the sake of disconnecting chat from intel, something intel related needs to get added to keep the intel levels the same.
What if there was a middle ground? A “communications disruptor” structure that shoved everyone in a constellation out of local chat and into constellation? It should probably be expensive, fragile, and have high fuel cost to discourage but not prevent defensive use.
The middle ground just means as soon as your Intel is disrupted you safe up because it means someone is hunting your constellation and you get instant notice they are even before they are in your system.
I.e. it’s not middle ground
Middle ground or not (which it is) it’s better than what you suggest.
What is this Constellation chat feature you keep referencing? I cannot find any way to access such a thing within the game. There are no published channels nor any options related to enabling it that I have been able to find.
Moreover, I cannot find any description of such an EVE feature anywhere online except for an obscure reference back in 2012 that did not indicate how it works or where to find it.
Unless you can describe how to enable it, this seems like someone’s hallucination or distant flashback memory. 
Chat’s broken again…