TLS was hard, the implementations kinda sucked, and it turned out that it was important.
So we went through a dark age where "Just open a socket and have at it" couldn't fly over WAN, which means there wasn't much point doing it at all.
QUIC will fix this. You can treat it like a bunch of TCP streams and UDP datagrams that are Just Encrypted.
I'm thinking about doing a toy IRC knock-off with QUIC. Having TLS standardized in the transport layer means less work for the app, and having multiple streams and datagrams means that odd stuff like file transfers or even voice chat could be tacked on without opening new ports or new TCP streams. Matrix is cool and all, but I want something you can just throw down for a few friends and some bots with a shared password. Matrix homeservers are too much work for one-off.
My old New Year's resolution was always "I'm finally gonna get into web dev". But I don't like web browsers. My new resolution will be "I'm gonna do web stuff, without web browsers."
I'm building a webrtc video based dungeons and dragons app so my sister can DM for my kids and I instead of using Skype/hangouts/discord etc.. which all suck because she's in . So all that to just say I did it in Electron and it was a cinch and I'm doing mobile versions with Ionic. Both are web dev without exactly using browsers, but still using browser engines. Could be fun.
I see at least 2 here which have commits from 2021.
To be blunt though, I don't like C. It does low-level better than many languages, but C's idea of high-level is too low.
If I had to use QUIC from C, I would pick a Rust or C++ library, write a wrapper that makes it basically into a single-threaded epoll knock-off, and then call that. If I had to do it in pure C, I'd give up.
For my pet projects, I want to use the tools that make me most comfortable, where I can slide between low and high exactly when I want. Web browsers struggle to go low, and C struggles to go high.
I hate C as a language, but I think it makes for a great API. Any language under the sun can bind to C. To bind to Rust or C++, you'd need to basically be a Rust/C++ compiler. From that perspective, I don't have a problem with having a Rust library with a C interface, except it might be harder to maintain for distros. gcc/g++ are everywhere at least.
msquic would be a good start, which is the protocol implementation from Microsoft. I used it for a project of mine which used Quic for something not HTTP/3 related.
I tried to bring some nuance to this. 10 years ago I would have said something more like "Fuck web browsers". I've toned back on the hate, but I still think they have serious shortcomings. (Not that native doesn't - Notice I said nothing about permissions and untrusted code)
tl;dr: I think web browsers have a Pareto problem. Building inside a web browser is pretty all-or-nothing. Their interfaces make the most common 90% of cases easy but the other 10% of interesting niche stuff totally impossible, or too slow to be useful. Just like how old PC games would play music by triggering the CD drive's "Just play this track" feature, browsers are fine for doing super-high-level stuff exactly the way most people want to do it. But if you want to do anything with that audio other than stream it unmodified straight to the speakers, suddenly the APIs let you down. And the whole time, you're taking on some of the biggest dependencies in history. There are two companies that make full-sized web browsers. One is a non-profit constantly struggling for funding while making awful PR gaffs and being hypocrites about privacy. The other is an openly evil advertising company.
Full:
I've done really basic stuff, like I learned how HTTP works, I wrote a few web apps with Rust, I made a game with TypeScript and WebGL. But it just never clicked for me.
My comment is missing a little context. There's basically two different niches:
1. If I want more than 2 or 3 people to use it, it has to run in a web browser. I don't mind doing WebGL and putting it on a static site. I can always do a native port if I feel like it. All the games I've made can be modelled as "Read keyboard input and run OpenGL commands", and browsers are enough for that.
2. If I want to really have fun with something, just for myself, web browsers are too big of a dependency and the restrictions are too tight. Sure, they'll get QUIC as WebTransport soon (IIRC), but I'm always gonna be limited by the dependencies.
I don't like Electron out of principle. It's just so big. Native development can be awful - Big C projects are not fun to build. But Rust is striving for "Just clone and `cargo build`". What's the `cargo build` for web stuff? I have to set up TypeScript or something else to shield me from JavaScript... If I were using Electron I'd have to learn all that...
I actually like local web UIs. I think because that offers flexibility. If I want to send a video stream from a browser, sure I "just" have to use WebRTC. But how do the WebRTC servers work? I haven't found satisfying documentation. What if I want to start with a webcam stream and then compose graphics into it before encoding? I know browsers have Skia, but is that exposed to me? Or is it like so many bad "Play an audio file" APIs where it breaks down as soon as I want to play a _remote_ audio file or _stream_ an audio file or _transcode_ an audio file.
So (sorry for the meandering) back to my toy IRC idea.
I can do that with HTTP and long-polling and it would kinda work. But it would just be a crappy Matrix clone. What I really want is to show off "Look, I think QUIC is going to bring back custom protocols, QUIC has not to come to abolish the word of TCP but to fulfill it, and here's how it looks."
And I could do that with Electron, but like the "Let me do everything for you and make the 10% of niche cases impossible" API that can only play audio or send a webcam stream without any compositing, Electron presumes I'm going to have a GUI, and I'm also going to run it on the same computer.
Whereas if I make the first prototype UI with curses or a local web UI, I can forward it over SSH easily or run it when a GUI isn't available.
It sounds a lot like Gemini, but I think Gemini is a little misguided. It sounds like most of its proponents think that you can control a protocol by just having very noble goals. And it sounds like they are opposed to HTTP and QUIC not because the protocols are bad or even hard to implement (In the case of HTTP. QUIC actually is hard to implement), but just because bad entities use them. I think it's dangerous to believe that powerful tools are only for bad purposes. It will leave good people de-powered.
I like the way you're thinking here, I think the limitations you mentioned with gemini may stand... for me it's kind of like the limitations generally speaking with markdown. Doesn't leave much room for doing stuff like parsing the raw data when they aren't in a hierarchical structure with xpaths you can target and stuff like that, it just throws out so much baby with the bathwater that I'm ready to scream infanticide.
Any thoughts on fast experimental protocols like warp data transfer [1] or fast and secure protocol [2] ? I know they're not exactly the most open things or wellsupported in terms of what you're looking for but I've been really wondering when we're going to start seeing pressure to relieve network congestion using stuff like this. I get that part of the idea of QUIC is generally to shift the optimization of network traffic from kernel-space (for example fq-codel or CAKE) into user space, but does it offer wider improvements on bandwidth usage outside of that?
So we went through a dark age where "Just open a socket and have at it" couldn't fly over WAN, which means there wasn't much point doing it at all.
QUIC will fix this. You can treat it like a bunch of TCP streams and UDP datagrams that are Just Encrypted.
I'm thinking about doing a toy IRC knock-off with QUIC. Having TLS standardized in the transport layer means less work for the app, and having multiple streams and datagrams means that odd stuff like file transfers or even voice chat could be tacked on without opening new ports or new TCP streams. Matrix is cool and all, but I want something you can just throw down for a few friends and some bots with a shared password. Matrix homeservers are too much work for one-off.
My old New Year's resolution was always "I'm finally gonna get into web dev". But I don't like web browsers. My new resolution will be "I'm gonna do web stuff, without web browsers."