[lossolo]

1. Use nickserv and chanserv? This is solved problem.

2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.

[Karunamon]

Re 1: Most users of Slack don't even use the slash commands, so I'd say that requiring what ammounts to CLI syntax to manage channels and accounts, something you get for free in a user-friendly way in most modern communication tools, is a nonstarter.

Re 2: ZNC works, but is a really trash user experience from both sides. For instance, you never really know if someone is there or not. Also no push messages, which breaks the "get this person's attention" thing that most people use it for.

And you get the same problem if for some reason the bouncer loses connectivity.

[efreak]

1. GUIs can be (and have been) written for channel management and other functions. There's multiple clients (or client plugins) for such functions as changing modes (with checkboxes), changing the topic, etc.

2. ZNC has plugins for push messages, or at least it did when I was using it several years ago. My personal bouncer was configured to automatically set my away status when I went offline; alternatives include (de)voicing (in)active users, changing nickname, etc. When my bouncer had no clients connected and someone sent me a pm, it was configured to send a message to Pushbullet.

If you're not using a bouncer or the bouncer is down, services packages such as anope may include a memoserv for sending messages to offline users; on services login, memoserv will notify you of pending messages.

[Karunamon]

1: At the client level, sure. Where's the ChanServ/NickServ/OperServ GUI (that interoperates with the 5 or 6 most common service packages?)

2: Which ties right back into point 1 that setting this up is not user-friendly.

[KirinDave]

1 doesn't really solve the problem.

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.

[lossolo]

> doesn't really solve the problem.

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.

[KirinDave]

> Care to elaborate? It solves authentication for us and we are using it for 10+ years like this

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.

[lossolo]

> If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.

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.

[KirinDave]

> plaintext? 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.

Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration

Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with that.

> TLS usage is mandatory and passwords are not stored in it plaintext. I think your knowledge about how IRC is used now is a little outdated.

> VPN -> znc -> IRC

Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?

Even having a decent in-home internet connection, a way to route traffic back into your network, and a raspberry pi to host it on is a tall order.

[tastroder]

> Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration

You can do all that over an encrypted connection [1] if you like. All this protocol nitpicking kind of ignores that IRC is a stack that is a) open to a multitude of clients and thus use cases (vs. all those fancy web-things that offer me either lockin and emojis or a lack of user base) and b) proven over decades. Yeah, it has it's inherited edge cases and downsides but this thread makes it seem like it's a stupid idea somebody came up with in 2 hours, which it is absolutely not.

[1] https://freenode.net/kb/answer/chat

[lossolo]

> Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with that.

We are running our own IRC servers and you can't connect without using TLS, I still don't know what's your issue is with the registration ? You would need to have access to the machines that are running IRC servers to use that information. It's like saying that none of the standard authentication over the internet (login + password to your bank, your slack account, google cloud etc) using encrypted connection is not secure because you are entering password in plaintext.

> Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?

It's hosted at one of the largest datacenters in Europe. We are not using cloud. Cost is low, very low, compared to Google cloud/AWS we are paying around 50x times less for our whole infrastructure. But we digress now from the main discussion.

> Are you paying for a VPN service (please no)?

We are running our own VPN servers on dedicated hardware.

[aidenn0]

I agree with you on persistent logs, but I authenticate with an SSL client certificate, not a password. This is supported by several networks. Also, what do you mean by "plaintext"? Good id services will store a hashed password and the irc connection can be over SSL. That's no more plaintext than any web service login.

[KirinDave]

The difference being that there are absolutely no better options. Everyone agrees the login form model is insufficient and that's why anyone who takes personal security seriously now introduces a lot of infrastructure around their logins.

But aside, it seems like not all networks support TLS logins?

As it stands, I have no IRC equivalent of a 2FA key. I present a plaintext token and hope that it's all handled properly and that I'm not a victim of a password reuse attack.

Any web based solution is light years ahead on this.

[tastroder]

> As it stands, I have no IRC equivalent of a 2FA key. I present a plaintext token and hope that it's all handled properly and that I'm not a victim of a password reuse attack. > Any web based solution is light years ahead on this.

That's also the case for 99% of authentication in the web context. 2FA adoption is on the rise but by no means the standard. If it was a thing users asked for, there's no protocol reason a nickserv service and clients couldn't adopt a 2FA flow, even without breaking backwards-compatibility.

[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.