6 ms·

> Because IRC works. It's open, battle tested and has huge support by an endless amount of tools and documentation. There is not much reason to not use if all y

> Because IRC works. It's open, battle tested and has huge support by an endless amount of tools and documentation. There is not much reason to not use if all you wanna do is chat. How about encryption?

dijit 4y ago
TLS is accepted, since you implicitly trust the server when using chatrooms in most cases. for everything else there are plugins in your client for OMEMO (what signal is based on) and OTR (which is purely session based). Handling this as a third-party implementation for E2EE is probably the only true way to gain trust anyway. If your provider provides the infrastructure and the client then how can you really trust it?
- sdfhdhjdw3 4y ago
  I'm not a security expert, but my humble view is that if you need plugins for really basic functionality, that's a red flag.
  - dijit 4y ago
    "E2EE" is not really basic functionality. I believe it is hard to get right, and only worthwhile on 1:1 communication, it doesn't work well at all on large chat rooms, which is what IRC is. Regardless, if you don't want E2EE to be handled by a plugin- it is possible to make a client with it baked in. There is no company that will stop you creating a third-party client unlike slack/discord which are extremely hostile to those endeavors by comparison. EDIT: If you downvote without replying I'm just going to assume you're ideologically opposed to open standards, because I'm not sure what else I can take from it.
    - sdfhdhjdw3 4y ago
      I didn't downvote, and I'm very pro open standards. I just think we can do better than IRC, that's all.
      - dijit 4y ago
        Ah, I wasn't accusing you of downvoting, just the community. You can't downvote direct replies. --- Speaking about standards; have you looked at IRCv3? Is there anything specific that you feel is not being addressed? Encryption (to my mind) is better handled outside of the spec itself, just like HTTP vs TLS wrapped HTTP (HTTPS) where the "TLS" has no bearing at all on how HTTP is implemented. IRCv3 is attempting to address the persistence issues, though many people like the lack of persistence in general. I don't want to guess at what your concerns are, but more generally; have you looked at the spec?
  - deleted 4y ago
    [deleted]
  - numpad0 4y ago
    It's not really a green flag when values offered by major commercial alternatives seems like then-experimental client features of existing thing(cf. Twitter, Slack, Discord)
- rdpintqogeogsaa 4y ago
  Yet there are also large networks like QuakeNet or UnderNet with no TLS anywhere.
  - dijit 4y ago
    And you can choose not to be there. My network forces TLS: https://darkscience.net https://darkscience.net Forcing people to "do what you want" is against the spirit of open standards.
    - deleted 4y ago
      [deleted]
ddevault 4y ago
If IRC were designed today, it would probably be with E2EE. But it's not the end of the world that it wasn't, it just limits what use-cases it's appropriate for. Asking about kernel config options in #linux does not really demand particularly high privacy, and TLS between you and the server is generally sufficient. E2EE is also pretty difficult to get right and dramatically increases the complexity of the system -- Matrix's third-party client ecosystem is hamstrung by this requirement and very poor compared to IRC as a result. E2EE is nice to have and essential for some use-cases, but I don't think that IRC is invalid because it lacks it.
- sdfhdhjdw3 4y ago
  So I tried Matrix yesterday for the first time in my life, despite having heard about it in passing for years on end. It's fucking slow.
  - Idesmi 4y ago
    The matrix.org server is slow.
300bps 4y ago
I haven't heard of a widely-used IRC client that doesn't have built-in SSL connectivity for quite some time. For example: https://www.mirc.com/ssl.html https://www.mirc.com/ssl.html
astrobe_ 4y ago
When a platform does not guarantees secrecy you just avoid holding private conversations on it. In my opinion, that's the spirit of IRC, a public place to discuss, because often channels are logged and the logs are accessible for anyone from the web. If not, just about anyone on a channel can do it without your consent. That's also true I think with other "secure" chat platforms because that's the nature of any-to-any chat protocols. Then you use private messages as a way to talk to someone without disturbing, or away from the noise, of the channel - still not for really private conversations ; for this you don't need encryption, you need end-to-end encryption, but at this point you'd rather use a messaging platform rather than a chat platform.
usrn 4y ago
Encryption makes more sense for small or one on one chats with people you know, the sorts of things people use XMPP for (which has OMEMO: signal style encryption.) In large public chat rooms being able to use a pseudonym is much more important than encryption.
ThatGeoGuy 4y ago
There are OTR / OMEMO implementations out there for private queries. For rooms, I'm not convinced that we need full Olm / Megolm style encryption in most wider chats - encrypting messages across 200 individual parties with a magnitude more individual clients is perhaps just yak-shaving. I even learned today that irssi has an OTR module by default! On Debian systems you have to install irssi-plugin-otr but once you have that and irssi you can just `/load otr` and `/otr init` in a query and that's it, you have E2EE. This is handled client side though, so I suppose if your clients cannot agree on a protocol you'll be left with nothing. I'm not sure that's really the responsibility of the server though, since we're talking E2E after all.

dijit 4y ago

TLS is accepted, since you implicitly trust the server when using chatrooms in most cases. for everything else there are plugins in your client for OMEMO (what signal is based on) and OTR (which is purely session based). Handling this as a third-party implementation for E2EE is probably the only true way to gain trust anyway. If your provider provides the infrastructure and the client then how can you really trust it?

sdfhdhjdw3 4y ago
I'm not a security expert, but my humble view is that if you need plugins for really basic functionality, that's a red flag.
- dijit 4y ago
  "E2EE" is not really basic functionality. I believe it is hard to get right, and only worthwhile on 1:1 communication, it doesn't work well at all on large chat rooms, which is what IRC is. Regardless, if you don't want E2EE to be handled by a plugin- it is possible to make a client with it baked in. There is no company that will stop you creating a third-party client unlike slack/discord which are extremely hostile to those endeavors by comparison. EDIT: If you downvote without replying I'm just going to assume you're ideologically opposed to open standards, because I'm not sure what else I can take from it.
  - sdfhdhjdw3 4y ago
    I didn't downvote, and I'm very pro open standards. I just think we can do better than IRC, that's all.
    - dijit 4y ago
      Ah, I wasn't accusing you of downvoting, just the community. You can't downvote direct replies. --- Speaking about standards; have you looked at IRCv3? Is there anything specific that you feel is not being addressed? Encryption (to my mind) is better handled outside of the spec itself, just like HTTP vs TLS wrapped HTTP (HTTPS) where the "TLS" has no bearing at all on how HTTP is implemented. IRCv3 is attempting to address the persistence issues, though many people like the lack of persistence in general. I don't want to guess at what your concerns are, but more generally; have you looked at the spec?
- deleted 4y ago
  [deleted]
- numpad0 4y ago
  It's not really a green flag when values offered by major commercial alternatives seems like then-experimental client features of existing thing(cf. Twitter, Slack, Discord)
rdpintqogeogsaa 4y ago
Yet there are also large networks like QuakeNet or UnderNet with no TLS anywhere.
- dijit 4y ago
  And you can choose not to be there. My network forces TLS: https://darkscience.net https://darkscience.net Forcing people to "do what you want" is against the spirit of open standards.
  - deleted 4y ago
    [deleted]

ddevault 4y ago

If IRC were designed today, it would probably be with E2EE. But it's not the end of the world that it wasn't, it just limits what use-cases it's appropriate for. Asking about kernel config options in #linux does not really demand particularly high privacy, and TLS between you and the server is generally sufficient. E2EE is also pretty difficult to get right and dramatically increases the complexity of the system -- Matrix's third-party client ecosystem is hamstrung by this requirement and very poor compared to IRC as a result. E2EE is nice to have and essential for some use-cases, but I don't think that IRC is invalid because it lacks it.

sdfhdhjdw3 4y ago
So I tried Matrix yesterday for the first time in my life, despite having heard about it in passing for years on end. It's fucking slow.
- Idesmi 4y ago
  The matrix.org server is slow.

300bps 4y ago

I haven't heard of a widely-used IRC client that doesn't have built-in SSL connectivity for quite some time. For example: https://www.mirc.com/ssl.html https://www.mirc.com/ssl.html

astrobe_ 4y ago

When a platform does not guarantees secrecy you just avoid holding private conversations on it. In my opinion, that's the spirit of IRC, a public place to discuss, because often channels are logged and the logs are accessible for anyone from the web. If not, just about anyone on a channel can do it without your consent. That's also true I think with other "secure" chat platforms because that's the nature of any-to-any chat protocols. Then you use private messages as a way to talk to someone without disturbing, or away from the noise, of the channel - still not for really private conversations ; for this you don't need encryption, you need end-to-end encryption, but at this point you'd rather use a messaging platform rather than a chat platform.

usrn 4y ago

Encryption makes more sense for small or one on one chats with people you know, the sorts of things people use XMPP for (which has OMEMO: signal style encryption.) In large public chat rooms being able to use a pseudonym is much more important than encryption.

ThatGeoGuy 4y ago

There are OTR / OMEMO implementations out there for private queries. For rooms, I'm not convinced that we need full Olm / Megolm style encryption in most wider chats - encrypting messages across 200 individual parties with a magnitude more individual clients is perhaps just yak-shaving. I even learned today that irssi has an OTR module by default! On Debian systems you have to install irssi-plugin-otr but once you have that and irssi you can just `/load otr` and `/otr init` in a query and that's it, you have E2EE. This is handled client side though, so I suppose if your clients cannot agree on a protocol you'll be left with nothing. I'm not sure that's really the responsibility of the server though, since we're talking E2E after all.