…the ability to authenticate connections via classic SSH keys (mutual TLS is supported too of course).

The bridge can be used to expose local Varlink services to remote peers via HTTP, opening up those services to the HTTP world. But sometimes the other direction is useful too: i.e. being able to access remote Varlink services exposed via HTTP via sd-varlink + varlinkctl. With v260 that's easy to do: if you specify a Varlink service not via an AF_UNIX socket path, but via an HTTP URL…

…then sd-varlink/varlinkctl will fork off /usr/lib/systemd/varlink-bridges/http (and analogue for https, or any other protocol scheme), and communicate through it.

In fact, Michael's bridge implements this client side too, and hence after installing it, you can do stuff such as:

varlinkctl call httqs://my.web-server.com:8080/ws/sockets/io.systemd.Hostname io.systemd.Hostname.Describe {}

and the right thing will happen. (I replaced a p with a q in the above, to trick Mastodon's formatting.)

@pid_eins

the `more` support and keeping connections open can easily be implemented with just native HTTP without having to switch to websockets. Doesn't even have to be SSE. Can just be a response that streams its results and splits the stream by NUL byte.

The varlink semantics of queuing multiple requests and the need for responses to come back into the same order as requests makes it behave basically the same semantics as HTTP 1.1

Map each HTTP path to a varlink method call. And map the parameters to the request body

Then simply stream back the reponse of the varlink call back over the http connection. If the varlink response streams multiple answers, just keep the http connection open

Here is an example that reuses the same varlink connection over multiple HTTP calls; works fine!

I really don't see the need for websockets here

Here's a demo in a few lines of go:

https://gist.github.com/arianvp/314113d4309c7d7d3047535e167352ac

@arianvp so the bridge supports both the ws and the non-ws mode iirc. @michaelvogt please comment.

(the other reason why ws is sometimes nice, is that varlink knows a concept of upgrading protocol, i.e. just being something to set up a connection and then switching to something else)