Curl, libcurl and the future of the web, with Daniel Stenberg

Welcome to another episode of Syscast, the show where we talk Linux, open source, and web development. My name is Mattias Geniar, and today I am joined by none other than Daniel Stenberg, who you may know from a little project called Girl or Lip Girl. Hi there, Daniel.

How are you?

Good evening. Super glad to have you on the show. Thanks for coming.

Just in case the audience, well, the audience I’m going to assume knows what girl is and they’ll probably know what lip girl is, but they may not know you by name. So could you introduce yourself? Who are you?

What do you do in your real life?

uh there’s a real life too well that’s the real life too so yes i i i’m the lead developer and maintainer of the curl project which i started um i started the project a long time ago it actually started before i named it curl but i named it curl and the first curl version was released in 1998 so it turned a little it’s a little bit over 18 years old now um so that’s sort of my main spare time project and i’ve been doing open source and networking related open source a bunch of other projects too for for a long while and that is sort of what’s been driving me on my spare time and in my day job i’ve been a consultant and software developer since long before that of course and well in 2014 I got employed by Mozilla so nowadays I work for Mozilla on Firefox and in the Firefox networking team. That’s super cool. Is that a full-time job for you?

That is a full-time. Well, actually, I’m allowed by Mozilla to work on curl part-time. So I actually do curl part-time and the rest is Firefox.

And then I do curls part-time too.

Indeed, it sounds like something really up your alley, perfect for you. So you started Curl a really long time ago. It’s sort of embarrassing to say for me because I think you started Curl when I was 10 or 12.

That says something about the age of the Curl project. The age of me, perhaps. I did not want to say that, that you mentioned.

Why did you get started with Curl? What motivated you to start Curl?

Well, already at that time, I had been dabbling with other open source things and the networking. And at the time, actually, in the mid 90s, I and a couple of other friends, we wrote an IRC bot that just, well, on the IRC. Back when the Fnet IRC split back in the middle of the 90s.

And then we wrote a bot for a couple of channels that we hang out in. And then we wanted that IRC bot to be able to provide currency rates for people that were chatting in the IRC channel. So I just wanted a little tool to fetch currency rates every now and then. and they appeared on websites of course so they were available over http so i just needed a little tool to transfer currency rates over http and at the time i didn’t find any other i found a little tool called http

that you actually find a problem that you want to solve and you just solve it. And then another person comes along and solves a related problem. And then you find another reason to go ahead and sort of, and then it just grows from there.

And that’s sort of been the story ever since. I mean, I think I’ve scratched most of my own itches. Now it’s more like fixing the problems that I’ve introduced and making sure that it gets better.

And now it’s just…

sort of the the joy of making something that a lot of people are using and making sure that it actually works as good as possible yes and i think what you’re doing has an uh the ability and it already has an immense impact on the web that we know today the web that we use or the applications that we use to interact with it it’s an insanely large project I think curl is mostly a two-part project. There’s curl, the command line interface that we use at the command line to interact with the protocol. And then there’s libcurl.

Could you describe where are they different?

Yes. Well… it started out as a command line tool back but then in 1998 and and and i pretty soon and already when we when i released the first version of curl it it could already do http ftp and gopher and it could upload to ftp and it could upload data to http so but quite It wasn’t that long until I realized and I got requests from people that wanted to incorporate sort of the file transfer abilities into their own programs. They wanted a piece of curl into their own programs to make sure that their programs could download and upload data using these protocols.

So, of course, it sort of came natural for me to export the file transfer abilities or the actual sort of the core of the command line tool into a library. And I had basically designed it like that from the beginning. So I converted internals of the command line tool into a library.

So Libcurl, the library, was released in 2001, the first time. And that is basically a small C API to do…

Well, there are many protocols in this world. So yes, but it supports, I believe, it depends on your account, but it’s like 21 protocols or something like that. But as you say, it’s mostly known for HTTP and it’s also mostly used for HTTP and HTTPS actually.

So the biggest protocols that are actually, that people are using, Libcurl with and Curl for that matter is, they are HTTP, HTTPS, FTP, FTPS and SFTP.

Lip curl is a library, a C library. It’s used in PHP, in Python, in Ruby, pretty much any language that you can think of somehow or somewhere uses lip curl. How does that work?

How do they interact with you? How do you make sure that’s compatible or that their wishes, their features work with what you had as a design for the library?

Well, it mostly works by us, I should say us, because it’s certainly not just me alone. So we’re a team making this. So we provide a library with an as stable and solid API as just… possible so we provide an api that just doesn’t change if you write in a program today it’ll work with the with the lib curl we release like five or ten years down the road as well that makes that makes it reliable and and people won’t really have to communicate back to us much if they just rely on the api they can do whatever they want so most of these users of lib curl they they don’t They don’t really communicate back to us.

We deliver our things. They use it. So that’s sort of how it goes mostly.

You’re building the API that is powering most of the programming languages that we’re actually using today on the web. It’s a cool behind-the-scenes job, I think. Really powerful way to be…

You wrote a blog post not so long ago where you claimed, and I think it’s probably right, that Girl has over a billion users. That’s not a number that you just randomly came up with, I think.

No, it’s certainly not. But I tend to avoid speaking about users too, because users is such a hard concept when you’re making a component that is often used within devices and services and tools. For example, Libcurl is used in iOS, Apple iPhones, iDevices, so in iPads and iPhones.

Apple says there’s a billion active devices, right? That’s a billion right there. I know that, for example, Facebook is also sort of an intense user of Libcurl in their backend stuff.

Of course, that doesn’t really make it that everybody who uses Facebook is a user, but it still sort of empowers and enables a lot of users.

No, no. I had no such sort of… Maybe I could have dreamt about it, but I could never anticipate it.

I had never expected it. So it just… I didn’t ever really even notice when it happened.

It just slowly, slowly, gradually took over like this. You gradually took over the world. It just sort of happens.

You know, that could happen to anyone.

Exactly. You mentioned it already, curl supports a variety of protocols, not just HTTP or HTTPS. I think if I remember correctly, it supports POP3, IMAP, to Telnet, to all kinds of protocols.

We probably don’t even know curl supports yet. How can you keep that inside a single client? That has to be really hard to keep that many protocols to work.

Yes and no. It sort of goes like this, that the most… used protocols they sort of get the most tested and most they get also get more bug reports but it also goes the other way then so the the less used protocols they they get less used and we get less fewer bug reports on those and sort of so it isn’t really that hard and also once we’ve made implementation we have the test cases we have the documentation they they’re usually fairly easy and easy going to just keep keep going as they are and just they don’t they don’t hurt as much while they’re there. So no, it’s not that hard.

I mean, it grows the code base and it makes certain things more complicated, but usually more protocols, that’s not really what makes it harder to maintain. We have other insane things that make things harder. For example, that we support a lot of different TLS. backends for those protocols that supports TLS.

And that’s more of a struggle and a battle to keep sanity.

Yes, exactly. They’re all different. They have all different FPIs.

They have all the different flaws and sort of pros and cons. And we have to write a glue layer for each one of them And, you know, TLS, that means basically security and security is hard. So that’s an endless source of potential problems.

I mean, security wise and just complexity wise.

I can see that, especially if you’re following the web the last couple of years. A lot of TLS ciphers have been found to be vulnerable to attacks. A lot of them have been deprecated.

New ones come along. There are a lot of new protocols and ciphers being discussed right now. They all have to be implemented and maintained on your end.

Yeah, exactly. I don’t have to implement the ciphers since those are in the TLS libraries. So they are implemented in the TLS libraries.

But I often have to adapt our use of the libraries so that we make sure that we only use the correct parts of the libraries and so on, and use the libraries correctly. So that is actually a source of many of our recent security problems have been that it turns out that we haven’t used the APIs properly for specific libraries or whatever.

Yes, right. Yeah, and I think that is sort of how our security problems have been over the years, that they’ve been pretty specific for certain use cases. We have a fair share of them, but none very serious so far.

And we’re doing our best to not let any one of those slip in.

A couple of years ago, OpenSSL had its share of problems. As a result of it, there were a couple of forks from large projects. We have PolarSSL, we have BoringSSL, LibreSSL.

Do those forks make it more difficult for you to implement in curl or is it really all standardized and doesn’t matter that much?

Yes and no. I mean, if any project that supports OpenSSL, the OpenSSL API, will have it fairly easy to also support LibreSSL and BoringSSL because they’re sort of, at least in their LibreSSL and BoringSSL are sort of diverging from the OpenSSL way slowly in different directions. So it is fairly easy or it has been fairly easy. at least up until now but I’m sure that they all three of them will go different paths from now on so the difficulty will increase from here so I don’t know exactly where that will go or how we and everyone else will handle that but they at some point in time we we will probably i don’t know it depends on how they behave but they might at some point be considered different libraries and not just forks of the once open ssl api it would make sense they forked it in the first place because they disagreed with probably a lot of choices that were made and it only makes sense that those projects slowly diverge into their own their own settlement Yes, and also OpenSSL has changed a lot since after the forks.

So even in the OpenSSL project has sort of shaped up in a lot of ways since after the forks were made. So they are cleaning up their API quite intensively right now. And the other ones are not following that API cleanup the same way.

So they’re sort of cleaning up the problems in different ways. Do you see all those forks as a good thing or a bad thing for security? I’m not sure how it will turn out for security in the long run.

In general, I think forks are useful because it unblocks certain development bottlenecks that can happen in projects, but it also spreads the efforts so that now we’re having three teams working on basically the same thing instead of having one team. I’m not sure. I think we’ll just have to see what the future shows.

It can be good, it can be bad. Hard to tell which way it’ll go. If only we could predict the future.

I think I share your opinion in this. In a way, the forks have already motivated OpenSSL to move, I’m not sure in a faster way, but in a different way, in a more secure way. At the same time, as you mentioned, the forks are probably heading in slightly different directions and that will put a bit more effort on those implementing the libraries like curl.

At one point, it’s not unthinkable that just implementation details are going to be done wrong by implementers, not only in curl, but everywhere OpenSSL is being used. it’s going to be more difficult or more easy to make a mistake if all of those projects take on their own path. So that could be bad for security.

Time will tell. Yes, but I also think that… A little depending on what OpenSSL does.

I think that, for example, LibreSSL might have problems getting traction. So why would people switch to LibreSSL if OpenSSL sort of shapes up enough and they change their API at the same time? So I think maybe in the long run, LibreSSL will have a hard time to keep up and boring SSL is Google anyway.

So Google is going to make the… own routes so they’re not really affected by what anyone else does anyway so it depends also what happens and in the boring ssl case which is google’s library then they basically make a boring ssl for their own purposes so they haven’t really made it really easy for others to keep up and to use it so we’ll see what happens so their use case is slightly different from all of us mere mortals trying to run a web server

Yeah, it’s confusing naming when you write it down. It’s getting really popular on GitHub, and I think most of it is done, or most of its popularity is attributed to very fancy screenshots that they can show where the output is just being colored, as in headers are being shown in key value pairs with clear color distinctions. The HTML output is being, well, run through some kind of parser that can color an output.

How do you feel about that, with those new clients emerging?

Well, I think that’s just great. I mean, if there’s a need or if people want to write it and people want to use them, so fine, that is just great. And I also think that’s good for innovation.

People can try out different things and offer features. And of course, if people then think that those features are so awesome that we should also have them, then I’m sure that someone will eventually make them happen for Curl 2 if they would be that sort of interesting in my case i tend to just get overloaded with things to do anyway so there’s hardly a shortage of things to do so even if so things like for example enhancing the command line tool curl to do a colored output that tends to end up far way down

Exactly. Yeah. And I also think that sort of people are using curl to such a large extent to, you know, show how an API works or describe it on websites.

So there’s so much documentation and online tricks and hints and help everywhere.

Oh, yeah. Imagine how many monitoring agents and clients are building on top of curl to fetch pages, check if a status code is ready, and wake some kind of engineer in the middle of the night if that’s not the case. Exactly, yeah.

I think that would be the bad use case of curl, waking engineers in the middle of the night.

It’s been a lot of work, actually. But it turned out I started, I wrote the book or the paper or whatever we should call it after I made a couple of presentations on the topic. And then I got so many questions about it from people who couldn’t attend or people who asked me afterwards about the details.

So I decided to try to sort of document everything in a more permanent way so that people could read it in their own time and read it on paper instead of looking at video presentations or listening to me talk or whatever.

It’s a pretty hefty book by now. If anyone’s interested in learning more about HTTP2, that’s definitely a recommended read. We’ve been running HTTP2 for I think about a year now since it was final, while ignoring SPDY.

How do you see the future? Should we look at HTTP3 or are we going to see a 2.1 spec first?

I’m quite sure that there won’t be a 2.1. One of the key things when HTTP2 was made was that it is HTTP2, not 2.0. So there’s no minor version in this protocol.

So you’re either compliant and you work with HTTP2 or you’re not compliant. And if you’re not compliant with HTTP2, it’ll be something else. but but and that said what comes after http2 or in parallel with hp2 that is sort of not crystal clear and it’s not a given what what is going to happen we’re already seeing now as um google experimenting or not I would possibly even call it more than experimenting. They’re running QUIC as a protocol for both within Chrome and Google services.

And QUIC is sort of an experiment beyond HTTP2. I wouldn’t call it HTTP3, but it’s definitely… somewhere in going in in a direction beyond the gp2 at least could you describe what the difference is what is quick perhaps quick that’s then q u i c that is a protocol which is first of all it it is run over udp so it’s not tcp and it is so which is quite different than because most of http and transfer protocols have always been over tcp so this is a protocol over udp and then they implemented basically the rest of the protocol stack themselves running then from a client perspective in the browser so they have a sort of tcp tls and hp2 protocol implemented in user space than over udp that’s a lot of things too a lot of acronyms a lot of acronyms get into your brain and by doing that um not only can they iterate really fast um i would say that is possibly one of the better things they got out of this. You know how slow it is to, for example, change things in the TCP implementation or specifications, adding TCP options and things.

That takes forever in standardization. And then you have to take forever to get it into kernels everywhere. And then in the end, you get problems on the internet anyway, because there’s too many mailboxes that prevent that from working the way you want.

And by implementing this protocol all by themselves, basically in both ends, they could iterate really, really fast. And also by doing things like going over UDP instead of TCP, they have addressed several shortcomings that HTTP2 still has. Like, for example, TCP head of blocking, which basically means that if you’re using HTTP2, you’re doing a lot of streams over a single connection. which basically in the real world that’s the maximum number of streams is usually 100 so you can have 100 parallel streams going on over one physical TCP connection and if you drop a couple of IP packets there when talking to your remote site that those lost packages in the middle that they affect that single TCP connection but that single TCP connection could be 100 different streams and they’re all sort of will be put on hold until you have retransmitted those missing packages packets in the middle of that TCP stream

Yes, it is. But it isn’t that big of a downside compared to HTTP1. Because usually when you drop packets, you drop packets on all TCP connections.

So usually when you have six TCP connections, like in the old days, you lose packets on all of them. So it’s not really… much worse than HTTP1. It’s actually better than HTTP1 in many cases, because it’s usually better to have one connection that loses packets than having six connections that lose packets.

But it doesn’t matter. But in the Quick case, they have made it so that they send packets that you can actually lose packets in the middle. And if you lose a packet in the middle, it’ll just affect one stream or a few streams, but the other streams can go on.

That is one thing that they addressed by doing it this way. They also, for example, they don’t have the same connection, you know, the tuples you have when you have a TCP connection, how you know that it is a TCP connection, you know, the IP address, the source and so on. They don’t associate connections with the same way in QUIC.

They’re not based on the IP address at all.

Yes. Yeah, exactly. That is the challenge.

I think the number is 7% that don’t work at the moment. I would have expected more, actually. I believe that’s a number from Google.

Yeah. The number is also hard to know for sure. That’s a number they know with failed attempts.

I would imagine that it might be higher in certain enterprise environments where they haven’t yet run that much of quick experiments.

That’s cool. If you look at the inspector right now, it still shows HTTP2. Is that something being done behind the screens?

No, if you see HTTP2, it is HTTP2. So then it’s not using QUIC. You’re absolutely right.

It’s now showing QUIC or SPD3. I totally missed this. That’s cool.

I can’t really say if it’s faster or slower because it’s always fast, Google. But it is cool to see that this is working.

Yes. So how fast Quick is in comparison to other things, that is, of course, still left to see. I’ve seen numbers that Google have presented about how fast it is in comparison.

Yes, it is faster, but it’s also sort of not crystal clear in all cases if it’s better or worse. And there are a lot of obstacles still to solve. And I mean, we’re basically at that point where that Google was in when they made Speedy.

And now they’re taking Quick to the IETF basically in the same way. Well, not exactly the same way, but like they did, like Speedy was taken to the IETF when HTTP2 was made. So now they’re going to try to make quick an IETF standard or at least an RFC.

I’m not sure which track they’re doing an IETF. So they’re going to try to make it properly documented and pull through the IETF system.

That’s cool. There’s a lot of innovation coming from Google. Is this something that you see?

Well, probably you’ll have to. Curl will probably support this eventually if the spec is final.

Yeah, of course. I would be happy to support it much sooner than final two, but it really depends on time and how it’ll develop and so on. So yeah, I would like to get started on something quick-ish soon, but I’m not sure how much, if I’ll manage that.

In the HTTP2 case, I was sort of saved by a lot of the framing and the binary level stuff being made by a very productive Japanese guy. So we’re using a library for a lot of the underlying HTTP2 magic. So that made it easy for us to support HTTP2 really early on.

Thank you, productive Japanese guy. Yeah, it’s the ngHTP2 project.

Yes, yes. And he’s amazingly productive. So he works hard and he’s very good.

So when he does things like that, it is very useful for your project.

I don’t think that will be HTTP3. It might be what we could consider a successor to HTTP2, but I don’t think it’ll be called HTTP3. So no, I don’t think so.

Okay. But I think those are mostly like technical reasons. It doesn’t matter what it’s called.

True.

Oh, that’s a really good question. I’ve never been a really good, you know… visionary guy looking forward into the future and and and thinking about how things should or will turn out so that that’s never been my my big thing in life so no i don’t know i think there are things we should I think there are some problems with HTTP, like, for example, cookies. But on the other hand, we have such a weird infrastructure on the web and on the internet that some of those things are really, really hard to change.

So it’ll depend a lot on what sort of will we can collect among the people that are going to do these changes and write the code and make everyone do the changes to the infrastructure that would be necessary to change things like that so that is so that is why it’s hard to predict when is for example then cookies is cookies ever going to go away maybe but it’ll take a huge effort and it’s hard to tell if that huge effort ever is going to actually manifest or if it’ll just never happen

It’s odd that we, I say we, I never had any part in it, of course, but to have some kind of state in a stateless protocol, cookies were invented. After all these years, they’re still here. And by now they are so ingrained, so there that you can’t really remove them again from the world of HTTP.

It’s a hack that became something of a permanent hack.

yes but also because of that in like in comparison to for example web servers or web browsers there are many many many more implementations of cookies so it turned out that most almost everyone has made their own cookie implementation. So changing cookies is much harder than changing basically anything else in HTTP. That’s too many edge cases.

Yes, and too many custom things that just was made to work exactly like it worked once. even if no spec ever said exactly like that. So we’re sort of stuck in something that a lot of people have built over the years.

Yes. It has to come from people that can actually deploy and run things in the wild across, I mean, on the real internet with a wide variety of use cases. But these days, especially after we’ve deployed HTTP2 everywhere with ALPN, for example, in TLS, it is now at least much easier for anyone to introduce new protocols to experiment with.

It’s much easier now to upgrade to another protocol. If you and me make a protocol tomorrow, we could call it matthias protocol and we could actually negotiate that over the network i’m already fantasizing what the matthias protocol could do it would probably break everything but at least i would only break your um yours and mine client and servers so i mean it has actually made a fairly neat infrastructure to actually start

Oh, that is a good question. I sometimes get so amazed by all the stuff people are doing. We are so many people working on so many different areas of the web and the internet.

So I tend to get a little blinded by everything. So at times I just take a step back and look into my own little corner to keep focused on the stuff that I am… post to work on and do on. So no, it’s really hard for me to predict.

But of course, at Mozilla, we’re focused on, I mean, I shouldn’t say focused, we’re determined to keep making the browser and the web good and accessible and usable for users. So we’re trying to be user focused and make things better in general for for users on the Internet. And what that means, I think it’s not that easy for it’s not up to any single player to say exactly where we’re going.

So we’re, of course, trying to steer things and development in the direction that we think is the correct one. But then we’re only so few. So it’ll be It’ll depend on what everyone else thinks is the correct way.

Well, yes, but this particular implementation is actually made using the networking stack in Firefox, but I’ve not been involved in the implementation of it. So the implementers of this, they’re just using the networking stack and we have worked on providing the features that they need for this in the networking stack, but they have implemented it. Also, I have no particular insight.

They basically have made sure that the concept of origins within the browser can also be added so that you can have origins and a bunch of other parameters that have to match for it to be the same origin. So then you can make sure that you have the same actual site in different tabs, but you also need more parameters to match for them to actually be considered to be the same origin by the browser. That is how it keeps things separate.

I think that’s very cool. That’s not something that is only possible in HTTP2. It’s something that’s possible in the spec in general.

Even though it’s that old, the protocol, seeing innovation still happening after all these years, I think that’s pretty cool.

Yeah, I agree. And I think that is one of the… things that fascinates me with working in this area that we’re having this internet and the web and stuff that have existed now for quite a number of years. And we’re still seeing that this pace of development, we’re still seeing this imagination, this level of new ideas and things.

And I think we’re going to see things growing and innovating for quite some more time. For example, just looking at this trend that we’re using much, much more objects on each website now, much, much more data. We’re using much more video.

So I think there’s a lot more to be done, I think.

There are a lot of areas to improve in. I think probably the most difficult one to improve will be the one where web developers, agencies, advertisers make correct use of those implementations like not spam video screens in advertisements on top of pages that you have to click through. Those are also very clever implementations of the protocol, but I doubt they’re doing anyone any good.

Hopefully that’ll change. right but that’s more a question of of how to handle the content and and who’s going to provide it and using what means so i think yeah that is a that is a question that we will struggle with for quite some time i think yes indeed thankfully we have a lot of time so there’s a lot of lots of possibilities to fix this but yeah it’ll take time even the quick protocol will probably have the same challenges um because it’s purely an implementation of that protocol

Oh yeah, I don’t think we have seen any major new innovations in that area. I mean, we’re all just sending HTML and we have things sent in different ways over the HTML. So yeah, we haven’t modified that much.

No, we can just send it faster. Yeah, or earlier.

Yeah, true, true. Slightly unrelated question perhaps, but I wanted to check with you. If you’re a web developer today, if that could be Python or Perl or PHP, whatever, according to you, which web-related technologies should those listeners invest time in to master?

What’s relevant for a web developer that they should master today to still be relevant in five years?

um that is good it’s a good question i’m not sure i’m the most suitable person to answer questions about web in general because i’m too much focused on transfer and transfer protocols and not that much on a more high level web webby things but possibly i would I don’t know. It’s a difficult question. It is a difficult question.

I would say that, for example, right now, I would say that there’s a movement to make sure that things work better offline, to make sure that things in the web is more… app like for example and I that’s the sort of a trend that I like because it makes the web better and everything that makes the web better especially when you sort of yank out your cable or end up on an airplane it’s a good idea so I think there’s a but in general no i don’t have i’m not much of a webby guy i’m i’m sending things over protocols and wires but i don’t i’m not a web person that’s that that sounds odd coming from the person who leads the curl project

Yeah, and sort of my entire focus, and not only in my spare time, but even in my work time, is I’m… I’m mostly doing transfer things, networking things. I don’t know a lot of things above the actual networking.

So when it comes to things that are actually in the content or using the networking on top of that, that’s not my area. I’m not an expert there.

Yeah, makes sense. From my personal point of view, if someone’s listening and they want to learn more about just the web in general, I found just trying out curl, just typing curl dash dash help and looking at what each parameter does gives you such a big insight into the protocol, into those teeny little details that actually make a difference between a request that works and a request that hangs or fails. Just understanding this from a rather low level gives you so many possibilities and so much power that you can use it in a variety of cool ways.

But it takes time and effort to just look at either the curl manual or the spec, which is rather boring to read.

And hard. It’s hard. I mean, it’s so much.

So it’s hard, actually. understand the details if you read that entire huge thing. So no, I agree. I think that if you want to be an expert in something, getting to know sort of the fundamentals, like if you want to be an expert on cars, you might want to know how the engine actually works, maybe.

Or maybe you don’t. It depends on sort of where you’re striving, where you want to be. But I, of course, think that protocol details are interesting and often very valuable to know and master, even if you’re not implementing your own protocol or anything.

Just knowing how it works and what the limitations are, how the mechanics work, that’s useful and that’s going to be…

I think in general, I think you should keep an eye out. out on things that you think is fun, because I think open source in general benefits from people participating in what you think is fun and interesting and getting involved in whatever you think is fun and interesting. That is what is going to drive your interest and make you learn things if you think it’s fun and interesting. So I think you should just go with whatever you think is. looks like the right thing for you.

It doesn’t really matter. And of course, if you want to be sort of part of what is developing right now, you would just dive in and find an interesting project that you read about or learn that it exists and does something fun that you’re interested in. But in general, I think that is…

Fairly good guideline. Just go with what you think is fun.

I don’t see myself stopping maintaining it. But I mean, there is no law in nature that says it has to remain like this forever. There could be a replacement at some point in time.

I could grow bored at some point in time. Or maybe this sort of technology changes direction so that something else becomes a more relevant project. Who knows?

In general, I believe that our web of today is becoming too compartmentalized. We have less and less big players. I mean, we’re going to internet and web in particular than we’d… fewer and fewer big players and not as distributed as it once was and as distributed as we once thought it should be and you know democratizing and everything so I believe that distributing things and making trying to get back to being getting more players on the internet that is only good I think even protocol wise I think having distributed things are in general better because it’ll be more I mean, it’ll stand up against problems and reroute around problems better.

It’s true.

It’s a bit at odds in the way that, well, let’s spring back to Google. They’re having a bit of a monopoly in a way on the web. They manage so much on the web in a way that’s beautiful.

They can implement protocols like QUIC and improve the web for everyone. at the same time right now we’re happy because all of those changes appear to be good ones and are in favor of the open source web what if tomorrow they make a change that does not sound so good and it turns out that they manage about 50 of all the web traffic are we still going to be happy if big players make changes that perhaps we don’t like to support it’s a tricky question in the future but that is also sort of a reason why

Sounds about right. Let’s see if in about 10 years that worked out. I think what the track record has proven us so far is that the IETF is good at receiving, looking back at something like Speedy, it’s a really good implementation, but IETF just doesn’t say, yes, it’s good.

Yes, it’s good, but we’ll need a couple of changes to make sure that it’s future-proof and independent from Google. So those are all good choices.

Yes, but also it is kind of natural because when a company like Google, like in the Speedy case, they bring a protocol, when they provide a protocol sort of framework where here we wrote all this, this has proven to work, which all is good, you know. feedback and info, we have metrics, we have data, it works this good. So, okay, now we see that one of these, it is possible to deploy a protocol like this on internet. Good.

But then it turns out that Google is only one company. They have had their set of goals and use cases that they made the protocol optimized for. When they bring that to ITF, they’ll… suddenly face that there are a lot of other companies with different use cases and different ideas of what sort of optimizations that are good and which are bad.

So it makes sense that they can’t really drive their changes completely because all the other players in the IETF, they won’t agree that all the decisions were the right ones or the trade-offs probably could be done differently. And then you have to sort of debate that and make sure that people agree on on why things are made and how things should be made to actually reach whatever you want to reach yeah the hard part of democracy is getting everyone to agree uh so yeah it can be really hard times actually yes

Yes, and actually by IUTF standards, HB2 was really fast. So it might have been considered long, exactly by that reasoning that speed already existed and was working. But I think pretty much every little bit that was… provided in the Speedy spec has been modified in some ways in the HTP spec.

So every turn, oh, sorry, every stone had to be turned, basically. Yeah, all for the better.

Okay. Daniel, it’s been an absolute pleasure to have you as a guest. This was a really interesting topic.

I had a lot of fun recording it too. I hope you did too. If people would like to reach out to you or get in touch with you, how can they best get in touch?

Well, I am at Bagder on Twitter, which is an old nick I’ve used since forever. That’s why it’s so strange. And my website is at daniel.hacks.se.

Hacks with H-A-X-X dot S-E.

I’ll add all of those links in the show notes as well. Daniel, thanks again. Enjoy the rest of the evening or night as we’re about to reach.

Take care. And if I ever need another happy guest, I will gladly invite you again.