2 is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.
Care to elaborate? It solves authentication for us and we are using it for 10+ years like this.
> is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.
Let me check my current znc IRC session signon: Wed Jul 18 07:43:12
So almost a year.
If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.
> Let me check my current znc IRC session signon: Wed Jul 18 07:43:12
Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.
plaintext? In our use case TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated.
> Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.
VPN -> znc -> IRC
You don't need to be rich and lucky to replicate this. Signon time was from znc to irc, not from my home connection to irc.
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.
> 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.
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.
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.
