Please fake a Matrix Server

[Mannshoch]

Describe your request

Currently, GSConnect use it's own message tool.

Proposed solution

Please fake a Matrix server, so you could use messages with the currently installed Matrix client like FluffyChat.

Alternatives

No response

GSConnect version

55

Installed from

GNOME Extensions website

GNOME Shell version

44

Linux distribution/release

Ubuntu 23.04

Additional context

No response

[ferdnyc]

Let me be blunt: The likelihood of this happening is extremely low.

...Wait, no. Turns out, that was the diplomatic version. The blunt version is: There isn't a chance in hell of this happening.

There are various reasons, some related to the GSConnect project, others related to Matrix specifically. (Some of which I was unaware of, myself, until I did the requisite half-hour's worth of due diligence on the technical feasibility of this request.)

I'll detail those, at least briefly, for the record in case this proposal ever resurfaces. But first, I'm going to move this to Discussions, as it isn't an actionable Issue at present. (Or, like I said, likely ever.)

[ferdnyc]

So, here are the barriers to making this any sort of reality:

GSConnect project

The GSConnect project is in community-supported mode. There are no "project developers" per se, and while we (the maintainers) are doing just that — maintaining the extension — any significant development effort needs, first and foremost, someone committed to doing the work.

But in this case, that wouldn't really help (or at least, they'd fail)... because:

Matrix {system, APIs, protocol, servers}

A matrix server — actually, a Matrix homeserver — is an incredibly complex beastie. It's not the sort of thing you "fake".

While the Matrix project makes a very big deal of how easy they make bridging Matrix to other services, they mean exactly that: Building Application Service gateways between other services/protocols and a full Matrix Homeserver implementation. But any such bridges still require a homeserver to bridge to, which of course GSConnect could not provide.

To even build a GSConnect bridge to the Matrix network would require implementing large portions of their APIs, including authentication and encryption, so that a user's text messages could be exchanged securely on the federated Matrix network. And it would require that the user be okay with us putting their private text conversations onto the Matrix network, which... hell, I wouldn't be! That just sounds foolhardy on the face of it.

Matrix clients

All of this hinges on a rather... surprising design decision made by the Matrix project:

Matrix clients are SINGLE-SERVER by design

When they say "homeserver", they mean just that — emphasis on home server. The design of the Matrix system requires that a client have a single server "home" to which it signs in and accesses the entire network. From their FAQ:

A user's client connects to a single homeserver, which stores the communication history and account information for that user, and shares data with the wider Matrix ecosystem by synchronising communication history with other homeservers.

Oh, sure, you can access services at as many remote Matrix servers as you like, but you do all of that through your homeserver, over the network using (behind the scenes) Matrix's server-to-server APIs.

Which means that a Matrix-bridged GSConnect would require a server not only compatible with their Application Service (bridging) API, but also their server-to-server protocols. It wouldn't actually have to support client-server, unless it was going to act as a homeserver as well, but that's small consolation.

Additionally, Matrix clients support a number of features above-and-beyond the ones available to KDE-Connect-relayed device SMS, many we don't support, and several we couldn't support even if we wanted to — but at least in some cases there'd be no way, AFAICT, to communicate to the client that we can't accept messages using those features and it therefore shouldn't use them.

At issue are things like:

1. End-to-end encryption. This one, we could actually "shut off", simply by not enabling it in any of the Matrix "rooms" GSConnect is bridged into. At issue is the fact that E2E requires a compatible Matrix client on both ends of the connection — the server isn't supposed to be able to examine any of the message content, so we'd have no way to turn E2E-encrypted messages back into KDE Connect SMS transactions. That server-opaqueness is what makes Matrix's E2E so secure, but it's also what requires a compatible client on both ends of the connection.

2. Message attachments. Matrix clients have the ability to insert all sorts of out-of-band content into messages they send using the protocol. Even for text-based things like spoilers, the official advice of the protocol specification is:

   clients are strongly encouraged to first upload the text containing spoilers to the media repository, then reference the mxc:// URI in a markdown-style link

   So a Matrix client, by design, constructs messages from not only their bare text content, but also a whole host of potential "attachment" uploads that go to the Matrix "media repository", a separate service running on the homeserver that accepts uploaded data for out-of-band incorporation into message events. This, as I'm sure you can imagine, greatly complicates the process of translating between Matrix events and a potentially-bridged service like GSConnect's SMS plugin.

There are also desirable features the clients don't support, like:

1. Message-length feedback/controls. Many SMS client interfaces provide a character counter when composing messages, indicating how the content will be split up if sent using the basic/legacy 160-character (or 70-Unicode-glyph) SMS protocol. GSConnect's messaging interface doesn't currently support this, but it could. No Matrix client does, AFAICT.

2. Non-contact messaging. GSConnect can send a text message to anyone, even someone not on your contacts list, simply by entering their phone number as the recipient. It's not clear that a Matrix bridge could provide similar functionality; messages are sent to a "room" (and person-to-person communications can be established by creating a private, invite-only "direct chat" room), but that still requires that the recipient identity be known to the server/bridge.

The notion of using established client implementations for GSConnect messaging is an intriguing one, but comes with its share of hurdles to overcome. And Matrix, specifically, appears to be an especially poor choice for any such functionality, due to its single-homeserver design.

[ferdnyc]

P.S> There are already several Android SMS <-> Matrix bridges available:

• https://matrix.org/docs/projects/bridge/sms-matrix
• https://matrix.org/docs/projects/bridge/android-sms
• https://matrix.org/docs/projects/bridge/matrix-sms-bridge
• https://matrix.org/docs/projects/bridge/matrix-texting

So if that's your bag, in theory you don't need either GSConnect or KDE Connect, to make that happen.

[Mannshoch]

wow, Thanks for your very detailed feedback.
My simpl thinking was, I use Matrix, I have several accounts it works great. Why not also send SMS over this nice Matrix client.

👍 Now I know how complex this simple idea is.

best regards