14:54 <kentonv> capnproto 0.8 release: https://capnproto.org/news/2020-04-23-capnproto-0.8.html

14:54 <JacobWeisz[m]> Woo!

17:21 <abliss> http/1.1 over capnp seems exciting. Could we replace httpGet in hack-session with a proper http proxy living inside the grain? it could tunnel all requests over capnp through sandstorm, with powerbox requests to auth new hosts? any hope for supporting http/2 and/or websockets?

17:46 <kentonv> abliss, HTTP/1.1 and HTTP/2 are different encodings of the same semantic protocol, so http-over-capnp is an alternative to both. But KJ doesn't have an HTTP/2 implementation so currently to proxy from HTTP/2 to Cap'n Proto would require two proxies, first to HTTP/1.1 and then to capnp

17:50 <kentonv> as for replacing Sandstorm's alternative HTTP-over-RPC protocol... maybe. The nice thing about Sandstorm's protocol is that it pulls apart the semantics of HTTP so that it's not a bag-of-headers. That's useful for sandboxing because we can be thoughtful about what features the sandbox is allowed to use. If we switched to the more general bag-of-headers protocol then we need to accomplish the same thing through header whitelisting, and sometime

17:50 <kentonv> s rewrites, which feels messier... but maybe less cognitive overhead?

17:50 <kentonv> of course, we'd still have to support the old protocol forever as well...

18:00 <simpson> This new work seems like something that's easier to implement in other runtimes. I'm still not sure how I'd approach using Sandstorm's HTTP-over-RPC encoding ala carte.

18:00 <simpson> Or do I mean "ala mode"? Whichever one doesn't have whipped cream.

19:55 <isd> Some of this has been talked about before, but a big downside of the way web-session works is that it's hard to get existing http libraries to talk to it. By contrast, it would be fairly easy to write a wrapper for http-over-capnp so you could e.g. use any python wsgi app without modification

19:56 <isd> But I agree with kentonv's assesment re: advantages for the folks implementing the sandbox.

19:56 <isd> It's a bit of a shame that we're exposing that to app developers though.

19:58 <isd> It might be neat to experiment with an alternative to sandstorm-http-bridge that wraps apps in a membrane and catches calls to the web-session methods, converting them to capnp-over-http.

19:58 <isd> So apps could use something with less of an impedence mismatch with their http libraries, but not have to have an extra layer of indirection for the rest of sandstorm's capnp apis.

20:00 <isd> This blog post is worth a read: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

20:01 <isd> It's framed in terms of PL-level static types and talking about Haskell specifically, but what she's talking about is not far off from the design principles behind web-session I think.

20:14 <isd> Relevant issue: https://github.com/sandstorm-io/sandstorm/issues/3174

20:15 <isd> simpson: mode has ice cream

20:23 <isd> I guess another possibility rather than a membrane that catches calls to web-session methods directly, we could catch calls to UiView.newSession, and if the session type is WebSession or ApiSession, we call out to the app with an alternate session type, wrapping the result.

20:27 <isd> abliss: re: a proxy inside the grain, the bridge does this already for powerbox-acquired http targets. Really we want to get rid of httpGet (and everything else in hack-session.capnp), and have everything go through the powerbox