seanmonstar

hyper Roadmap 2025

Tue, 10 Dec 2024 11:48:00 +0000

After a year since hyper 1.0, we’re updating the ROADMAP. hyper is an HTTP library written in Rust, used by many in production.

The purpose of the ROADMAP is to highlight what is highest priority in order to continue orienting hyper towards its VISION.

It’s based on interviewing our users to see make sure what the most important things are. Writing it down is a way of letting users know what’s coming next.

Open source is guiding

Open source is not a company, and so people can work on and contribute whatever they want.

But we can guide contributions, by outlining what is most important for the project. Thus, a secondary purpose of the roadmap is to be a guide for those interested in contributing, but not sure what to do specifically.

Focus Areas

The roadmap breaks down four focus areas:

Documentation: Invest in docs, guides, and examples to ensure users can learn how to use hyper.
hyper-util: Provide new helpers for use with hyper, and stabilize and graduate some into hyper itself.
HTTP/3: Harden the h3 crate (reqwest uses this already!), and use it to power conn::http3 in hyper.
Observability: Improve visibility into hyper’s operations through stable support for events, tracing, and metrics.

A living document

The ROADMAP is a living document. As we make progress, or as priorities change, the document can too. Proposals for additions and edits are always welcome.

Contribute

If you’ve wanted to get started contributing to a Rust open source project, help us build hyper! Pick one of the focus areas that interest you, and reach out in an issue or Discord. We’d be thrilled to mentor you.

hyper in curl Needs a Champion

Tue, 19 Nov 2024 09:48:00 +0000

tl;dr - hyper in curl is nearly complete, but it needs a champion. Without a partner actively engaged that wants to enable and ship, it’s now on the path for being deprecated and removed.

It needs a champion, a backing vendor or distro. Will that be you?

Why would you put a hyper in a curl?

Why would you? Memory safety.

Company after company, product after product, report after report. Memory un-safety. Causes. Serious. Issues.

curl is everywhere. Billions of installations. It’s likely all humans accessing the internet use curl.

A self-analysis of curl finds that half of curl’s vulnerabilities are C mistakes. Memory safety.

As I said when when we told the world about it:

Considering how much curl is used, this was an opportunity to make the internet safer.

hyper is the most mature HTTP library written in Rust. By making hyper a possible HTTP backend for curl, the code used for the most ubiquituous protocol could be made safer. Certainly true for HTTP/1, even more so with the much bigger (code-wise) HTTP/2 and HTTP/3.

So, why do this? Oh, right. Ahem. Memory safety.

Most of the work is done

Let me back up a little.

In 2020, we started exploring the idea. I designed and built a C API for hyper. Daniel refactored curl to allow for HTTP backends, and integrated hyper.

We got it nearly complete. Adventurous tinkerers were able to build and use it on their personal machines. Over 95% of curl’s large test suite was passing.

I gave a talk for curl up 2022 about the progress.¹

We’re ready to finish, technically.

Over the finish line

Funding for an engineer to complete the work is available.

But the upkeep of the feature isn’t free, in both the curl and hyper repositories. Because of that, and without a commited organization wanting to ship it, it’s planned to be removed at the start of 2025.

So, what exactly could change that? What is needed?

Champion required

A champion, if you want it.²

A backing vendor or distro that wants to enable and actively use the backend. A launch partner. Many people know what it’s like to work on a large new feature, ask people to try it out, and everyone is too busy, assuming someone else will. A launch partner actively tests it and provides feedback.

There’s more incentive to partner than ever, as we see companies successfully make code safer. And this project is so close, adopting now can have a large impact compared to the remaining effort.

Reach out to me if you want this to happen. Sooner rather than later. Let’s make the internet safer!

Recently, a few more things have been improved on hyper’s side. For instance, @nnethercote and @jsha significantly improved the C docs, and @hjr3 added HTTP/1.1 trailers support that curl needed. ↩
People always end up doing exactly what they want. There’s a loud rewrite-it-in-Rust sub-community. Here’s an opportunity. Actions show what people actually want. ↩

hyper HTTP/2 Continuation Flood

Wed, 03 Apr 2024 14:11:00 +0000

Patches are available for h2, v0.4.4 and v0.3.26, to harden against a newly disclosed HTTP/2 attack vector, mostly for servers. If you need help, reach out for support.

If you’re curious about more, read on.

What is the attack?

In HTTP/2, there are a bunch of frame types. Some of those frames are related to sending headers (or fields). Since there is a maximum frame size, in order to send more headers than fit, a peer can send CONTINUATION frames that indicate more headers for the message.

That mechanism is the source of a new attack, trying to send an infinite number of CONTINUATION frames to starve or kill a server. This was a coordinated release, with various implementations involved. VU#421664 has details about the others.

hyper’s `h2` is somewhat affected

The HTTP/2 specification doesn’t state a default value for SETTING_MAX_HEADER_LIST_SIZE. You should set that to something reasonable for your use case. But even if you don’t, h2 picks an emergency default, which is fairly high so to as to not reject requests for users who need big requests.

Once a stream of headers and continuation frames reach the limit, either configured or the large default, memory growth will cap there. h2 will keep reading and decoding, but discarding any new headers. Really, it’s trying to keep the HPACK table in sync, and will send back a stream error once finished of “too big”.

The problem is that h2 won’t stop reading as long each CONTINUATION frame says there are more coming. So the memory stays the same, but it will use CPU to read and discard. And since the headers are never “complete”, the application doesn’t get to know about the processing of frames.

However, if deployed on Tokio (or some other runtime with a similar feature), the task budget will prevent it from locking out other tasks. Other requests can be served, and responded to. But it will make it slower.

A degradation of service.¹

What we did

Besides testing and determining the above, we also worked on a fix.²

We realized that while a lower SETTING_MAX_HEADER_LIST does help, it’s not the only thing that needs to be checked. The reason for that is because a CONTINUATION frame could be sent with the smallest header value, and thus take longer to reach that maximum. That will still consume resources processing frames.

We figured that a maximum needed to be set on the allowed CONTINUATION frames. But a naïve hard-coded number has its own problems.

The maximum frame size isn’t usually changed, which means you’re stuck with 16kb frames. And if you do want to allow message headers bigger than that, then you need to allow CONTINUATION frames. Since both frame size and header list size are configurable, a hard-coded limit wouldn’t work.

We settled on calculating how many CONTINUATION frames would be needed for a legitimate message to send up to the max header list size. We also add a little bit of padding to that number, to account for frames that may not be perfectly packed.

The patch has been tried out on some production servers, and found no false positives.

What you can do

If you don’t use HTTP/2 on a server, then don’t worry.
- If you do, but are not exposed to untrusted L7 traffic, also don’t worry.
If you don’t set the SETTING_MAX_HEADER_LIST_SIZE, you should consider doing that.
You should run cargo update -p h2 in your application to pull in the latest versions with fixes (v0.4.4 and v0.3.26).

If you need help, reach out for support. Or send thanks, so that months long security work like this can be done in the future.

For this reason, we didn’t create a CVE. I’m sure some well tell me I’m wrong. I’m already skeptical of CVEs for denial-of-service; it’s a big deal for some people, and not at all for others. I’m also very wary of alert fatigue. A degradation of service, where things are just slower, does not feel like a “wake-up-your-team” moment. (We did submit a RustSec advisory to nudge people to upgrade.) ↩
Noah Kennedy and I have worked on this on and off for a few months, while waiting for the VINCE deadline. Thanks Noah! ↩

Podcast: Rustacean Station, hyper 1.0, and independent maintainership

Fri, 29 Mar 2024 10:09:00 +0000

I was recently a guest on the Rustacean Station podcast. It was nice to catch up after a couple years since my last appearance on the show. We spoke about hyper, how and why it became v1.0, becoming an independent maintainer, future work, and more.

I thought I’d grab a few fun and interesting quotes, with their timestamps:

Sponsoring is not the Mafia (11:48)

The lowest engagement is sponsorship where it’s like, what am I getting from your sponsorship? If you turn it around and think about, well, a lot of times open source is like this common good that everyone kind of benefits from and I don’t want to pay for it because someone else is going to pay for it, right? It’s kind of like this Russian roulette of like, well, if no one pays for it, then eventually that thing is going to go away.

So sometimes when I talk to the companies, I just ask them, hey, how much are you using this stuff? You’re using it a lot. Cool. How annoying or how much work would it be to have to maintain it yourself if I were to just disappear? Oh, then we’d have to put a whole engineer on that or something like that. Okay. So if you think of it as a business risk mitigation to sponsor, then I can keep doing it. And then it becomes like, okay, well, we would pay a full-time engineer to do this all year. We can pay a way smaller amount to just have the sanity check that this is not going away.

And so what do they get? They get a business risk mitigation.

You’ll have to excuse me, but I’ve been watching a lot of Sopranos. And so when you said, how bad would it be if this thing happened to go away? It sounded a little bit like a tactic they might use to secure the contract.

(laughs) Yeah, it’s not like an insurance racket.

Access to the maintainer / advising (12:50)

There’s more things that I can offer and I do offer. Another one is people want to be able to ask, hey, we’re using your stuff and we want to know are we using it correctly or, hey, we’ve been trying to use it and we have this problem and we don’t understand why. Could you take a look?

If it’s a private project, people aren’t going to post their source code into a public issue. I’m not going to have the time to go and take a look unless it’s like, hey, let’s get a retainer and I can now sign an NDA. I’m not going to steal their code, all that legal stuff.

It’s like getting an advisor, a reviewer, and then I can then take that knowledge and go back and be like, okay, so I now have knowledge that like company so-and-so is using this in a way that I didn’t expect. How can I make it better for them? So like, both sides benefit, but it’s only possible if I set up contracts and everyone’s legally happy.

Breaking people, not kneecaps (30:55)

If something would be a breaking change, then we label it with a breaking change. And it’s not something we can do right now. We can close it or postpone it or something. And then, you know, maybe three years from now, go and take a look at all the issues that are labeled that and say like, yeah, you know what, this would be worth breaking for. But at the same time, I’d love to not have to break people, even though, you know, the promise is only for three years. I’d love to not have to.

Did you just say break people? We did go back to the mafia reference, right? But no relation, right?

Exactly. Yeah. No breaking kneecaps.

Client middleware (32:12)

The other major thing is improving middleware. There’s all this stuff in tower, and it’s great. Like there’s Axum. You can use it to make really powerful servers. But the point of this middleware was actually that you could use it both ways. You could use it for servers, but you could also use it for clients. And that doesn’t work as well.

The most popular thing to use for clients is reqwest. And it doesn’t fit in to tower middleware. It has a bunch of extra stuff like redirects and some other things that it does. Various kinds of timeouts, which would be great middleware, but it’s currently all just wrapped up in reqwest.

And then also, if you even just look at the middleware in the first place, it’s like opaque. You have to understand how to do service discovery to then use load balancing. You have to understand how to build a retry policy before you can fit in retries and understand what is a retry budget.

It’s complicated. And it’d be nice if people could just get, hey, this is better for 95% of use cases. And if you really want to go and tweak your retry policy, sure you can. There’s the escape hatch over there.

But that’s my other thing to work on. Make reqwest and like Tower’s client middleware merge together a whole lot nicer so you can have much better stacked clients.

Retry storms and budgets (33:50)

Since there wasn’t a really easy plug-in, then people implement retries themselves. And that includes making themselves vulnerable to retry storms and just not doing it in a safe way. And the thing is that we have this middleware and things that would protect you from that, but they’re just complicated enough that people are like, ah, I can just retry in a loop.

But then you smash the server once things start falling apart. And it’d be so much better if you just add in a retry layer. It’s going to do things wisely. And maybe you say, you know what, on this URL, never retry it, but otherwise do the default thing.

It’d be so much nicer if you didn’t have to understand how bad retries can go.

If you just do a simple counter, then you might have counters at various layers. And maybe your counters aren’t shared. And now even though you’re trying to be nice to the server, you’re still retrying on thousands of times, whereas a shared budget or something would notice after a few retries, hey, the server’s overloaded. Let’s stop pounding it. Because as long as we keep trying, it’s never going to get back up. That’s one of the problems with retry storms.

The linkerd blog had a good post on how you can fix that using Tower middleware. But I’d prefer it if people didn’t have to read that to use it.

And plenty of other topics

Go have a listen, I hope you find it informative!

reqwest v0.12

Wed, 20 Mar 2024 08:13:00 +0000

Today marks the v0.12 release of reqwest, a higher-level, batteries-included HTTP client for the Rust language.

What’s new

The headline feature of reqwest v0.12 is the upgrade to hyper v1. reqwest does a lot of custom work to add features to hyper internally, but doesn’t need to expose too much of it publicly. This was what took the majority of the work to upgrade. Still, as outlined in the the hyper v1 announcement, the parts that are public have stabilized. The most obvious improvement to most users of reqwest will be the stable integration with http v1 types. This should remove the last blocker for a lot of people to finish upgrading to hyper v1.

With the breaking change, we made a few more improvements. Several optional features have been added which previously were required, such as http2 and charset. This allows disabling them and making the compilation time and size lower if not needed. We also converted all the implicit optional dependency features to dep: syntax.

We had to disable the HTTP/3 feature, but it was experimental anyways. It’s a goal to bring it back as soon as possible. We might also be able to add some other QUIC backends, such as s2n-quic.

See the release for more details.

Coming next

As mentioned a few times before on this blog, my focus next is to make a bunch of the powerful features in reqwest available as middleware. reqwest will remain easy to use. But it will be possible for people configure their own client stacks, without needed to fork or copy code. It will also mean even if you use the reqwest default easy stack, you can more easily integrate it with other tower middleware, such as retries or load balancing.

Thank you!

reqwest usage keeps on growing, and it’s both humbling and exciting to watch! For example, rustup uses reqwest as its default download backend, helping all Rust developers to keep their compiler up to date. Oxide uses reqwest in their Progenitor library that powers their OpenAPI clients.

Thank you for all your contributions, both in reporting issues, and in helping fix them. <3

If your company uses reqwest, consider becoming a sponsor. Additionally, for private advice, reviews, security help, and access to the maintainer, get in touch for support.

2023 in review

Tue, 16 Jan 2024 08:29:00 +0000

A year of change, and of stability. Let me briefly reminisce and highlight what happened in 2023.

Independent

I became an independent maintainer in June 2023. This was a somewhat scary decision, but it did exactly what I hoped it would: my work-life balance feels fantastic. I’m also glad to be able to do similar to what I did at AWS—meeting with and advising teams with serious deployments—but with a wider variety of use cases. (Send me an email if that interests you.)

hyper

First, some stats about hyper over the past year. There were 90 unique authors this year, which is 40% growth from 2022! We had two more people sign up to be triagers.

v1 🚀

We released hyper v1 in November. What a ride. It brought changes, moving the less stable side out into hyper-util. But it also signaled a core that won’t be changing any time soon. Stability.

The ecosystem caught up quickly. There were releases for tower-http, headers, and Axum ready to go just a couple weeks after. It enabled some other cool things, like the general availability of the AWS SDK for Rust.

We closed out the year with v1.1, bringing back core pieces needed to make graceful shutdown in servers easier again.

Security

I reviewed at least 10 security reports, perhaps a couple more I didn’t keep track of. This includes the wider HTTP/2 rapid reset attack that hyper wasn’t affected by. The amount of time I spend on security reports keeps on increasing. That makes sense, we announced stability of v1, which surely made more people take a look. It also is a sign of more production deployments, with companies wanting to audit their dependencies.

HTTP/3

Another priority this year was to make progress on hyper’s HTTP/3 support, currently under development in the h3 crate. We released some initial 0.0.1 releases (and a few more subsequent ones), specifically to make it easier for people to use. reqwest gained unstable HTTP/3 support, using h3, and some brave users have enabled it, found it working well, and are now asking if we can make it stable. A couple of other fine folks worked to make the h3-webtransport crate, building on top of h3.

Future Focus

Doing a bit forward looking, what’s the plan for 2024? Well, of course it could change at any moment, but these seem to be the things people most ask me for, and most need.

HTTP/3 in hyper

I hope to make significant progress towards getting HTTP/3 support directly in hyper. I’ll work on a proper proposal, but here’s some unordered steps in that direction. Stabilizing the feature in reqwest. Set up an auto-updating h3 server for interop testing. Dig away at the compliance report, both by labeling more of the parts already working, and adding any missing parts. Propose how to expose it in hyper, which will be tricky so as to not tie hyper to any specific TLS library. And then get it actually added, likely as a hyper_unstable_h3 feature to start.

Level up Client middleware

There’s a lot of great middleware now. But it can still feel like it requires an expert to use it properly. I’ve been hinting at for a while that I’d like to do for clients what Axum has done for servers. I hope to do that with reqwest.

reqwest does a lot of useful things, but if someone wants to customizing it beyond the options that reqwest exposes, they have to reimplement a lot (or live with a fork). I want to make most of reqwest’s features tower middleware. reqwest will still have a standard “recommended” client. But it should be easier to build up your own custom stack.

And while we’re at it, I hope to make some of the most important and yet most difficult middleware much easier to sprinkle in: retries, limits, and load balancing.

On-going maintenance

I also must carve out explicit time for maintenance work. There’s bugs that need fixing. Reviewing and triage takes a lot of my energy. I want to improve the docs and guides. The amount of security reports received is growing, and those take time to investigate and respond or patch and disclose, depending on their validity and severity. This also includes time with my sponsors, which helps identify maintenance work priorities.

Want to join us?

hyper v1

Wed, 15 Nov 2023 16:44:00 +0000

I’m excited to announce v1.0 of hyper, a protective and efficient HTTP library written in the Rust programming language. hyper provides asynchronous HTTP/1 and HTTP/2 server and client APIs, allowing you to bring your own IO and runtime.

It’s been exciting and humbling to watch users build awesome things. Cloudflare uses hyper within Oxy, its next generation proxy framework to handle traffic at considerable scale. After Discord’s 5x improvement to @mention response times a few years ago, they have moved most of their critical systems to depend on Rust and hyper. curl has a currently experimental HTTP backend built on hyper with the goal of making the Internet safer.

Marc Brooker, a Distinguished Engineer at AWS, commented:

When building our new container-loading data plane for AWS Lambda, we expected to need a custom binary protocol. In production, we’ve found the overhead of hyper to be SO low that we are excited for it to continue powering our services.

Johan Andersson, CTO at Embark, said:

We have been using and relying on hyper for the last 5 years for our gRPC and REST services, tools, libraries, and embedded in our next game built in Rust. It has been rock solid across all of our usages, and it really is a foundational library for the Rust ecosystem. Congrats on 1.0!

The best way to get started is to check out the guide.

Stability here we come

Over the past 9 years, hyper has grown from a web developer’s side project into a solid library powering huge network applications. It’s time to grow up. After bringing async/await support in v0.14, we focused on providing a set of basic APIs that would keep hyper safe, fast, and flexible. This meant removing some of the more opinionated “higher level” pieces. Those belong elsewhere, like hyper-util, reqwest, Axum.

This release signals some stability. Major versions, like 1.0, are stable for at least 3 years.¹ We also keep a MSRV that is at least 6 months old.² We’ll add new features, and we still have a couple places to experiment: in the hyper-util crate, and hyper_unstable compiler flags.

Starting in v0.14.25, we added a backports feature which brings the new core APIs to you immediately. Combine that with the deprecated feature, and you’ll be guided to making your existing code ready for the upgrade to 1.0. Be sure to check out the upgrade guide!

The most immediate next steps are to update the other core parts of the ecosystem that depend on hyper: reqwest, Axum, Tonic. But after that, there’s plenty more to do. You’re welcome to come join us!

HTTP/3

I would like this to be my next focus. We’ve been building up the h3 crate, and reqwest has unstable support now. I’d like to stabilize the feature in reqwest, and explore how we can make it available in hyper directly. Then we can have easy HTTP/3 servers, too!

The trickiest question is making it available without being tied to a TLS/QUIC library. Then, users could choose to use quinn, or s2n-quic, or msquic, or any other.

Stabilize in curl

The biggest parts of making hyper work in curl are done. Someone with experience in Rust and C could make a huge dent in Internet safety helping to get it over the finish line.

Middleware

There’s some excellent middleware available already in tower and tower-http. But several of the important ones are just a little (or a lottle) too difficult to add to a stack. I’d also love for there to be some recommended stacks for servers and clients, that bundle together the right middleware that most people would need. To that end, I’ve mentioned before breaking open reqwest such that all of its features are middleware you can customize.

Tracing and Metrics

It’s possible to currently get a decent set of logs using tower_http::trace. It’d be better if you could get more fine-grained traces and metrics. Probably with some stabilized integration with tracing directly in hyper. Maybe some sort of hyper-metrics, similar to tokio-metrics.

`io_uring`

Part of the reason we made hyper have its own IO traits was to be able to adapt them for completion-based IO. I believe having decent support and benchmarks could be had pretty soon, by a motivated individual.

Thanks

A huge thank you to all our amazing contributors. You’ve made this project the success it is, and helped move hyper along the journey to 1.0. I’d like to follow up with a separate post specifically thanking you all.

Thanks to the companies who have sponsored the creation of hyper: AWS, Buoyant, Mozilla, Rust Foundation, Fly.io, Embark and others.

Your company could also become a sponsor or get support!

Besides some correctness mistake that must be fixed ASAP. ↩
We realize that some users just cannot upgrade that fast, and we care about them. ↩

hyper HTTP/2 Rapid Reset Attack: Unaffected

Tue, 10 Oct 2023 15:07:00 +0000

Today, the world has been made aware of a potential vulnerability affecting most HTTP/2 implementations, sending a rapid amount of streams and resets.

If you use hyper, even just it’s h2 dependency, you are safe. hyper is not affected. Especially if you have h2 v0.3.18 or newer. We manually verified that an example hyper server responds correctly. Big thanks to @Noah-Kennedy for all the help.

If you want to read more, checkout CVE-2023-44487, or these other breakdowns.

That’s it!

You’re still here. You want to know the “why”?

Well, for two main reasons.

We added in specific detection of this problem back in April. A related flaw was reported against hyper, with the added requirement of a consistently flooded network. We fixed that. It had a CVE and RUSTSEC advisory for it, so you should have upgraded, right?

But even without that fix, the damage that could be done was local. The bigger concern of this newly announced vulnerability seems to be when the receipt of the HEADERS frame triggers more work in the handlers that needs to then be canceled. The way hyper handles frames, it will cancel out the stream before ever making it available for handlers, so the cost is local. Without the fix, and only if the user can flood the network, then hyper could consume a lot of memory keeping track of all the suddenly reset streams. If they can’t flood the network, then no problem at all.

So if you’ve upgraded since April, you’re safe. By the way…

Handling security by dealing with reports, and working with coordinated disclosures like today are a significant part of maintaining hyper. If you appreciate that hyper is kept secure, consider sponsoring. Being able to have more support during security disclosures is something that you can setup with me privately.

Was async fn a mistake?

Thu, 28 Sep 2023 16:58:00 +0000

This stabilization PR for async fn in traits made me think: was async fn in Rust a mistake?

I mean, I dunno. Maybe it wasn’t. But play along for a moment.

By the way, I don’t mean that async/await in Rust itself is a mistake. That’s a Big Deal. It allows companies to deploy some serious stuff to production. And async and await syntax is a huge save. I don’t want to lose that. Writing manual futures and poll functions is megasad.

I’m specifically talking about the async fn sugar. What if we didn’t have it, and instead just returned impl Futures, and used async blocks inside the functions?¹

The current async fn is really nice, if you fit the expected usage. If none of the differences with impl Future ever cause you problems, then great! But I do run into them. Other people seem to also.

What’s so bad?

Some of these differences cause problems that don’t have decent solutions. (Do you know the differences?)² If you have to deal with one of them, suddenly you need to use different syntax.

And now, people need to understand both. And keep the subtle differences in their head when they read. Does that make things better? Or worse?

It’s the only place that has a magic return type. It makes lifetimes weird. With suggestions to reign them in. It leads to all sort of proposals about how to customize the return type. #[require_send], async(Send), Service::call(): Send, and I’m sure there’s others.³ I also am thinking about generators and streams, since they could also end up with magic return values.

So was it mistake? I think it may have been. Don’t worry, I don’t want to take it away from you, if you disagree!⁴

What if the alternative was nicer?

But I did wonder about this. What if we had the following features ready:

Repurpose bare trait syntax to mean impl Trait. It’s been enough editions, right?
Ability to forgo naming an associated type name.
Stealing the feature from Scala where functions can equal a single expression.

Then asynchronous functions could look like this:

fn call(&self, req: Request) -> Future<Response> = async {
    // ...
}

That’d be a nice improvement.

Yea, I know, it’s a little more writing. But I am in the optimize-for-reading camp. We read much more than we write. So if I have to write a few more characters at a function definition, but it makes the reading experience more understandable, that’s a massive win. ↩
I’ve been involved in async Rust since the beginning. I know how it used to be, I was part of the group making it better, and I pay close attention to all the new proposals. I still mean what I said: none of the solutions look nice. ↩
Return Type Notation (RTN) syntax is probably the least gross. But it raises a bunch of questions. Does it work for all functions? If not, why not? If so, do I check I::Iter or I::into_iter(). And also to consider: Rust’s strangeness budget! ↩
I could see an argument that it’s sort of like for, while, and loop. A more convenient syntax when it works, and you can use the others when you need more control. That argument breaks down when async fn is part of a trait definition. But anyways, I really just want the less-sugared way to be little nicer. ↩

I'm an independent open source maintainer

Thu, 27 Jul 2023 15:00:25 +0000

tl;dr - I’m independent, sponsor me!

I’m doing something new. I’m an independent open source maintainer! In the beginning of June, I left my position at AWS.¹

I’m still focused on Rust, async, and HTTP stuff. Projects like hyper, reqwest, h3, tower, and any other new ideas that come along. I just won’t be doing so as an employee.

So, then how do I get paid? Let me just clear up a couple ways I’m not. I’m not making separate licenses. I’m not charging for features.² I’m not selling prioritization on roadmaps. Rather, I plan to make maintenance work my primary focus.

Maintenance can feel like riding a squared unicycle while juggling water balloons. Some of those balloons are:³

Designing proposals, interviewing users, re-writing those proposals.
Coding, coding, coding.
Triaging a never-ending supply of issues.
Spelunking in ancient code paths to understand and fix weird bugs.
Following a proper security policy with responsible disclosure, collaborating privately, and preparing detailed reports.
Reviewing pull requests for quality and sticking to the vision, and hopefully teaching potential collaborators.
Writing articles and giving talks, as a form of marketing and teaching.
Pretending to be a project manager.

It’s a lot of work, so who would pay for all that?

Does your company depend on my work? Become a sponsor! Consider it a form of business risk mitigation. You can use GitHub Sponsors or Patreon. I can also work with an invoice system, for any requiring that.

I am also interested in some deeper relationships with companies that want more. What exactly those relationships will look like will evolve. It would likely be things that look like office hours, support or private advice. If you want to explore that with me, reach out at [email protected]?subject=Sponsorship">[email protected].

I learned a lot from my 3 years at AWS. Many lessons, some anti-lessons. Overall, I’m very grateful for my time there. But I had been planning this change for a while. And it was quite refreshing taking off a few weeks before jumping back into it all. ↩
A win about being independent is that no single company is deciding what features should be added. ↩
This would be a good subject for another article. There’s a lot more to it, and it’d probably be surprising to people how many hats are needed to maintain popular open source libraries, besides “just being a programmer”. At least, if you want to do it well. ↩

seanmonstar

hyper Roadmap 2025

Open source is guiding

Focus Areas

A living document

Contribute

hyper in curl Needs a Champion

Why would you put a hyper in a curl?

Most of the work is done

Over the finish line

Champion required

hyper HTTP/2 Continuation Flood

What is the attack?

hyper’s h2 is somewhat affected

What we did

What you can do

Podcast: Rustacean Station, hyper 1.0, and independent maintainership

Sponsoring is not the Mafia (11:48)

Access to the maintainer / advising (12:50)

Breaking people, not kneecaps (30:55)

Client middleware (32:12)

Retry storms and budgets (33:50)

And plenty of other topics

reqwest v0.12

What’s new

Coming next

Thank you!

Sponsor and Support

2023 in review

Independent

hyper

v1 🚀

Security

HTTP/3

Future Focus

HTTP/3 in hyper

Level up Client middleware

On-going maintenance

hyper v1

Stability here we come

Next

HTTP/3

Stabilize in curl

Middleware

Tracing and Metrics

io_uring

Thanks

hyper HTTP/2 Rapid Reset Attack: Unaffected

Was async fn a mistake?

What’s so bad?

What if the alternative was nicer?

I'm an independent open source maintainer

hyper’s `h2` is somewhat affected

`io_uring`