Add target for mautrix

[kegsay]

We have an entire ecosystem relying on https://github.com/mautrix/go for cryptography for bridges. It does not use rust SDK FFI or JS SDK, instead rolling its own SDK layer.

As a result, we lack confidence it doesn't have bugs which can cause UTDs. We should add a new m target which will drive mautrix, similar to how we have j for js-sdk and r for rust SDK FFI.

xref element-hq/element-meta#2387

[tulir]

Looks like most of the bugs are just NSE on iOS, but we'd be happy to help with adding mautrix-go as a test target anyway since Beeper is going to be leaning heavily on Go. All Beeper clients will switch to mautrix-go in the near-ish future and the remaining Python bridges are going to be rewritten in Go as well.

[tulir]

Also, mautrix-go has a pure Go implementation of Olm, having tests would be useful for finding bugs in that. Right now go-olm is definitely not production-ready, but eventually we want to make it good and get it audited to drop the libolm dependency (cgo isn't nice)

[cvwright]

Very cool! What would it look like to add something similar for https://github.com/futo-org/matrix.swift ?

[kegsay]

Calling Swift from Go is a bit of pain. However, you did give me a good idea.

Part of this test suite involves sending kill signals commands to clients to terminate them ungracefully. We couldn't do this easily for Rust FFI bindings as its in the same process as the test host (unlike JS where you can just kill the browser PID). The API had several designs to try to address this, starting with Go templates and ending in its current incarnation, which implements a net/rpc client and server. The idea is then you can kill the RPC server ungracefully.

The idea you just gave me is that this is literally one step away from providing a wire format for the client interface. By default, net/rpc uses gob encoding, but it can be configured to use the much more standardised JSON-RPC protocol. If we did, then you would just need to write a binary in any language which:

• listens on any port and prints it to stdout,
• receives JSON-RPC traffic over HTTP,
• and implements whatever that RPC is.

This could be in Swift for example. You wouldn't need to do an RPC client as we already have that.