Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add target for mautrix #56

Open
kegsay opened this issue Apr 29, 2024 · 4 comments
Open

Add target for mautrix #56

kegsay opened this issue Apr 29, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@kegsay
Copy link
Member

kegsay commented Apr 29, 2024

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

@kegsay kegsay added the enhancement New feature or request label Apr 29, 2024
@tulir
Copy link
Member

tulir commented May 2, 2024

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
Copy link
Member

tulir commented May 2, 2024

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
Copy link

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

@kegsay
Copy link
Member Author

kegsay commented Jul 12, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants