In this episode, we are honored to have Daniel Stenberg, the founder and lead developer of cURL, as our guest. cURL is a ubiquitous data transfer utility that grew into a robust library used in billions of applications worldwide. Daniel is a Swedish developer who has been involved in open source for decades. He is also the recipient of the Polhem Prize 2017 for his work on cURL. Join us as we talk to Daniel about his journey with cURL, his passion for open source, and everything in between.
In this episode, we are honored to have Daniel Stenberg, the founder and lead developer of cURL, as our guest. cURL is a ubiquitous data transfer utility that grew into a robust library used in billions of applications worldwide. Daniel is a Swedish developer who has been involved in open source for decades. He is also the recipient of the Polhem Prize 2017 for his work on cURL. Join us as we talk to Daniel about his journey with cURL, his passion for open source, and everything in between.
[00:00:00] Beyang: All right. Welcome to another installment of the Source Craft podcast. Today I'm here with Daniel Stenberg crater and maintainer of Curl, the most popular CLI for working with network protocols and requests. Daniel is also an active member of the I E TF where he has contributed to the working groups for Speedy, which became HTP two and now Quick, which I, I believe is expected to become HTTP three.
Hey, Daniel, how's it going?
[00:00:29] Daniel: Hello. It's a good day here today, .
[00:00:32] Beyang: Awesome. You just got done with a, a release, right?
[00:00:35] Daniel: Exactly. My 209th release is the beginning, actually, so yes.
[00:00:40] Beyang: Wow, that's, that's quite a journey. Um, I guess going back all the way to the beginnings of that journey, you know, when you think about what got you into programming originally, what was it that was your first introduction to the world of.
[00:00:55] Daniel: I had a friend who owned a Commodor 64 that sort of [00:01:00] teased me into what programming would be like or what computers and working with computers could be like. So, uh, it that is sort of, was such a attraction to me that I managed to get myself an a Commodor 64 when I was 14 years old. And
[00:01:18] Beyang: what, what sort of things did you do on the, the Commodor 64 when you got it?
Oh,
[00:01:22] Daniel: well, I, I. Already from the beginning I was sort of fascinated, uh, by just the ability to, you know, command the computer to do what I wanted to do. So that's, that was what I wanted to do, and I started immediately, you know, learn. And, and when you did it under the Commod 64, it was basic from the beginning since it had a basic interpreter from the beginning.
So you just start, you know, 10, print, hello, go to 20, go to 10, stuff like that. So it was really easy to begin with. And, you know, you could change colors on the background, on the border, stuff like that. Basic stuff. I don't know really why, but it sort [00:02:00] of, it draw it, draw me into it. So, yes, uh, I was hooked really, really
[00:02:06] Beyang: quickly.
That's awesome. Um, and, and when you started programming in, in Basic, were you making, uh, like we, we talked to a lot of people on the show that got into like, you know, uh, computers through games. Uh, for you, was it games or was it like some other kinda like intellectual?
[00:02:22] Daniel: Well, I, I, I think games was fun, um, at least to begin with.
So it was partly that it was just, and also just a challenge of, of I wanted to do my own stuff, right? I wanted to do my own games. And then I also rather soon got into the demo scene on Coming War 64 and I watched a lot of demos, people doing crazy things, you know, flying around colors and, and images and, and playing music.
And that was fun. And I sure I wanted to be part of that too. Uh, just, well, you know, get the computer to do
those
[00:02:55] Beyang: fun things. Yeah. So you're, you're a teenager grown up in, in Sweden. [00:03:00] And, uh, talk more about that demo scene. So my understanding is like the demo scene, when you say demo, it was really like people doing cool tricks with their computers.
Like, Hey, look at what I can do. Is, is that right? Exactly.
[00:03:11] Daniel: It was mostly a show off thing. So you put in a lot of graphics, flying things, music sound effects, and you know, and you tried to make it a bit. And, and you usually just try to impress the other demo groups. So you would try to do something fun that made some cool graphic tricks, or, you know, And, and the Commodore 64 was actually a computer full of, uh, well, I would, maybe I could say like, so the com, the graphics chip in it was rather undocumented and you could trick it to do a lot of things that wasn't really documented how to do it.
So you could sort of learn and try to do things and you could find out, wow, you could actually accomplish this if you did this. That wasn't documented anywhere. So it was sort of a, an adventure into the wild and try to do funny things and put that into those demos. And look at [00:04:00] this, I could do this fun trick when I blah, blah, blah.
[00:04:03] Beyang: Do, do you remember like, like what specifically that you could trick the chip into doing that, uh, was
[00:04:08] Daniel: Oh, yeah. I, I remember one of those things that I, I think, well, I discovered at least, I don't know if I was the first one, but that was how, you know, the. The graphic chips actually had sprites, which was, you know, eight independent graphic units.
You could put anywhere on the screen and move them around. You can change the positions. You had eight of those. And very early on before my time, actually, someone discovered that if you move them when the rester image goes across the screen, you could move them. So you could make them appear as more than eight.
So you could have 16, 24, 32 of them if you just move them at the right time and move them back again. So you could make them appear as a lot of them. And that was fun, of course, because suddenly there weren't only eight of them. You could have, well, maybe 40 or something. Oh, wow. 48. That was sort of the max if you just, you know, move them correctly and switched them around at the correct time.
But I, I [00:05:00] remember at one point, I, I remember that you could stretch those sprites if you just inserted the, uh, you could actually resize the Sprite at a certain point. And if you did that at the right point, you could actually stretch those sprites to actually stretch across the entire screen. So, and you've then just did stretch on stretch, stretch on stretch at right positions.
On the rest lines. You can actually get some sort of, you know, waving effects and stuff like that. , It was completely pointless, but it was fun and you could do something with it and, and was graphical
[00:05:30] Beyang: and That's awesome. How, how big was this community in, um, uh, yeah, you grew up in Sweden, right? Stockholm,
[00:05:38] Daniel: yes.
I was in then in Sweden and I had my, my younger brother was also into this and I, a few local friends. So we started this Devon Group here in Nia, south of Stockholm, Sweden. And then after a while we got to know others around Sweden. So we joined and we created the demo group. We called ourselves Horizon.
We went to all these different demo meetings in Sweden where we met up, you know, [00:06:00] hundreds of others, you know, carrying along small TVs and Commodore 60 fours, gathering in a school over a weekend or something, and did a lot of that so, well, I don't know how big it was. We were at least. Commonly more than, you know, several hundreds people in, in a school in Sweden, , and sometimes, you know, bringing in people from all over the Nordic countries, you know, Norway, Finland, Denmark, and we, So it was a, it was a great time.
Yes.
[00:06:28] Beyang: That sounds like it's such a fun scene. So, you know, from there, did you go straight away into Yeah. Like, programming professionally or, or you know, how, how did that initial hobby evolve?
[00:06:38] Daniel: I think at that time, a lot of people when, well, like a lot of people, I of course also got sort of a bit bored by doing those demo things after a while, because some, at some point you feel that you reached the end of what you can do.
Maybe that wasn't true, but it was the feeling anyway. So I wanted to change it up and do something different. And at that time, [00:07:00] Commodor was made. Well, the Commod Forum was made by Commodor, and they then shipped the ame, which was their big brother computer. It was shipped in late eighties, in 90, early nineties.
I don't remember exactly when it, late eighties, I guess. Uh, so I sort of switched to that too because it was sort of the common transition from, for a lot of people who worked a lot with KU 64. But on the, I mean, it wasn't as much fun as to do demos and stuff because it was a completely different universe.
It was a little bit like, you know, removing all the fences and there were no limits at all anymore because, so you could do so much more and so much different things. So it felt a completely different universe doing demos wasn't as much fun trying to do games. No, it wasn't that fun. So I actually, I don't remember exactly how I got into it, but I, I fell into C programming and I decided I, I want to do my own.
Text editor instead on the ami. So I started learning C and doing a text [00:08:00] editor.
[00:08:00] Beyang: Okay. So Amiga was no longer basic. You're, you're programming C that is like a wildly different, uh, kind of environment.
[00:08:08] Daniel: Yes. So exactly. The AMI doesn't have any interpreter from the beginning. So you actually, you know, more like traditional computer nowadays, you had to actually load something to do it.
Um, and yeah, I got in to see programming at work. Since I at that, by that time I. Roughly at the same time I started, uh, working for ibm. So I got into, I met some friends who were into c programming and so I started to feel around with C in general. Well, you know,
[00:08:33] Beyang: one thing that's interesting about your background is you, you actually didn't go to university, right?
You, you kind
[00:08:37] Daniel: of, Right, Exactly. So, so I actually, I did in Sweden, we had a mandatory military service back then, so I did that and then I was ready and prepared to, to go into university to do some study. Um, I actually applied for some courses and then at the same time I got a job offer from a friend to start working at IBM with their I A I machines.
And I [00:09:00] figured, sure, I can postpone the university for a while. I can go work at IBM and see, see what? And then I never got back to the university thing.
[00:09:09] Beyang: Cool. What did you do at
[00:09:10] Daniel: ibm? I worked with installing and preparing those RS six, 6,000 machines for customers. So it was pretty basic setting up things, installing them, you know, installing a lot of tapes to install different softwares, customizing them before they, so they got here into Sweden, we prepared them and then, and they were shipped out to the customers here in the Stockholm area, I guess.
Interesting.
[00:09:35] Beyang: So these are, this is the RX 6,000? Uh, yes. What type of machine was this? Like, what did it look like at
[00:09:43] Daniel: They were huge. So they were, you know, like small closets, usually powerful machines with powerful hardware. And they ran, I then, so they were really IBM's Unix machines.
[00:09:58] Beyang: IX was a flavor of Unix?[00:10:00]
Yes. Okay, got
[00:10:01] Daniel: it. Yeah, it's still, yes, I guess. I, I think it still exists.
[00:10:07] Beyang: There's still IBM mainframes out there, probably somewhere in, in some old company. Yes.
[00:10:12] Daniel: Yeah, yeah. I'm sure it, it still exists in a lot of places. Nothing ever really dies, you know, .
[00:10:18] Beyang: Okay, cool. So you, you're at ibm, you're setting up these, uh, uh, big RS 6,000 machines, and in your spare time you're kind of toying around with the Amiga.
Uh, what was that like? You know, like by day you're working with these like giant honking like business machines. By night you had this like, you know, very personal, uh, computing environment. Yeah,
[00:10:38] Daniel: but they really went hand in hand because at, at my, at my work, I, I, I realized the world of open source command lines, Unix emax C Code man pages, and that it was sort of a little bit how I got into how to do c programming and, and so, and I learned eax and tried it out at work and wanted, That's got me also [00:11:00] inspired quite a lot to do.
For my own text editor at am got a lot, a lot of inspiration from iax on ais. So it was a little bit back and forth. And then I started to participate at work. Some of the guys actually, someone like of a own personal project that started to write a little program that could help automatically install these machines that, that we were doing during the day because, you know, it was a manual labor.
You actually had to insert a, a terminal, do a lot of typing. Yeah. Cursor up, cursor up, select blah, blah, blah. And we actually worked on doing that by automation. So we actually wrote tools to do that automated and I was sort of helping out there. And I got into C program a little bit thanks
[00:11:43] Beyang: to that. It's kind of like a, a very early version of of DevOps.
Uh, in in a way.
[00:11:48] Daniel: Yeah. In a way, yes. Yeah. It ended then when they actually canceled and shut down the entire department, so Oh wow. It didn't really survive.
[00:11:59] Beyang: That's [00:12:00] a shame. Um, te tell me more about the, the text editor that you wrote, uh, for, for the Amiga. What was the motivation there and and what sort of features did it have?
[00:12:08] Daniel: Well, actually it, it, I mean the motivation actually was because when I started to program on the ami, I figured that the text editors we had, they were a bit limited. And at the same time I got into using EMAX on the AIC at IBM at work. So I figured there's a potential here. There's an ability to do a lot of fun things if you could just, you know, do this.
So I got a lot of inspiration from EMAX and brought it back to the ABI because the Amiga was really an, it wasn't really able to run EMAX for real back then because, you know, it was a 68 K CPU at eight megahertz in the original one. It was really a slow thing. So you. Squeeze out the performance a little bit more.
So that was, so I, I actually made a programming bill. I wrote my own programming language called fpl, actually FRA [00:13:00] Programming Language. The editor was FRAX Ed.
[00:13:02] Beyang: What was that programming language like? Was it ?
[00:13:05] Daniel: It was a very stupid, Its very c like it was more or less like interpreted c I don't know why, because it wasn't really making in a sense.
But, you know, it was close to my mind, I guess.
[00:13:16] Beyang: So that's awesome. I, you know, I know people listening to this, we have a lot of Vim users, uh, in, in our community, so I'm sure the question they'll ask is like, you know, why not just use, uh, vi in, in that situation, . Yeah,
[00:13:30] Daniel: well, well the answer is pretty, uh, obvious actually because back in those, I mean, I started at IBM 1991.
Uh, there was no VIN back then, and VI was a really, really basic editor. Emax was way more advanced and, and, you know, powerful back then. So, back then there was for me, and I don't think for anyone at that point in time, there wasn't really any question. So if, you know, if you wanted to automatic indent your source code, for example, VI couldn't do that.
EMAX could. So it was, [00:14:00] you know, stuff like
[00:14:01] Beyang: that. Got it, got it. Okay, cool. So, so this editor then you're building was really just, you're taking the, the best parts of the EMAX and making it runable in the more resource constrained environment of Amiga. Is that kind of the general idea?
[00:14:15] Daniel: Yes. Sort of like that for a while until we, when that was fun and, and we made a share where people actually had to pay to get the full experience.
So a few hundred people actually paid for it. It was fun. Um, so yeah, it, it went on for a while until I, I, I did this with a friend and we had a lot of fun, and then I switched work. I got to, got a real programming gig. So I started working as a actual software developer in 1993. And then I, and then I got it more into learning about what the internet is that it exists and what to do about on it.
And then my interest slowly sort of grew into more [00:15:00] uni to do more Unix programming and more network programming. So I slowly went away from a
[00:15:07] Beyang: talk a bit about the early days of the web, you know, what was that like? You know, you got into professional software development in 1993 that was probably, you know, right at the right moment where the internet was kind of taking off and you had all these new protocols emerging.
[00:15:21] Daniel: Yeah. And, and, and, um, I actually started trying it out a little bit. The first few steps at ibm, people showed me, you know, how to do search on Archie and do Gopher and everything. So yeah, it was really basic and um, hard to actually understand or get the full power so we sure we could start sending emails and everything.
But, and, and in 19 93, 94, something also discovered IRC to start chatting. And I think IRC opened my eyes a little bit. You know, a lot of people out there, a lot of collaboration and that everyone actually [00:16:00] is connected. And at about that time also, the web started to appear for real. So people started to actually ship browsers and everything.
So then, yeah, then things started to look really cool.
[00:16:13] Beyang: Yeah. That's awesome. T talk a little bit more about the IRC community. Um, you know, that's something that. , you know, it doesn't really exist anymore in, in the same way that, uh, it did these days. What was it like being on IRC in, in the nineties?
[00:16:26] Daniel: Yeah, but, but the, Sure.
I, I, So I discovered IRC 93, 94 something, and it's a chat. It's a way to, to chat online. Right. And you join room or channels really? They're not rooms, they're actually channels in the IRC language. But anyway, so you could join and there were, if you, back then I joined, um, F Net, which was the major, um, network back then.
Uh, so you could join channels with several hundred peoples in them. It was big back then. So, and, and a lot of people from everywhere chatting about [00:17:00] whatever. And I've immediately, of course, found channels with people interested in topics that I was interested in. Actually joined several Ammi channels earlier, uh, in, in the early days because, you know, I came from AMMI there.
So I found people talking about Ammi. That was fun. I started to. talk there. And I, and I realized that in, in icy and in IRC channels, especially back then, not so much these days, but you needed bots and in particular bots to protect the channel because there were, there was a lot of attacks and just abuse bams.
Yeah. And just, you know, download attacks. You could just, you know, take over channels by, by being aggressively you could do certain things to actually take over channels, kick everyone else out, and just be rude and, you know, annoying, like, you know, annoying kids. So you could actually do that . So, and in order to prevent that from happening, you could actually run, you could actually run and use defense bots that could sort of help you defend your chance [00:18:00] and stuff like that.
And, and the bots could also be more silly. You know, you could have a bot to, you know, help you explain things or answer frequently, ask questions or, you know, just like a bot, a robotic user who could. Do whatever. So I started working, uh, a friend of mine there in one of those IRC channels started working on a, on a bot in for irc.
And so I started sort of helping out on that IRC bot that was more or less my first adventures into T C P I P programming in c on Unix. I thought it was great fun.
[00:18:33] Beyang: Yeah. That's awesome. Yeah. You know, in some ways it's, it's almost like the world we live in now. Uh, there's a lot of analogs back to, to those days, you know, like these days, uh, discord and slack, you know, a lot of people run, run channels for that.
But I guess the, the difference now is that like there's all these kind of like companies, uh, behind these, these, uh, applications where, whereas in those days it really felt like it was just like a bunch of open protocols and people just kind of
[00:18:57] Daniel: like, it was certainly more of that [00:19:00] kind. Yeah. So more open protocols, people running servers for, for.
Good. Other sort of for the fun of it, because they could do it probably they worked at some universities. Universities or companies or, uh, yeah, so they ran stuff and it was more of, uh, and more open protocols. I could actually read the IC specification. How do you actually write about, just follow the specification and you can actually make about
[00:19:22] Beyang: it, you know, it.
Do you have any thoughts like comparing that world versus, you know, our, our current world? You know, are there things that you miss about, you know, that those early days of the internet that you wish, uh, it still had, or do you think, you know, things have mostly evolved for the. It,
[00:19:36] Daniel: it has mostly vaulted a better in the, in the way that of course, it, it, I mean, it worked back then because we were all enthusiasts and we were, you know, we could manage when everything just broke down for a while and we could just, you know, wait and fix it and stuff like that.
So, and as I said, the big channels back then, they had several hundreds of, of people joined. Right. But it was still small. It was still a small community. And [00:20:00] I think that's why it also worked, because it, it didn't ever grow up until, you know, millions or hundreds of millions of users because it really couldn't, it, it didn't scale like that.
So you need something and how do you scale something like that? I, I think you need money and some sort of investment to make sure that happens. So I think it's a necessary way to move forward.
[00:20:23] Beyang: Cool. Makes sense. So you got into network programming, uh, through irc. Um, it was kind of the, the early days of the web.
What, at what point did you start building this command line utility that would, uh, become curl?
[00:20:40] Daniel: Yeah, so, so I was working on, on that IRC bot and you could do a lot of, um, things with that IRC bot. You could ask it questions, it could respond. And one of, one of the days, I, I, and since we were in international channels, uh, in my Omega channels there, we talked about, you know, buying hardware, buying services, whatever.
And one out of [00:21:00] these days it struck me. Of course the bot should be able to translate currencies for me. , how much is a hundred US dollars in Swedish crowns today or in German marks or a lot of those other European currencies that are gone now. But so how do you do that? Uh, I just need to download some currency rates every now and then and, you know, and, and make the bot do that.
Ah, I just need to download current rates. Where are those ? So found, so found an HDP site, just hosting a lot of, you know, 40, 30 currencies. I just need to download them. So I just need a little tool to download. So I just Google, Before Google existed, I guess I used alavi. I don't remember actually . So, and how, you know, a little tool to download hp.
So I found a tool called HP ga. It was actually written by a Brazilian developer, and he released his first version, actually checked this afterwards, his first version in November, 1996. And I think I used this first version. [00:22:00] So I got that and it worked pretty almost the way I wanted to. So I, you know, I fixed it, sent an email back to the guy to, here's a patch, I think they should do this as well.
And then I found some other, and then I adjusted some other things and sent a patch to him again. And after a few patches he said, Oh, well maybe you can just become the maintainer of this. I don't wanna do, I don't want to work with this anymore. So I became the maintainer of HTP get then in late 1996,
[00:22:29] Beyang: Yeah.
You know, it's so interesting. Um, I, I feel like nowadays we think of Curl as, as almost like a standard, uh, Uix tool, and it is kind of startling to hear that it wasn't invented in like the 1970s, like, you know, a bunch of the other, uh, Unix tools are. But it makes total sense, right? Like HTP didn't come along until uh, uh, later.
Um, but like, yeah, like back in the day, uh, you basically just had to like roll your own Hgp like requester. There, there was no kind like standard tool in, in Exactly.
[00:22:59] Daniel: There was no [00:23:00] standard tool. And, uh, actually, uh, it's kind of fun since everyone compares Curd with w get, because it's a commanding tool for the similar thing.
And Wbl was actually also born in the early 1996, um, under a different name as well. It, I, I, I don't remember. I think it was. Yeah, well, it doesn't matter. But anyway, at, at that time at at least I didn't find it, or maybe I didn't think it was good enough for me. I don't remember exactly why , but, but, but I went this path anyway, so, um, and you know, it was a different time and here it wasn't as easy to find software.
Uh, also at that point in time. And also I was very much focused on getting this little tiny tool for my currency translation service. I didn't want any cause of thing complicated. You know, HCP get, there was 300 lines of. Perfect for my
[00:23:51] Beyang: and, and written in C at that
[00:23:53] Daniel: point. Yes, exactly. Yeah, it probably had no error checks or anything.
It was probably horrible , [00:24:00] but you know, I, it was just for my little fun, so why not?
[00:24:03] Beyang: Yeah. How, how did you find it? Uh, you know, this is before you know, GitHub. It might have even before like, you know, Source Forge
[00:24:11] Daniel: was, Oh yeah, it was way before source for too, so, yeah, I think I just searched for it using AltaVista.
I'm pretty sure, because it was years before we got Google too. So, you know, HTP tool get download. See, I don't remember exactly how I did it. I have no traces left to remind me either. So. And
[00:24:31] Beyang: so when you, when you submitted patches, then how did you. Patches, Did you like email DIFs or, you
[00:24:36] Daniel: know Yes, exactly.
Just did you know the diff diff and emailed the patches to the guy who actually had his email address in the source code . And it was only one file of source code too. So just one C file.
[00:24:49] Beyang: And were you using version control at that point, or was it No, not,
[00:24:54] Daniel: not initially, no.
[00:24:55] Beyang: Okay. So you just like e emailed the whole file over and like [00:25:00] manually, like specify which lines were added and No, I
[00:25:02] Daniel: think it actually, you know, I had his version of the, of the quote code and my version and just ran a diff and here's the diff from your version, here's what I think you should apply.
So, so, because the diff and they apply, command stays existed already. . So they were useful. Okay. So,
[00:25:18] Beyang: so you started submitting patches at some point. Uh, the, the Brazilian program had transferred, maintain ship over to you. Uh, and, and then what, like how, was there a point at which it became more of like a standard tool that other people started, uh, adopting and using?
Yeah,
[00:25:33] Daniel: it was actually pretty soon. So I, I put it up online on, on my webpage. And again, how, how do people find that? I, uh, I remember, I don't exactly remember at what point in time, but you know, there, there existed sites where you can, uh, you know, more like directory sites when you could announce, I have a program that does this, put it under the category, FP client, HTP client, blah, blah, like Fresh [00:26:00] Meat was an early one and there existed those kinds of catalogs so people could find it.
And, and pretty soon people actually started to submit patches in the same style. I started using version control. I started using actually rcs a little while before I switch to cv. Um, and then after a while, I, uh, found a current site using Gopher. So I added Gopher support.
[00:26:24] Beyang: Gopher is another, uh, web protocol.
Yeah,
[00:26:27] Daniel: it's similar to hdp. More, more. It's actually way simpler. Um, so it, so it's supported two protocols, but then it couldn't be HDP get anymore. So I switched name to URL get, because now it's for url and actually changed so that it actually worked on URLs, HDP and Gopher started getting more patches. I got proxy support and blah, blah, blah.
And then one day I added FTP support and after a while, early 90, 98 actually, I added support for FTP upload. And then it wasn't [00:27:00] yet anymore. It was doing. Put as well. So it couldn't be URL get, so it was, I changed name again, . So it became CURL in 1998 in March. And by, by that time I watched a sort of, you know, the currency translation thing.
I had forgotten about that , I was working on my command line too. I didn't care about IC bots anymore. So it was just fun to do this, uh, command line tool. So I sort of faded away from the IOC things and, and worked more and more on just current.
[00:27:31] Beyang: It's funny, I feel like there's a lot of infrastructure tooling that maybe gets created that way.
You know, there's originally some end user, uh, problem that motivates the creation of that piece of infrastructure. But then, you know, things change and the end user problem goes away or becomes less important. But where you're left is like a, a piece of infrastructure that is pretty generic and, and multipurpose and can be used for many other.
[00:27:54] Daniel: Uh, absolutely. And I think, I mean, scratching your own itch, that's a very powerful motivation to actually get [00:28:00] stuff done. So yeah, I think a lot of things start that way. Yeah.
[00:28:03] Beyang: Cool. Okay, so, uh, Curl is evolving. What, what was it like, um, like building something in, in open source back in those days, uh, when, you know, people were kinda like emailing you patches and when there wasn't, you know, GitHub where when there wasn't, you know, um, as, as strong, like a history I guess of, of open source development.
What, what was that like?
[00:28:27] Daniel: I, I guess it was similar today, but just slower and, and more spotty in, in, in contributions and think people actually discovering the project and, and doing anything. But, you know, in, in 19 19, 9, well very end of 1990, Source watch was created and suddenly appeared. And Source watch was actually, it was pretty good beginning of, you know, a central place where people could put things and get discovered and also make it slightly easier for people to contribute code back because they could find it and it could actually see the [00:29:00] code and things like that.
So pretty soon it was available like that for people find it, and then it, you know, slowly just gradually got people's attention. People sent me patches, they sent me feature request. I added code.
[00:29:15] Beyang: At what point did you become aware of a w get
[00:29:20] Daniel: I don't, I don't have that recording where, Uh, Okay, got it. I, I, I guess it was, it wasn't that far along.
I guess it was just a year or two into the game so that when someone pointed it out. But by that point in time, I think Kurt has already developed into a direction where it wasn't. I mean, a lot of people of course, compare Curl with W yet, but in my mind they're fairly different. They, they have an overlap where, where they do the same things, but you know, a lot of things, they actually do different things.
And so in my mind, I had, uh, had it set up what Curl was supposed to do, and then I realized with w existed, but you [00:30:00] know, they're not the same. So I never thought of, you know, giving up curl and just go to w getaway or so.
[00:30:07] Beyang: No, that makes sense for folks listening who, who may be unfamiliar with like the, the distinction, like how would you describe the differences in, in purpose and, and philosophy of the, the two tools?
Uh,
[00:30:18] Daniel: yeah, exactly. So, so of course this is my highly biased way of looking at it. So, so someone else will look at it differently, but from, from, from my point of view, w get is primarily done for download. A file or actually, or a whole, you know, tree of data W get, can actually parse html and figure out a website and download a lot of documents from the website.
Curl doesn't understand the content at all, so it doesn't, it can't download anything recursively or understand web content. Um, so Curl is much more of, uh, a way to do htp, more raw fiddle with it. You can download files with both of them, but Curl is more of a, doing more h p [00:31:00] fiddling or more transfers up and down and over time, of course, Curl does a lot more protocols and a lot more different things when it comes to internet transfers in a variety of ways.
Why, why W get has remained more sort of, The same thing as this actually was from a long time ago. It hasn't had this feature crepe that I we have in
[00:31:25] Beyang: Curl . Yeah, Curl has gotten quite advanced. Like it's still, it's still active development and it, it keeps evolving along with the, the web standards of our time, I
[00:31:35] Daniel: think.
Yeah. Quite a lot actually. Yes.
[00:31:38] Beyang: Cool. I mean, you know, being, um, you know, the, the, the creator and and main maintainer of this like tool that has become such a, a standard, uh, way of, of issuing requests, you must have had kind of like a front seat to the evolution of, of web standards, uh, you know, from the nineties through the two thousands and, and beyond.
What [00:32:00] was, what, what was it like to to partake in, in that and like how did you get involved in, in the conversation around how these standards.
[00:32:07] Daniel: When I did my first sort of steps into htp, I, I only, and, you know, I got that initial tool from someone and I could just read the source code. Oh, oh wow. This is how you talk htp.
And I continued from that without even realizing, you know, who, who decides this and where is the documentation specifying the format. I just, Wow, cool. Listen, source code that does htp I'll just extend a source code. But of course, after a while I realized, well, you know, there are, there's actually a specifications detailing this.
So, you know, I could add h p 1.1 support by reading the specifications since it had P 1.0 from the beginning. And, and, uh, Interesting. Yeah, exact uhp one at one was actually the first specification actually came in 1997, which was actually sort of the same timeframe, [00:33:00] but it took me a long time until I actually.
I realized that, that this is something I can have a say in and that I could actually, you know, talk to community that is also interested in, you know, the protocol details. So I could see that home and, you know, and be angry about details in the protocols. Why are we doing this? And I don't understand this.
And it took me years. I don't remember exactly how many, but I don't think I, I did, I think I found out about I utf and the HTP working group in the more, the mid 2000. So maybe 2006 something I started, I joined the mailing list and it took me a long time until actually set anything on that mailing list, but, you know, a mailing list dedicated to talking about htp, the protocol and implementations and, and that, that was awesome for me because it was a, like a gold mine in, in just, you know, similar minds.
Um, so yeah. And, and then in there I learned. You know, I could also contribute and, and speak my mind about what things that are [00:34:00] actually working, not working and, and my experience is from Curl and so on. Yeah.
[00:34:05] Beyang: And what was that like? I imagine you had maybe like a, a somewhat distinct perspective because my, and I, I know very little about the standards committees, but my, my impression of them is, um, you know, very active voices.
There are, you know, things like, you know, web browsers, right? Like the, uh, there's all, all these web browsers now that, you know, they have end users, they have like, features that they want to add, but, you know, Curl is a command line tool. So did you find that you had like a different perspective, uh, in, in that conversation?
[00:34:33] Daniel: Yes. And I think exactly I still have that. I still, I think that's still a very important difference, perspective and a different, different sort of mindset on how to do protocols and how to do transfers and all of those things. So I think I repeatedly think that it's a very important thing for me to remind everyone, uh, that wait a minute, we don't all, you know, load things, uh, like this.
We don't all waste megabytes of, of stuff just to do things [00:35:00] milliseconds faster. , some of us do it this way. So I think that is very important. Uh, and I also immediately, of course, found this struggle that a lot of those working on those standards, uh, they're working on that. More or less full-time while when you're, you know, you're a spare time hacker, just wanna follow along and, and voice your opinion.
Every now and then, it can be really hard because suddenly, you know, the discussion takes off really, really fast in one direction. And, and, and if you only spend, you know, an hour or two every day, it can be really hard to keep up with that and to actually have a say because it's, and it's also very complicated, right?
You, you need to actually know what you're talking about because if you don't, they won't listen to you. So, because you can't just be rambling on things, you actually have to keep up with the discussion, the facts, the protocols, where are we going, where should we go? And stuff like that. So, but very when you can, I mean, when you can actually keep up and you can actually contribute, I think it's very [00:36:00] valuable because I think in a lot of thing, you know, a lot of ways I, I think I can contribute and I think I can.
And the other way around I can actually understand where people think we should go and. And all right, they, they read that section in the spec like this. Of course, I thought about it, complete difference, . That's why it doesn't work for me. And, you know, and then I can adjust and, and everything works better.
And when we all can do it like that, I think the entire internet can actually work better, because we all understand each other better.
[00:36:30] Beyang: So this whole time you're, you're, you're developing curl uh, in, in your spare time, you're, at the same time you're holding down just like a full-time job as a programmer, Is that right?
[00:36:40] Daniel: Yes. So I, I changed jobs a couple of times, but I kept working, um, usually as a consultant doing embedded Linux systems. Uh, so yeah, so, and I, um, so I did my curl spare time, usually a few hours every evening, pretty much. So kept up. The mailing list, the [00:37:00] issues to working on things.
[00:37:01] Beyang: Got it. That's, that's incredible.
Um, was there any kind of like, uh, interplay between your, your kinda like full-time day job and, and curl, or were those mostly kinda like distinct?
[00:37:11] Daniel: They were shockingly just separate and I sometimes thought that it would be, be more fun if they could actually be more joined, but I don't know, maybe it was more of my decision of going into embedded systems so that, so I didn't, they didn't overlap much.
I actually, it was mostly my development stuff at work and my development stuff with Curl there was mostly separate. Got it, got it. So, so exactly at work at the end. But the systems, of course there was, there was often network related too, but rarely hdp rarely current stuff. So
until, pretty much until the end of 2013. So that when I was a. Ending, Uh uh, I was actually ending as a particular project and I sort of reached out to my community and asked, So is there anyone who has [00:38:00] any new gig for me coming up next? And then I got an offer to start at Mozilla. Got it. And, and what was that like?
So I joined as an employee at Mozilla in 2014, and then I could suddenly my two worlds could, you know, be joined. They could collide. So now suddenly I could work with htp, networking cookies, DS, TCP on all of that during day and during night. And actually I had some permission to do some curl stuff during work hours as well.
So yeah, it was great and everything was open source too, so that made, that was really my first full-time open source work. That was awesome.
[00:38:39] Beyang: What were your major projects at Mozilla?
[00:38:42] Daniel: Well, I worked in the networking team called the nico, which is the sort of the network stack that's basically HTP caching cookies.
um, stuff like that, dns. Um, so it was a lot of things that I was very familiar with from Curl, [00:39:00] but in a, in a browser context. So it was, um, quite of a steep learning curve that anyway, because it's, uh, messier more threads, more objects, a lot of more code, a lot of more developers, a lot of more bugs, a lot of more complicated situ.
but of course very educational and, and I learned a lot and I met a lot of great people there.
[00:39:24] Beyang: Yeah. That's awesome. Well, when you were at Mozilla, did you have opportunity to use their, uh, code search, uh, engine? Um, I believe now it's called like Search Fox, back in the day. I think it was like Dxr or Mxr
[00:39:35] Daniel: or, Yes.
And, and, and with such a huge code base such as Firefox, you need a good code search to find your way around because it's, yeah, it's, uh, I don't remember exactly, I, I dunno how much code there is now, but there was something like 20 million lines of code when I was there, so it was, you know, so much code and so much of that running concurrently.
So yes, [00:40:00] it's, it's, uh, it's a tricky code base to work with , to put it
[00:40:05] Beyang: mildly. Um, in, in terms of like, uh, your kind of like tool. You know, um, at Mozilla and also like these days, you know, what, what, what does your development environment look like? What, what kind of tools do you, do you reach for? Uh, what's, what's part of your day to day, uh, tool set?
Oh, I'm
[00:40:22] Daniel: a very, I'm a very traditional conservative guy. You know, I'm, as I mentioned, I learned C when I was back in 1991 something, and I still work primarily in sea. So I'm really stuck with the C development and then also in that set of tools, pretty much. So, you know, I build everything with make, I run configure.
I use gdb, I use emax. I said I use terminals. And so that's the environment I'm, I'm in. Um, of course there are a bunch of terminals. A. I mean, browse the windows when I, when I work. But that's, that's pretty much what I do.
[00:40:58] Beyang: Awesome. And in terms of [00:41:00] like editor plugins, are there any that you, you favor? Is it mostly like stock configuration?
[00:41:04] Daniel: Uh, I do most of, most stock. I have edited dot emax of course, but most of my things are actually very, uh, vanilla and, and ordinary and mostly in a way that I, I sort of try to stick to stock so that I can, you know, move around to different computers, different installations without them being too hostile or different.
So I easily
[00:41:28] Beyang: move around. Um, when you look at like the, the kind of tooling that other people are using these days, like, is there a reason that you prefer, uh, the kind of like stock emax, you know, terminal based setup? Um, like what are the things that you like about it that you just like, Oh,
[00:41:43] Daniel: I think it's a lot of just about habit and being accustomed to the way so working that I.
already know. So, you know, my fingers are trained like this much more than me, you know, thinking that this is the superior way or the best way. Because obviously there [00:42:00] are really cool editors and plugins and fancy ways of doing things, and one of these days I might change to that, but, you know, I'm so, so accustomed to this.
This is sort of the way I do it. I'm, I've grown up like this, so I think I'm very, uh, productive like this. I find my ways around the code what I wanna do like this, so I'm sticking to it. So sort of, I'm, I'm not breaking the team that I think is, is winning.
[00:42:26] Beyang: And, and you're still actively coding today,
[00:42:27] Daniel: right?
Yes. Uh, a lot actually. Well, mostly debugging, but, uh, that, I guess that's included in coding.
[00:42:36] Beyang: What, what was the, kinda like the last, uh, rabbit hole that you went down? Uh, you know, in terms of debugging, ,
[00:42:42] Daniel: you know, surprisingly often you can find them on and over and over again. There's a new rabbit hole you can go down into because there are so many and you think stuff that has been around for a long time, they should be fairly solid by now.
But no . So for example, the other day, [00:43:00] well months ago, so now I found this.net RC file format, which is a file format that was created in 1978. So it's pretty old, 44 years or something. So it's a, it's a protocol, it's a file that you can, it was originally made for the FTP tool I think maybe. So you can insert in username, password for this machine, blah, blah, blah.
And just, just a while ago someone pointed out that I have a pass password with a space in it. I need to specify it in my.net or see file and curl doesn't handle it. Uh, really a space in your password. . Who does that? . Well, I guess that was, that was not the question I was supposed to ask. So, so how do you support a space in your password in net say, So I got in a really deep rabbit hole there, realizing that, of course, there's no specification for the file format.
[00:44:00] There are a few different, there are a number of different tools that support the NET RC file, and they all have their own parcels. They're, they're not all the same. So I had to, I got into that and had to decide, well, how should Curl actually read this file? How should we interpret, How should you be able to specify space in your.
[00:44:21] Beyang: When, when you're going down rabbit holes like that, you know, for me it's often challenging cuz I'll often like lose my space. Like, you know, one thing leads to another and then all of a sudden, you know, I'm reading this, this old spec and then I almost like lose track of like the, the initial problem that I was thinking of.
Do you have an effective way of like, managing those investigations or, or journeys? Like you have a system?
[00:44:42] Daniel: I, I think, yeah, I think what's primarily, I mean, I have a rather strong focus on, on the issue that I, that actually triggered me there. So actually a user with a problem, right? And I wanted to fix that problem.
So I think that is what's brings me back to the surface all the time. Right? [00:45:00] Wait a minute, the, the issue is still open. The user still has this problem and that is what I'm trying to solve. So even if I go into this research mode and I find that this happened 1978, that doesn't help me, right? I, because there's this problem we need to fix.
So how do we get that info I found to actually fix that problem. So, So even if, if, and I also have this, you know, the biggest struggle sometimes is that, sure, I have this user with a problem that I would need to fix, but I also have, you know, I don't know how many other users that are also using that. Not Net rc, they never told me about it, but I need to maintain their use cases, right?
So I can't just invent a totally new way for this new user because he might be good with that, but all the other users I need to maintain so that their files still work. And that is usually the challenge then to make sure that I can fix the issue and not break anything of the old while understanding the issue and making sure, Sure.
This is a file used for other tools as well, right? So [00:46:00] it's supposed to be interoperable. And how do you get that? So yeah, it's a, could be really challenging at times. Yes.
[00:46:06] Beyang: How do you maintain the code base in such a state that you're still able to do active development after all these years? You know, the legacy code is, is a big problem.
Code bases have a 10 tendency to ossify over time. You know, bit Rod is a, a very real thing, uh, especially as, you know, you have, you know, many, many contributors to the same code base over a long period of time. What is your secret to ensuring that the code base stays healthy and remains a place where you can actively innovate and change stuff?
I
[00:46:34] Daniel: think I've been pretty good at most, by chance from the beginning, but more and more by effort to make sure that I abstract away enough in all the APIs and function calls so that I don't give out too many internals or informations about internals so that I am able to actually rewrite quite a lot of things internally without it.
You know, being visible from the outside, uh, that in combination [00:47:00] with a lot of test cases, of course, so that I actually, I can actually verify that things still work the same way it did yesterday when I rewrote all the internals. And I, I actually, I thought of that already when I did my first, uh, code bites of curls so that I, I understood that this would be a way for, uh, how we could manage things going forward without, you know, ruining backwards compatibility.
[00:47:27] Beyang: What do those abstraction matters look like in, in Curl? Like what are the key interfaces?
[00:47:31] Daniel: Well, one of the primary ways is of course, just to be very determined and persistent that we shouldn't break. So if we just made it one way, even if someone comes along later on and says, Well, why didn't you do it like this?
Right? Much more clever and easier to use and fancier and whatever, and then we say, Sure. Good idea. We didn't think about it like that two years ago when, so now we're stuck with that stupid way we did it two years ago. That's, that's, I think that's the primary way actually [00:48:00] just stick with what we have, you know, not be tempted to, to do it differently, just because we could or it could be better.
No, sure it could, but we already did it the stupid way. So we stick to the stupid way. And then when I, when I did things like in the lib curl API for the library, I, I originally had this idea to, to do the library. Like there's this I u CTL and FC NT function calls in, in C and in Li C, which is basically how to set options for a file descriptor.
And it's made to do abstract functions under the file descriptor without you knowing exactly what's underneath. And that's one of my sort of design or original design. Not goals, but I was inspired by that, by that way of doing things. So that's how I made Lial. So nowadays you actually set options on a handle like that without knowing about the internals really.
And that has turned out to be a pretty good way. It has its downsides, but generally it [00:49:00] works good. Um, it, the number of options has grown ridiculously over time, so that becomes a different problem. But it works pretty good. So nowadays you can actually one of those, if you get one of those examples, so actually a data in the early two thousands, you can mostly rebuild and use those examples.
Still today, you know, 20 years. ,
[00:49:23] Beyang: that's, uh, I feel like that, that's like an aspirational goal for every programmer. You know, write, write some code, uh, write a system that is still in use, you know, 20 years down the road.
[00:49:34] Daniel: Yeah. You just have it still use. Exactly, yeah.
[00:49:37] Beyang: At the same time, you're, you're constantly adding like, new features.
What are, what are the things that are, you know, new and curl or upcoming in Curl that you're, you're most excited about?
[00:49:46] Daniel: Um, well, um, just if we look at the last year or two, HTP three support is, is one of those big biggie because HTP three is, I mean, HTP two [00:50:00] was actually pretty big when that came as a new protocol for, I think for everyone who ever implemented HTP in any capacity.
When HTP two came, it sort of, it sort of, it tore down walls and did things in new ways that nobody had, has had thought about before. So it added a lot. A lot of challenges and new ways of doing things that actually had repercussions for a long time afterwards with bugs and stuff like data. Didn't really work with HTP two for, and we still have HDP two bugs today because of the new ways of how we do HTP when two came and now when they, with HTP three, which now is an, uh, published RFC already, We sort of add, add another notch sort of today.
Uh, I'm not sure what to say, but maybe the complexity level. So it's pretty much, you know, HTP two was a lot more complicated than HTP one and HB three is yet another level of complications and difficulties as an [00:51:00] implementer to. And this is
[00:51:01] Beyang: all the complications are in the name of like performance, like reducing latency, increasing
[00:51:06] Daniel: almost exclusively in the name of performance.
There's also in the name of security when it comes in HDB three at least, because now we have even more stuff, um, encrypted and secured over the wire. So it's even less things readable for EA straws and external parties.
[00:51:25] Beyang: Do you have kind of like an explain it like, I'M five, like what were the big changes from HTP one to two and then now from like two to three?
Like what, what are the major? Uh, okay, let, let
[00:51:35] Daniel: me try . So from HTP one to HTP two, which changed how, one of the primary things was that we pretty much split up. So we send everything in HGP to everything in HGP in tiny parts. So we can send multiple connections over the same connection. You know, with HGP one, we used one TCP connection for every request.
And that turned about to be, that turned out to [00:52:00] be really bad, especially for browsers because they wanna do a lot of parallel transfers and they can't really waste a bazillion of connections. So with HTP two, you can do one connection and do many requests over the same connection. So by pretty much splitting up everything in tiny pieces and multiplexing it over the same connection, that is the, the big change with HTP two.
Uh, and with HTP three, we switched from, because when you did that with HTP two, you send a lot of streams over the same connection because that's the term, right? So you could do a hundred, typically you do a hundred streams over the same TCP connection, so you get, get a lot of parallel data over just one connection.
But that has the downside that when you have a lost network, so you lose a few packets in the TCP connection, then all the hundred streams or all post while you wait for that single packet to get remitted. So if you have a loss network, you can lose a lot of [00:53:00] packets. So all those hundred streams suddenly pause Contains very contain.
Yeah, exactly. So when you get a loss network, HB two becomes rather soon worse than HB one, cause HB one then use many connections. So if you lose package P one, you only, so you know, you punish one connection, not all of them. So HGB three is a way to solve that by switching entirely into UDP and, and adding quick on top of that.
And, and when I say quick, now that's not the Google quick that Google once invented. It's now the ITF quick and IATF quick is a TCP like protocol. Done over UDP with, with sort of included TLS . It's a lot here. So with quick, you can set up a connection and do many multiple individual streams across that connection exactly like you could [00:54:00] do with HDP two and individual streams.
But with quick, you can actually lose packets and you can, and you only punish those streams to which those packets belong. So you can actually set up one connection a hundred streams. Maybe you lose a packet or two in there. Maybe three of those streams need to wait until that packet gets transmitted.
The other 97 streams can continue because it's an entirely new transport stack here. So it's not TCP anymore, it's quick.
[00:54:30] Beyang: Okay, so there is no longer like a, the basic unit is no longer a single TCB connection. It's actually going over udp and then there's this like protocol on top of it, uh, called Quick, that kind of manages, uh, this kind of like, um, pack, uh, I guess like it's non stream based, but I'm guessing like quick, kind of like virtualizes streams on top of this so that it, it looks that way
[00:54:53] Daniel: to pretty much, So you, you get it, you actually have, uh, quick connections and now you have quick streams [00:55:00] over those quick connections.
But those streams then become independent of each other. They're in order and reliable, but they're independent of each other, which is kind of an interesting thing because as a, like, uh, in a web context, you can actually, you know, start sending an image, start sending image A, then send image B, but the image B might actually arrive before image A or, you know, it's, it's a new way of, of looking at transfers.
It's, it's a bit of a, It takes a while to get used to. And, and then, so then, so then, um, when Quick was added then as this new transport protocol with streams and the, uh, multiplexing independent better for loss of networks than HTP three, is the new HDP protocol done over quick? Ah, got it. The streaming, the plexing and everything is done by quick, which is, you know, the TCP tls replacement.
So HTP no longer needs to do multiplexing or streams or anything because that's now handled by the [00:56:00] transport protocol. And since it's a completely different transport protocol, we had to do a new h p because it's had to do, it has to do different compression. So it's HB three in, in a lot of ways is similar to HTP two in, in features and, and.
Well, even in, in how it's created, but since it's done over quick, it had to change quite a
[00:56:23] Beyang: lot. And, and how quickly, uh, will, you know, end users, um, you know, uh, people using web browsers, uh, and and command line tools start to like, feel the impact of, of the switch over to HDP three?
[00:56:36] Daniel: If, if, um, I mean everyone was using Firefox or Chrome today, they're already using H P three to large extent, I think up to 25% of the web traffic already from those pressers to all those, the, the major properties, you know, the big CDNs, Facebook, Google, Instagram, you know, CloudFlare, Fastly, those soda.
So [00:57:00] the big ones, they, they run HB three and if you have modern browsers, they do, I think Sfar is going to enable it by default two in soon. And the Edge does two of course. So they're all going HB three and all the big servers are going HB three. Outside of those, I think it's going to be a bit slower for several reasons, because it's difficult to deploy for if you're a smaller server company.
Running it is, is a, it's a, I mean it introduces so many new challenges. Udp, encrypted all the time. It looks like you DDoS attack all the time client wise. It's also completely different. New libraries, new things. You know, the stack is not in the kernel. You have to do timers, you have to do fallbacks. Uh, so yes, it's, uh, it's a new adventure for everyone.
You know,
[00:57:52] Beyang: sometimes I feel like there's kind of these dual forces on the web. You know, on the one hand there's the people working to make the [00:58:00] protocols as efficient as possible. You know, squeeze every ounce of. latency and, and bandwidth utilization out at the same time. It feels like, you know, front end web frameworks, uh, they're, you know, they're getting larger and larger every year.
And so, like, it, there's like, web performance almost feels like this, like constant struggle between, uh, you know, these forces of like, you know, larger and larger payload sizes, uh, at the application level and then at infrastructure level just trying to, like,
[00:58:27] Daniel: certainly like that a little bit, like in the old days when software got slower and slower and the CPUs got faster and faster,
So, yeah. Yeah, it's a little bit like that. And also, I mean, there's, there's this fierce race to lower latency, right? So that's removing round trips and, and making sure that every round trip is actually, you know, possibly a few milliseconds faster. But there, there's also, at the same time, you know, we have cdn, so all of us in the, in the modern, uh, western world, we have very few milliseconds to the closest server that we're [00:59:00] actually talking to.
So, Optimizing away what X percent of their rtt, We don't notice that. We can't even spot it. So even if you go right now, like if we are sitting here, you and me, if you would talk HB one, two, or three, we wouldn't even notice the difference. So it is actually kind of an ironic that the people are actually noticing the most.
They are the ones who are actually the worst, uh, networks. And we're probably in the third world. Whether you have, you know, far away from your servers, Laos networks, crappy connectivity,
[00:59:33] Beyang: I, you know, I almost wonder if there's ever, I feel like people undervalue performance as a first order feature. Uh, and, and how important performance is, like even a, you know, like a one second latency.
It psychologically it's, it feels different, you know, It's like just enough for your brain to get distracted
[00:59:49] Daniel: or, Yeah, Well, I think at, I don't know how people do it in general, but I think at least I think that was the mindset that actually got HCP two going once [01:00:00] upon a time, right? It was almost 10 years ago now.
But, but, um, so suddenly people started to realizing that, you know, speed and latency is actually very important to users and very important to all those sites, especially those of course, who have something to sell, right? Because they realize that if you're just a little bit faster, your customers will enjoy it and they will buy more, spend more time on your sites and so on.
So it is very important to, to a lot of sort of actors on the web. Do you
[01:00:29] Beyang: think we'll ever get to the point where like a web, website, websites and web apps just. They feel native, you know, like a lot of sites I visit, they're still like loading bars, Right? Like that's still a common site.
[01:00:43] Daniel: Yeah. And that's a very good question.
Yeah, , I don't know you would hope or you would expect, but it seems like we've been doing this for so long already and we're not there yet. So I don't know. We'll see.
[01:00:58] Beyang: Maybe there'll be some movement. You know, [01:01:00] there's another, um, company that I'm aware of that's, that's building more like applications in the, in the terminal, their whole, uh, uh, pitches, like terminal ui.
I wonder if there, there might be like a low latency play there, um, you know, combining command line tools and rolling into some terminal based interface. But that maybe that's just, you know, my programmer, uh, , wishful thinking, fantasizing about, uh, a zero latency, uh, world. Cool. Um, yeah, so I, I think, you know, we're, we're basically at the end of the time here.
I don't wanna keep you any in longer. Thanks so much for, for taking the time. Um, is there anything like, last, you know, parting thoughts, uh, that you have for listeners? Like any calls to action, um, you know, like calls for contribution or maybe like financial support that would be helpful? Oh, I,
[01:01:46] Daniel: for, I forgot.
I just wanted to mention that I'm actually also, I mean, I mentioned Tob three as something we're working on the last few years. I actually started also working on web sockets just the last few weeks. So web sockets is also one of those new [01:02:00] things that we are going to land in curl this year, this fall, I guess in a few months or so.
And that's going to be a lot of fun to see where, where, what we can do with that and where we'll, what people will do with it and want with it, and, That's
[01:02:15] Beyang: awesome. That's, that's gonna be such a huge, uh, boon for developer productivity. I think, like having worked on some web sockets based, uh, applications before, it just, it's so much easier if you have like a command line way to, uh, to bug
[01:02:28] Daniel: things.
Exactly. And try it out and, and work with it. So yeah, I'm, I'm looking forward to that, forward to see what people are going to do with it and, and want from it. So yeah, it's going to be a lot of fun.
[01:02:42] Beyang: Anything out there that, uh, people who are listening to this, uh, can, can help, you know, if you have like one ask that you would make of people, what would that be?
[01:02:50] Daniel: One ask. Um, uh, I don't have any ask. I think, uh, I think if you want to help out in a call project, just join [01:03:00] us@curl.se and, and figure out there's a Help Us page. Might be a bit of a threshold and high bar to get into it, but we're all friendly and you can always just ask anyone around for help. Where, I mean, a lot of it, going back to what you said about people are actually thinking, Well, we existed since the beginning of time.
Right? So didn't Curl always exist? Because I mean, Ellis did, right? So , um, and, but we are actually a small project in, in terms of how many we are and, you know, what phases that actually, you know, you can see, well, maybe not faces, but names in the project who will show up, you know, when you enter a issue, who will actually ask the questions.
So we're usually just, you know, a dozen or two of people who are actually will respond, who will be there. So it's, it's a small project. We're casual, we're all friendly, so it's easy access, easy to get to. So if, if you ever. You want to get into the project, it should be easy. And also, even if you have issues, typo in the manual or anything, file issues, and we work on it.
So you'll, I [01:04:00] think everyone who has actually do try will find it easy to work with us and easy to help out or just provide assistance, whatever. We don't really, I don't think we urgently need anything, but we of course, we appreciate help or assistance, whatever, whenever people feel like and can
[01:04:20] Beyang: help up with.
Well, my guest today has been Daniel Steinberg. Daniel, thanks so much for, for being on the show. Thank you. It
[01:04:26] Daniel: was fun.