I've noticed that the distinction between server and client is much less apparent in HTTP2 libraries than it was in HTTP1 libraries. It doesn't seem like Mint follows this philosophy, but many HTTP2 libraries (even ones that also support HTTP1) are both server and client libraries.

Presumably this is because HTTP2 is sort of two protocol layers stuck together—a session layer and an application layer—and at the session layer, HTTP2 just has identical "peers" rather than any concept of client/server. (Theoretically either side of an HTTP2 connection could open a session to the other side and send a message! It's just the semantics of the HTTP-mimicking application layer that stop this. If you read the RFC, all the session stuff—frames et al—are specified in terms of "peers", and it's only when the spec starts talking about HTTP request-response that we see "clients" and "servers" mentioned.)

Since implementing the session layer is most of the work of implementing an HTTP2 client/server, and the session layer is just about "peers", once you've implemented it for a client (or server), you can reuse it to implement a server (or client) mostly "for free."

It's a "new HTTP client" (tweet from one of the authors -> https://twitter.com/whatyouhide/status/1100082898986774528).

The example is confusing, but it's actually an HTTP client.

In the Erlang world... it's always yet another client.

So, it's the former (client library).