Question: HTTP client (TLS-capable) on the roadmap?

[PeterXMR]

The web examples (examples/web-response.0, the Response.text(...) API, the zero routes --json command) show a clear server-side HTTP story — pub fun GET(request: Request) -> Response, Next.js-style routing. What's not clear from the README, examples, or the docs-site articles I've looked at is whether there's an HTTP client primitive either today or planned.

Concretely: for the use case of a native CLI / tool that calls a few third-party REST APIs over HTTPS, parses JSON responses (great that std.json is already in stdlib — examples/std-data-formats.0), and aggregates the results, is the intended path:

1. There's already a std.http.client.get(url)-ish thing in the stdlib that I missed scrolling through the examples?
2. It's planned but not yet shipped — even rough timing ("weeks vs months vs not yet on the roadmap") would help me decide whether to wait or plan around it.
3. The recommendation is to FFI out to libcurl (or similar) via the examples/c-interop/ pattern.
4. The web stack is intentionally scoped to server-side only for the foreseeable future — a totally reasonable scoping choice given the Vercel-edge use case; just want to know explicitly.

Asking because I'm evaluating Zero as a possible re-implementation target for the pure-math / parsing pieces of a small Bitcoin price viewer (Kotlin Multiplatform UI + Rust core today: https://github.com/PeterXMR/spotprice). Whether the HTTP-client piece exists determines whether porting the network-facing modules is in scope, or whether Zero is the right fit only for the math / aggregation pieces (which I'd port regardless — core/convert/ and core/aggregator/median.rs look like a good fit for typed effects + choice + generics).

I noticed #20 covers structured concurrency separately, so I've kept this issue focused on just the HTTP-client question — happy to keep the concurrency discussion there.

If there's a roadmap doc or design discussion thread I missed, a pointer is fine. Thanks for putting Zero in the open; the examples have been a good read regardless of where it lands for my use case.

[PeterXMR]

Following up on my own question — I went digging through the repo, docs, and web while waiting, in case it saves a longer answer. Posting what I assembled in case it's useful as a reference for others landing on this issue via search.

What's documented today (v0.1.1)

The std.http and std.net modules ship type scaffolding only:

• docs-site/articles/modules/http.md: "std.http currently exposes parsing and hosted metadata helpers. It does not provide a request/response runtime in the current public surface." Exposed APIs are parseMethod, client(net) (returns hosted client metadata), server(net, addr), bodyLen, and tlsBoundary() which returns the literal string "platform-or-c-library".
• docs-site/articles/modules/net.md: "std.net exposes network capability metadata and bootstrap handles. It does not provide socket read/write APIs in the current public surface." connect(...) / listen(...) are declared but return Maybe<Conn> / Maybe<Listener> with no usable concrete type today.
• The conformance test conformance/native/pass/std-net-http-breadth.0 passes when conn.has == false && listener.has == false, and the benchmark benchmarks/zero/networking.0 does the same — the bootstrap is wired to return "absent" everywhere it's exercised.
• CHANGELOG 0.1.1: "Removes placeholder module docs that described surfaces not ready for users and adds current module docs for std.crypto, std.http, and std.net" — i.e. deliberate replacement of aspirational docs with honest scaffolding-only docs.
• No std/http or std/net source files under compiler-zero/ or native/zero-c/ — stdlib is compiler-resident.
• No example anywhere makes an outbound HTTP request; Request/Response only appear as server-side handler types in examples/web-response.0 and examples/web/hello/src/routes/index.0.
• No open or closed PR mentions adding an HTTP client runtime.
• Network is not yet listed as a target capability in docs-site/articles/target-capabilities.md (only args/env/fs/memory/stdio appear).

Provisional mapping to the four options in the issue body

• (1) Already exists, I missed it — ruled out by the docs + conformance test.
• (2) Planned but not yet shipped — most likely. The published type surface (client(net) → HttpClient, connect(...) → Maybe<Conn>, tlsBoundary() → "platform-or-c-library") reads as intentional pre-publication of the eventual runtime's shape, not as deprecated stubs.
• (3) FFI out to libcurl via c-interop — implied recommendation for today. tlsBoundary() returning "platform-or-c-library" is the maintainers' own architectural hint that TLS is intended to come from outside the language. examples/c-interop/ has the wiring pattern (src/, vendor/, zero.json) but no HTTP-specific example.
• (4) Server-only by design — ruled out by the very existence of std.net.connect / listen and std.http.client(net) scaffolding.

So provisional answer: (2) is the real state, (3) is the today-workaround, with no public timeline that I could find.

Three questions a maintainer answer would still unblock

1. Is there a target version or milestone tracking the std.http/std.net runtime? Even at the resolution of "weeks vs. months vs. no concrete plan yet" would help external evaluators.
2. Is the intended TLS source platform-native (Android NSC, Apple SecTrust on those targets) or BoringSSL-via-libcurl, or both per-target? tlsBoundary() says "platform-or-c-library" but doesn't specify how that resolves per --target.
3. Would a worked example under examples/c-interop/ showing the libcurl-bridge pattern for an outbound HTTPS GET be welcome as a PR, or would you rather hold off on that until the real runtime lands and avoid people building around the FFI path?

No rush — happy to leave this issue open as a "current state of the HTTP client" reference for others while you triage. Related: #5 ("generateText primitive") implicitly depends on the same answer about whether model access piggybacks on a general HTTP client or is its own capability.