The main pain points for us were: thread-safety issues (httpx claims to be thread-safe but we hit race conditions in production), no HTTP/3 support, and the redirect behavior requiring explicit opt-in everywhere. Also the multiplexing story in httpx is quite limited compared to what niquests offers out of the box. On top of that, httpx maintenance has been slow to acknowledge valid bug reports, the thread-safety issue took over a year to even be acknowledged...
The switch was surprisingly smooth. I think there's an official migration guide in the doc. Honestly the API is closer to the classic requests library so nobody will be lost.
Thanks for the thoughtful feedback, grenran. You're right that domain ownership is the gold standard for digital sovereignty. We considered it, but realized it creates the exact complexity we're trying to eliminate: DNS management, registrar renewals, deliverability issues, etc. That said, your point about lock-in is valid. Here's our thinking: Portability matters. Your emails are yours. You can export everything via IMAP anytime, no artificial barriers. If you leave, you take your data. We're not gatekeeping your identity. We're providing infrastructure. Think of it like renting an apartment vs. buying a house, both are valid, and renting doesn't mean your landlord owns your furniture. For power users who want domain ownership, you're probably better served by Fastmail, Migadu, or self-hosting. We're not trying to replace those. We're targeting people who just want firstname@lastname.re without learning what an MX record is. The tradeoff is real: simplicity vs. full ownership. We chose to optimize for the 95% who want email to "just work." But we hear you, and we're exploring options like letting users transfer their address to their own domain if they ever want to graduate to full control. Would that kind of "graduation path" address your concern?
