[_flux]

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.

[dijit]

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.

[blibble]

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]

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]

both games and voip have used STUN for the past decade or so

[_flux]

It could be the future—unless non-permissive firewall configurations ruin it.

[Arathorn]

ooh, mxrxtx sounds interesting - is this solving https://github.com/matrix-org/matrix-spec/issues/189?

[_flux]

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]

And this is how good old services, protocols and standards get enshittified. Welcome to HTTP(S) v121.99.5146.

[_flux]

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]

> 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]

You can use 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]

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]

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.