6 ms·

IRC is great and you can do SSL connections and also encrypted DCC transfers on some servers (Abjects/#moviegods, for example)

_flux 3y ago
However actually establishing those DCC connections in the first place might need some configuration in a typical consumer internet setup? I've been playing with the idea of adding IRC support to my prototype Matrix WebRTC transfer tool mxrxtx, but I haven't touched that for a while.. And I wouldn't have any use for it anyway.
- Arathorn 3y ago
  ooh, mxrxtx sounds interesting - is this solving https://github.com/matrix-org/matrix-spec/issues/189 https://github.com/matrix-org/matrix-spec/issues/189?
  - _flux 3y ago
    Yes, I think it solves that as-is. But I'm hoping a future version of it would also solve some other scenarios, like when I share a file from a mobile to a room it would leverage an already running desktop session with better battery and better connectivity. Another axis is providing a well-tested specficiations and providing it as a library that could be easily integrated into apps. I have a TLA+ spec of the existing solution, so I hope the "next" version would also be as precisely specified, probably using Quint.
- M95D 3y ago
  And this is how good old services, protocols and standards get enshittified. Welcome to HTTP(S) v121.99.5146.
  - _flux 3y ago
    You don't actually need HTTP(S) to make use of WebRTC, though, if that's what you were implying. For data transmission WebRTC layers on top of SRTP and the developer just needs to provide a way to pass the handshake data over some medium; could be an HTTP server, could be a Matrix room, could be an IRC channel (or PRIVMSG). And in the worst case it can also use STUN or TURN to solve the NAT issue which DCC makes zero attempts to. Perhaps you can clarify what you mean by enshittification? I suppose the reality with NAT isn't the great, but it's not really about protocols but the way systems end up being built.
    - M95D 3y ago
      > You don't actually need HTTP(S) to make use of WebRTC, though, if that's what you were implying. I wasn't aware that WebRTC can use other transports, but that wasn't the point. It was about the embrace-extend-extinguish of IRC protocol. I'm OK with embrace. I'm NOT OK with extend. It leads to extinguish. > I suppose the reality with NAT isn't the great, but it's not really about protocols but the way systems end up being built. How many GB of nodejs or some other crap need to be imported just to solve a NAT problem? It's just a text messenger FFS! Why can't you just document which are the incoming ports and let the user decide the forwarding or firewall setup, like we did for the last 25 years?? And why put WebRTC in a text messenger? That's for video calls.
      - _flux 3y ago
        You can use https://github.com/paullouisageneau/libdatachannel https://github.com/paullouisageneau/libdatachannel for your C/C++ integration needs. It's 10k lines. So the answer is 0. Its required dependencies (I assume this as they are git submodules in deps) are more than 100k lines, though, srtp support making the bulk of it. On my machine it took 11 seconds to compile it. Irssi is 64k lines (plus its dependencies), so I guess that makes WebRTC complicated. Can't argue that DCC isn't simple, but perhaps the protocol deviced decades ago is a bit too simple.
        M95D 3y ago
        Each protocol serves a purpose - it's ORIGINAL purpose. To extend it like this means to degrade it's original usefulness, make it complicated to create new implementations and it won't even compete with a new protocol specifically designed for the new purpose. All this leads to "extinguish" phase. IRC was implemented in probably hundreds of programs (many/most from scratch, not by importing the same library!). There's even an implementation for Arduino! It's a successful protocol as it is now. Could you run it on Arduino if it had WebRTC in it?
        _flux 3y ago
        Probably not, but is it worth starting new projects with 16-bit MCUs in the year 2024? 32-bit MCUs are cheap and plentiful in offering. I realize the IRC protocol is easy to implement (though the protocol itself has flaws that make it difficult e.g. to identify which message is a response to your query, IRC3 addresses this) and I too have done it in the past, but I see zero reasons to embrace it today.
- dijit 3y ago
  That's mostly due to NAT. When we have some more widespread IPv6 adoption we could (and should already) look into supporting IPv6 with DCC, that would make it function properly and dare-I-say would be excellent from a UX perspective.
  - _flux 3y ago
    It could be the future—unless non-permissive firewall configurations ruin it.
  - blibble 3y ago
    with ipv6 there's still a firewall on the border router that will prevent incoming connections reaching your local machine's random ports this is entirely a client problem, even with NAT there's no reason the IRC client couldn't do DCC using modern style hole punching (with the IRC server mediating)
    - dijit 3y ago
      I disagree, anything that requires Peer-to-peer needs to be considered, so firewalls will always support some kind of upnp. Else the gamers and the people who rely on voip are going to go ballistic.
      - blibble 3y ago
        both games and voip have used STUN for the past decade or so
- fddrdplktrew 3y ago
  [dead]
Avamander 3y ago
Except it directly reveals your IP to the other peer. Might as well share a magnet link. Though I would indeed like direct file transfer for more usual purposes in other chat clients. Would be great with Matrix/Element.
- fddrdplktrew 3y ago
  LoL... sharing your IP with a hacked server doesn't really affect me... but when I use magnets links from my home IP, I keep being harassed by Comcast.
- weberer 3y ago
  You connect to a server, not a peer. Your client does no uploading.
  - Avamander 3y ago
    The client receiving will connect to the one sharing the file. Routing the data through the IRC network would be unreasonable. This reveals your IP, which is kinda bad. https://www.tg007.net/archive/tutorials/showdocca03.html https://www.tg007.net/archive/tutorials/showdocca03.html
  - crtasm 3y ago
    DCC stands for Direct Client to Client

_flux 3y ago

However actually establishing those DCC connections in the first place might need some configuration in a typical consumer internet setup? I've been playing with the idea of adding IRC support to my prototype Matrix WebRTC transfer tool mxrxtx, but I haven't touched that for a while.. And I wouldn't have any use for it anyway.

Arathorn 3y ago
ooh, mxrxtx sounds interesting - is this solving https://github.com/matrix-org/matrix-spec/issues/189 https://github.com/matrix-org/matrix-spec/issues/189?
- _flux 3y ago
  Yes, I think it solves that as-is. But I'm hoping a future version of it would also solve some other scenarios, like when I share a file from a mobile to a room it would leverage an already running desktop session with better battery and better connectivity. Another axis is providing a well-tested specficiations and providing it as a library that could be easily integrated into apps. I have a TLA+ spec of the existing solution, so I hope the "next" version would also be as precisely specified, probably using Quint.
M95D 3y ago
And this is how good old services, protocols and standards get enshittified. Welcome to HTTP(S) v121.99.5146.
- _flux 3y ago
  You don't actually need HTTP(S) to make use of WebRTC, though, if that's what you were implying. For data transmission WebRTC layers on top of SRTP and the developer just needs to provide a way to pass the handshake data over some medium; could be an HTTP server, could be a Matrix room, could be an IRC channel (or PRIVMSG). And in the worst case it can also use STUN or TURN to solve the NAT issue which DCC makes zero attempts to. Perhaps you can clarify what you mean by enshittification? I suppose the reality with NAT isn't the great, but it's not really about protocols but the way systems end up being built.
  - M95D 3y ago
    > You don't actually need HTTP(S) to make use of WebRTC, though, if that's what you were implying. I wasn't aware that WebRTC can use other transports, but that wasn't the point. It was about the embrace-extend-extinguish of IRC protocol. I'm OK with embrace. I'm NOT OK with extend. It leads to extinguish. > I suppose the reality with NAT isn't the great, but it's not really about protocols but the way systems end up being built. How many GB of nodejs or some other crap need to be imported just to solve a NAT problem? It's just a text messenger FFS! Why can't you just document which are the incoming ports and let the user decide the forwarding or firewall setup, like we did for the last 25 years?? And why put WebRTC in a text messenger? That's for video calls.
    - _flux 3y ago
      You can use https://github.com/paullouisageneau/libdatachannel https://github.com/paullouisageneau/libdatachannel for your C/C++ integration needs. It's 10k lines. So the answer is 0. Its required dependencies (I assume this as they are git submodules in deps) are more than 100k lines, though, srtp support making the bulk of it. On my machine it took 11 seconds to compile it. Irssi is 64k lines (plus its dependencies), so I guess that makes WebRTC complicated. Can't argue that DCC isn't simple, but perhaps the protocol deviced decades ago is a bit too simple.
      - M95D 3y ago
        Each protocol serves a purpose - it's ORIGINAL purpose. To extend it like this means to degrade it's original usefulness, make it complicated to create new implementations and it won't even compete with a new protocol specifically designed for the new purpose. All this leads to "extinguish" phase. IRC was implemented in probably hundreds of programs (many/most from scratch, not by importing the same library!). There's even an implementation for Arduino! It's a successful protocol as it is now. Could you run it on Arduino if it had WebRTC in it?
        _flux 3y ago
        Probably not, but is it worth starting new projects with 16-bit MCUs in the year 2024? 32-bit MCUs are cheap and plentiful in offering. I realize the IRC protocol is easy to implement (though the protocol itself has flaws that make it difficult e.g. to identify which message is a response to your query, IRC3 addresses this) and I too have done it in the past, but I see zero reasons to embrace it today.
dijit 3y ago
That's mostly due to NAT. When we have some more widespread IPv6 adoption we could (and should already) look into supporting IPv6 with DCC, that would make it function properly and dare-I-say would be excellent from a UX perspective.
- _flux 3y ago
  It could be the future—unless non-permissive firewall configurations ruin it.
- blibble 3y ago
  with ipv6 there's still a firewall on the border router that will prevent incoming connections reaching your local machine's random ports this is entirely a client problem, even with NAT there's no reason the IRC client couldn't do DCC using modern style hole punching (with the IRC server mediating)
  - dijit 3y ago
    I disagree, anything that requires Peer-to-peer needs to be considered, so firewalls will always support some kind of upnp. Else the gamers and the people who rely on voip are going to go ballistic.
    - blibble 3y ago
      both games and voip have used STUN for the past decade or so
fddrdplktrew 3y ago
[dead]

Avamander 3y ago

Except it directly reveals your IP to the other peer. Might as well share a magnet link. Though I would indeed like direct file transfer for more usual purposes in other chat clients. Would be great with Matrix/Element.

fddrdplktrew 3y ago
LoL... sharing your IP with a hacked server doesn't really affect me... but when I use magnets links from my home IP, I keep being harassed by Comcast.
weberer 3y ago
You connect to a server, not a peer. Your client does no uploading.
- Avamander 3y ago
  The client receiving will connect to the one sharing the file. Routing the data through the IRC network would be unreasonable. This reveals your IP, which is kinda bad. https://www.tg007.net/archive/tutorials/showdocca03.html https://www.tg007.net/archive/tutorials/showdocca03.html
- crtasm 3y ago
  DCC stands for Direct Client to Client