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.
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.
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)
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.
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.
> 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.
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.
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?
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.
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.
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.
Only very small piston airplanes, and the need fuel is being phased out. Areas immediately surrounding heavily used ga airports are occasionally seeing elevated levels but it's not a particularly potent source for the public. The issue is mostly employees at the airport being exposed while fueling and performing maintenance.
They want a perfect changeover where new fuel can run in old engines. Problem is general aviation is stick in the 1950s, and dont want to have to replave their valve seats with hardened ones.
Because the idea the web has a single root in Berners-Lee and that he is definitional for what the web "is" is a bit of a false meme. The roots of these concerns about controls, corporates proceed the web, and were always latent in the web, once it went beyond CERN. He gave birth to a body of code and a protocol and it very rapidly moved beyond his immediate control. The fact that we almost never got access to a read-write framework and it became read-only for most people except behind CGI gated commentaries, the absence of the engagement he wanted, was there in the 0.9 web, not something which emerged in the 1.0 web (ie, almost nobody ever experienced active annotation aspects)
Otherwise importance is personal. They're important to me as a historical bread-crumb trail. They inform.
Most gopher and wais information emerged into web rapidly. The controls behind the gopher and wais information did not emerge into some new nirvana, web was an access method, overwhelmingly read-mostly.
Look in strict literal terms of course it roots in TBL. You can't deny history. The question is what context that lies in. And the context is that to do HTML and HTTP TBL and his related involved people looked at SGML and other things like the Diamond system from BBN (not for a minute do I think that was the progenitor) or Hypercards. They didn't do web in a vacuum.
