add Wasmtime RPC RFC

[rvolosatovs]

Refs bytecodealliance/wasmtime#7348
Refs #39 (comment)

Rendered

[bjorn3]

It seems like this wouldn't allow using multiple plugins at the same time. Only a single plugin exposing multiple interfaces. Maybe a syntax like -P import=wasi:keyvalue=wrpc+tcp://[::1]:7761 -P import=wasi:nn=wrpc+unix://run/user/1000/wasi_nn.sock would work?

[rvolosatovs]

Definitely open to suggestions here, I struggled to come up with a design, which would not feel overloaded and as I mention in the open questions section, I've decided to start with a singleton plugin because of the CLI design concerns and the fact that shared state (e.g. resources) gets increasingly more tricky as number of plugins grows.

Perhaps we would just need to come up with wasmtime.toml-or-similar config file eventually, which would define the mapping, since mapping every single interface to an endpoint on the CLI feels quite tedious if the number of interfaces is large.
On the other hand, that's probably not much worse than the likes of:

docker run -v$path:$path -w$path

so perhaps endpoint per-interface is fine at least to start with

[bjorn3]

If a default port is used, should it be registered with IANA? And what should the default be for unix domain sockets? /run/user/<uid>/<package_name>.sock?

[rvolosatovs]

I chose 7761 pretty arbitrarily, if this RFC is accepted and we're happy with this number, IANA registration sounds like the right thing to pursue.

In terms of the UDS path I guess we'd need to first determine if we want plugins to be composable or if we want it to be a singleton. If we go the multiple-plugins route:

$os-specific-runtime-dir/wrpc/wasi/$name.sock

e.g.

/run/user/$uid/wrpc/wasi/http.sock
/run/user/$uid/wrpc/wasi/keyvalue.sock
/run/user/$uid/wrpc/myorg/mypackage.sock

seems like a reasonable default for wRPC-based plugins on UDS.

[bjorn3]

How is authentication handled? Would it require a CA certificate or are self-signed certificates allowed?

[rvolosatovs]

Depends on the implementation, ultimately wasmtime CLI user would be the one to decide. One thing to note though is that in current implementation, SAN is (ab?)used to specify the function being called: https://github.com/bytecodealliance/wrpc/blob/628e6bf79416ca2671d0a3c79ac25949f9bf84d8/crates/transport-quic/src/lib.rs#L29-L42

Currently, self-signed or not, the server (plugin) needs to generate a cert with appropriate SANs.

This can easily be changed/made configurable to e.g. be specified in the stream header as done for e.g. TCP and UDS https://github.com/bytecodealliance/wrpc/blob/628e6bf79416ca2671d0a3c79ac25949f9bf84d8/crates/transport/src/frame/conn/client.rs#L33-L43
I feel like being able to sign served plugin capabilities may come in quite handy, but I don't have strong feelings about this

Update: wRPC transport will reuse a singular QUIC connection for calls and open a bidirectional stream per invocation: bytecodealliance/wrpc#445

Wasmtime would be free to choose the connection strategy. I think the default should be enforcing that the plugin cert is signed by either know CAs from OS cert pool or, perhaps, webpki. E.g.: https://github.com/wasmCloud/wasmCloud/blob/a0e816316573e01e166e0a8366203a5ba8f7f1e5/crates/core/src/tls.rs#L55-L66

Users would probably need to be able to also specify custom CA and certs on command line though and optionally enable --insecure, which would allow self-signed certs

[bjorn3]

The only option that would allow backward compatibility on the Wasmtime side I think would be to make plugins shadow builtin implementations.