[ohithereyou]

1 is trivially solvable on the server side by requiring TLS+SASL

2 is trivially solvable on the server side by writing logs

IRC is a protocol, not a product, and an IRCd author can add these features. The fact that it has not been done speaks to the demand for these features.

[KirinDave]

I would not call running those services "trivial", but yes. If you bolt actual authentication onto something below L7 of the protocol, then you get real authentication. However, it's difficult for permission models to properly integrate with this, which is why many servers still support nickserv.

> Logs

Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.

> IRC is a protocol, not a product, and an IRCd author can add these features.

Except that to directly address these issues within the framework of IRC is impossible. Folks just push any problem they don't feel like solving down the stack, or hand tweaking of their IRCd in ways that most clients won't respect.

Using IRC to build a protocol (as anything other than the shallowest integration for a more robust chat backend) seems to be extremely niche.

>The fact that it has not been done speaks to the demand for these features

Alternative hypothesis: it's much easier to just go build something else rather than listen to folks list off a string of excuses rather than just amicably agree it's a nostalgia thing and it's not for everyone.

[ohithereyou]

>However, it's difficult for permission models to properly integrate with this, which is why many servers still support nickserv.

freenode and Rizon both support SASL, and UnrealIRCd has support built in[1]. It's not 'bolted on' as you claim, and many networks support it.

>Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.

You can add a module to an IRCd to log on the server. This is ideal in a work situation where people know they're being logged. This is not a client side method as you seem to imply.

>it's not for everyone

Nobody, especially the most 'hardcore' of IRC users I've met, would contend that everyone should be using IRC. Rather, what they're contending is that IRC has technical limitations and the people that use IRC _prefer_ having those technical limitations because their use does not require those features.

[rhizome]

>Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.

I don't understand, is this referring to running company chats on EFNet or Freenode or something? IRCd can be run locally, on an inside server or other controlled execution environment.