I would like to measure the interest in a fork of Asio, proposed as a Boost library for review. Currently, Boost.Asio (and the standalone version Asio) is developed and maintained by Christopher Kohlhoff. Unfortunately he has a well-earned reputation for being unresponsive to emails and GitHub issues. For example: https://github.com/chriskohlhoff/asio/pull/904 I believe that Asio is Boost's most valuable asset, because "the C++ Standard cannot connect to the Internet." Every other language has portable networking built-in except for C++. Asio is the industry standard and the gold standard for portable networking, yet it is falling behind due to its lack of evolution. A major component of my revitalization plan for Boost is to promote Asio and build many great things on top of it. For example, clients and servers which speak MCP ("Model Context Protocol"), empowering users to easily connect and talk to AI endpoints (Large Language Models) using REST and JSON. Learn more about MCP here: https://www.pulsemcp.com/ In discussions with our staff engineers, there is a movement to propose a Boost.Crypt library with cryptographic primitives as an alternative to OpenSSL, with the goal of modern interfaces which eliminate broad categories of undefined behavior and usage errors which lead to vulnerabilities. Yet if Asio cannot adopt support for alternatives to OpenSSL we cannot evolve. The fork of Asio is just in the idea stage, no work has been done yet, and it is all open to debate and design. My thinking of how the fork would work goes like this: 1. C++ Alliance allocates dedicated staff to maintain the fork 2. Stakeholders come together, on the mailing list and through GItHub issues, to determine what directions we might like to explore or move towards 3. Dedicated staff implement the work and provide support for stakeholders 4. Changes in Asio would be adopted on an as-needed basis The first order of business would be to go through all of the GitHub issues in Asio and address them one by one. What do you think?
On 15 Aug 2025 21:14, Vinnie Falco via Boost wrote:
I would like to measure the interest in a fork of Asio, proposed as a Boost library for review.
Currently, Boost.Asio (and the standalone version Asio) is developed and maintained by Christopher Kohlhoff. Unfortunately he has a well-earned reputation for being unresponsive to emails and GitHub issues. For example:
https://github.com/chriskohlhoff/asio/pull/904
I believe that Asio is Boost's most valuable asset, because "the C++ Standard cannot connect to the Internet." Every other language has portable networking built-in except for C++. Asio is the industry standard and the gold standard for portable networking, yet it is falling behind due to its lack of evolution.
A major component of my revitalization plan for Boost is to promote Asio and build many great things on top of it. For example, clients and servers which speak MCP ("Model Context Protocol"), empowering users to easily connect and talk to AI endpoints (Large Language Models) using REST and JSON. Learn more about MCP here:
In discussions with our staff engineers, there is a movement to propose a Boost.Crypt library with cryptographic primitives as an alternative to OpenSSL, with the goal of modern interfaces which eliminate broad categories of undefined behavior and usage errors which lead to vulnerabilities. Yet if Asio cannot adopt support for alternatives to OpenSSL we cannot evolve.
The fork of Asio is just in the idea stage, no work has been done yet, and it is all open to debate and design. My thinking of how the fork would work goes like this:
1. C++ Alliance allocates dedicated staff to maintain the fork 2. Stakeholders come together, on the mailing list and through GItHub issues, to determine what directions we might like to explore or move towards 3. Dedicated staff implement the work and provide support for stakeholders 4. Changes in Asio would be adopted on an as-needed basis
The first order of business would be to go through all of the GitHub issues in Asio and address them one by one.
What do you think?
Have you discussed this with Christopher? Specifically, if it would be possible to collaborate or co-maintain Asio and/or Boost.Asio.
On Fri, Aug 15, 2025 at 12:12 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Have you discussed this with Christopher? Specifically, if it would be possible to collaborate or co-maintain Asio and/or Boost.Asio.
This is exactly the problem. Chris does not respond to emails, does not respond to GitHub issues, and has told me in the past that he does not like to interact on social media or in chat rooms. I have asked many times. This is a frustration shared by many. No, it is not possible to collaborate or co-maintain Asio with Chris. Kohlhoff works in high frequency trading firms, which implement valuable proprietary algorithms and require NDAs (non-disclosure agreements). Often he cannot talk about his methods, so keeping quiet is second nature. I believe that Asio for Chris is first a portable network library that he uses in his career, and second an open source offering for users. That is, that Chris evolves Asio in accordance to his needs at work and not in response to users, whose GitHub issues, email, and mailing list posts he simply does not see or read. Therefore, even if Chris was open to collaboration there are many design decisions which we may want to make that he might disagree with. For example, we may consider requiring a more recent version of C++. We might want to use `std::error_code` instead of `boost::system::error_code`. We might want design changes which help other Boost libraries interoperate yet conflict with his vision. All of this is solved with our own fork of Asio. Thanks
Em sex., 15 de ago. de 2025 às 16:36, Vinnie Falco via Boost <boost@lists.boost.org> escreveu:
We might want design changes which help other Boost libraries interoperate yet conflict with his vision. All of this is solved with our own fork of Asio.
If it's going to be a new library with a new design, it should go through the Boost peer review process. I don't know if your idea is going to be sufficiently different to warrant a new library that's mostly going to be an overlap of what Boost.Asio already does though. I'll chime in later with more points. In the meantime, is it my impression or am I the only person who still uses the mailing list asio-users? What should be the alternative for asio-users? Boost-develop or boost-users? I've been developing macros for Boost.Asio, and if they ever get in a state where I think they might be useful to other people, I was planning on announcing it in asio-users. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On Fri, Aug 15, 2025 at 1:41 PM Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
If it's going to be a new library with a new design, it should go through the Boost peer review process.
Yes to the review process, which is why I am first gauging interest. As for the "new design," I am not looking to innovate here. The fork would use the same interface principles as Asio and the same code, except for things that we want to modernize which would not be accepted in original Asio. The canonical example being the use of `std::error_code`. Where we would differ is that there could be support for things that Asio won't do, such as native Botan support for TLS. Or this WolfSSL which is alluded to in the neglected GitHub issue in the OP. I don't know if your idea is going to be sufficiently different to warrant
a new library that's mostly going to be an overlap of what Boost.Asio already does though.
I'm not sure it needs to be sufficiently different, other than having responsive developers and active support. This is why I am posting to the mailing list. Would a fork of Asio which keeps mostly the same interface, has enhancements desired by the community, and has updated documentation and ongoing support worth having as a Boost library?
I'll chime in later with more points. In the meantime, is it my impression or am I the only person who still uses the mailing list asio-users? What should be the alternative for asio-users?
Is asio-users a Boost mailing list? I don't use it. Given the decline in mailing list participation, I think we should try to consolidate all of our mailing list activity down to just a single mailing list (the developer's mailing list). The volume of user traffic is so low, that we should not complain about answering user questions in the developer mailing list. Robust technical discussion is the lifeblood of the Boost library collection and we need to nourish it. Thanks
El 15/08/2025 a las 23:55, Vinnie Falco via Boost escribió:
On Fri, Aug 15, 2025 at 1:41 PM Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
If it's going to be a new library with a new design, it should go through the Boost peer review process.
Yes to the review process, which is why I am first gauging interest.
As for the "new design," I am not looking to innovate here. The fork would use the same interface principles as Asio and the same code, except for things that we want to modernize which would not be accepted in original Asio. The canonical example being the use of `std::error_code`. Where we would differ is that there could be support for things that Asio won't do, such as native Botan support for TLS. Or this WolfSSL which is alluded to in the neglected GitHub issue in the OP.
I don't know if your idea is going to be sufficiently different to warrant
a new library that's mostly going to be an overlap of what Boost.Asio already does though.
I'm not sure it needs to be sufficiently different, other than having responsive developers and active support. This is why I am posting to the mailing list. Would a fork of Asio which keeps mostly the same interface, has enhancements desired by the community, and has updated documentation and ongoing support worth having as a Boost library?
Hi, Which is the plan to maintain the new features that Asio will get over time? I've not followed Asio evolution, but I guess more features are being added in newer versions (there are some experimental features mentioned in the library documentation). Having support for other SSL libraries (MbedTLS also comes to my mind) is a nice feature. Reducing dependencies to the minimum is also a good feature, although I've seen that the weight of the library has been considerably reduced in the latest Boost releases. If understand the proposal correctly, if the fork passes the review, then we would have 2 networking libraries inside Boost (Boost.Asio + Boost.ForkedAsio)? Best, Ion PS: Building "great things" above a networking library also includes something like Boost.Curl, the C++ swiss army knife for internet protocols?
On Fri, Aug 15, 2025 at 5:20 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
If understand the proposal correctly, if the fork passes the review, then we would have 2 networking libraries inside Boost (Boost.Asio + Boost.ForkedAsio)?
Yes, exactly. The API of ForkedAsio would closely follow Boost.Asio, and it would pick up changes from Asio. Thanks
El 16/08/2025 a las 5:06, Vinnie Falco via Boost escribió:
On Fri, Aug 15, 2025 at 5:20 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
If understand the proposal correctly, if the fork passes the review, then we would have 2 networking libraries inside Boost (Boost.Asio + Boost.ForkedAsio)?
Yes, exactly. The API of ForkedAsio would closely follow Boost.Asio, and it would pick up changes from Asio.
Thanks
We have previous experience of having newer versions of a library (Coroutine2, Hash2, Lambda2, Signals2, Variant2), but I think in many of them the API was changed o support newer features or standards. They are in practice, greenfield re-implementations and/or variations. On the other hand, having a lot of newer and shinier features would make Boost.Asio2 more attractive to Boost but it would make tracking the original library increasingly difficult. If we think we can't do it better than Chris, then I don't know what could be the correct path forward. Are networking programmers comfortable with the Asio API or we would like to change the API to make use of newer C++ features? I've read comments from some programmers disliking the Asio interface (the old one and also the interaction with C++ coroutines) but I haven't seen a mature, better alternative yet (and exploring a new API is out of you proposed Boost.ForkedAsio proposal). Best, Ion
Vinnie Falco wrote:
For example, we may consider requiring a more recent version of C++. We might want to use `std::error_code` instead of `boost::system::error_code`.
Chris already uses C++11 in Asio but has deliberately retained system::error_code. Dropping it will lose the error locations.
On 15 Aug 2025 22:34, Vinnie Falco wrote:
On Fri, Aug 15, 2025 at 12:12 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Have you discussed this with Christopher? Specifically, if it would be possible to collaborate or co-maintain Asio and/or Boost.Asio.
This is exactly the problem. Chris does not respond to emails, does not respond to GitHub issues, and has told me in the past that he does not like to interact on social media or in chat rooms. I have asked many times. This is a frustration shared by many. No, it is not possible to collaborate or co-maintain Asio with Chris.
Incidentally, I recently received a PR from Christopher for Boost.Log[1], to reduce the dependencies caused by Boost.Asio. Which was an issue I reported in Asio[2] not long before. So clearly he does monitor issues and responds by action, where he sees fit. My concern with the proposed fork is the longevity of the project. I agree with Peter that it would be increasingly difficult to maintain, with little practical effect (other than better documentation, I guess). We may end up with unmaintained fork that is incompatible with the main library, which is no longer accessible to Boost libraries (other than as an external dependency). I don't see switching to std::error_code as a big deal, but maintaining this change will take resources that are better spent elsewhere. As for adding support for other cryptography libraries, is it not possible to that externally? I don't work with Asio very often, but from what I remember, the SSL part of it is quite separate from its core. It should be possible to write similar wrappers for other crypto libraries, if needed. Maybe you should consider a new Boost.AsioEx library that hosts such Asio extensions instead of a fork. [1]: https://github.com/boostorg/log/pull/249 [2]: https://github.com/chriskohlhoff/asio/issues/1637
On Fri, Aug 15, 2025 at 6:53 PM Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:
The more I read issues and PRs on asio, the more I understand Chris' policy.
Chris policy is: 1. Not to participate on the mailing list 2. Not to respond to emails 3. Not to engage in discussion with stakeholders 4. Not to respond to GitHub issues The number one portable C++ network library is often giving users a bad experience. We can do better.
Could you elaborate on what kind of evolution you would like to see.
Yes. More examples. Better documentation. Requiring newer versions of C++ and using more standard types.
Why couldn't boost.crypt just implemen It's own crypt-stream type like botan does?
It could. This doesn't solve the stated problem, which is that the Boost networking library that many other libraries depend on (Redis, MySQL, Beast, http-io, websocket-io, cobalt) has an author who is unresponsive to users, unresponsive to emails, unresponsive to the mailing list, and unresponsive to GitHub issues.
That would be design by committee. A lot of stakeholders have input through Chris being part of the industry and they would never participate in an open discussion.
Right, and the design that I am referring to has to do with cosmetic things such as which error code to use. We would not be innovating on the networking API and smarts. Instead we would track the upstream repository. We could however have more examples. Better documentation. And most importantly we could control the GitHub issues and respond to people who open the issues. Even if all of the opened issues are garbage as you imply, then we could explain why they are not actionable and actually close them. This way new visitors to the repository do not see an unmaintained project.
4. Changes in Asio would be adopted on an as-needed basis
And who determines what is needed?
We have to figure that out. Likely we would just track everything.
What do you think?
Horrible idea. Greenfield one to compete with asio and motivate chris to add them this way.
You are suggesting that we create a new networking library from scratch. In my opinion, this is foolish. Chris already did the bulk of the work, and we would be throwing that out. I do not think I can do better than Chris. And I am certain that you cannot do better than Chris. A greenfield solution would be inferior. Furthermore, based on my observations of Chris over 8+ years, he is not the kind of individual who would be "motivated to add them this way." Quite the opposite he would probably be relieved that an alternative exists and he might actually just stop maintaining the Boost version of Asio (which is not used in the HFT systems he works with). Thanks
Vinnie Falco wrote:
Right, and the design that I am referring to has to do with cosmetic things such as which error code to use. We would not be innovating on the networking API and smarts. Instead we would track the upstream repository.
That's going to be a maintenance nightmare. Not impossible, but would take quite a bit of effort from highly determined individuals and the job will get harder and harder with time as the two repos diverge.
Klemens Morgenstern wrote:
https://github.com/chriskohlhoff/asio/pull/904
Have you looked at the PR? It is a build script change for a header only library. The author gives no reason why this is needed or any indication that this works.
The PR is a fix for a previously accepted PR, which has been applied incorrectly.
participants (6)
-
Andrey Semashev -
Ion Gaztañaga -
Klemens Morgenstern -
Peter Dimov -
Vinnie Falco -
Vinícius dos Santos Oliveira