Hi Steve, Thanks for your message, and for the pointers. I spent some time in the Http repository, and the overlap is clear. The router, middleware, CORS and static file support cover much of what taar does below the handler layer, and Http goes further on content encoding and conditional and range requests. To answer your question, the upper layers depend on Beast mostly for vocabulary, not for I/O. The binding layer, JSON-RPC, MCP and OpenAPI use Beast's request header, fields, verb, status and string_body/response types, plus asio::awaitable for coroutine handlers. The parts that really need Beast and Asio are the session and the TCP server, which are the parts Http and Beast2 already cover. From a first read, a taar handler could sit behind a route_task adapter. rest(f, path_arg("id"), json_body_arg()) would read route_params::params and req_body, convert the arguments, call f, and write the result to res. The work on my side would be to abstract the message types taar uses for argument extraction and response generation, and to support capy::task next to asio::awaitable for asynchronous handlers. I also noticed that dynamic_invoke resolves arguments by type from a polystore, while taar binds each argument by source and name (path, query, header, cookie, body). The two seem complementary rather than overlapping. My current plan is to take taar to review on Beast and Asio, since both are established Boost libraries. I would like to keep the protocol layers separable enough that an Http backend can follow without changing user code. Does that fit with how you see Http and Beast2 evolving, and do you have a rough timeline for Http's review? I will join #boost-corosio on Slack. Regards, Reza