There is a corresponding chatmail relay PR that adds the ability to connect to chatmail relays over WebSocket: chatmail/relay#1030
As a first step to make it usable, we need core to support connecting over WebSocket.
First, need to extend "socket security" enum that already has Ssl (implicit TLS) and Starttls (STARTTLS) with a new "WebSocket" variant.
Then, login parameters (entered by the user in advanced settings) needs to be extended with a websocket path, likely right after the port:
|
/// Server port. |
|
/// |
|
/// 0 if not specified. |
|
pub port: u16, |
It is not going to be used (and probably should not be accepted) if socket security is not set to WebSocket.
Configured parameters should be extended similarly here:
|
/// Server port, zero if unknown. |
|
pub port: u16, |
|
|
|
/// Socket security, such as TLS or STARTTLS, Socket::Automatic if unknown. |
|
pub socket: Socket, |
This will make it possible to configure websocket manually for testing. DCLOGIN QR code scheme can also be extended to support passing websocket path.
For implementation, there are two libraries:
tungstenite looks good, the main difficulty is using our own connection establishment code. We want to use our own DNS, proxy and TLS connector, so cannot use tokio-tungstenite as in examples.
Once there is a possibility to configure websockets manually, we can also test it together with chatmail/relay#1030 and think about discovery later.
For reference, XMPP and IRC support websockets too. I have looked a bit into what they do, they both use message/frame structure of websockets, but in our case it's fine to ignore it and use websockets for streams. No need to try to put SMTP/IMAP commands into separate messages. IRC also uses WebSocket subprotocols, I don't think we are going to use them and don't need to allow selecting them. For IRC it just complicated things, IMO IRC should have defined a single binary protocol and make the client deal with invalid UTF-8 locally.
There is a corresponding chatmail relay PR that adds the ability to connect to chatmail relays over WebSocket: chatmail/relay#1030
As a first step to make it usable, we need core to support connecting over WebSocket.
First, need to extend "socket security" enum that already has Ssl (implicit TLS) and Starttls (STARTTLS) with a new "WebSocket" variant.
Then, login parameters (entered by the user in advanced settings) needs to be extended with a websocket path, likely right after the port:
core/src/login_param.rs
Lines 72 to 75 in c3563f7
It is not going to be used (and probably should not be accepted) if socket security is not set to WebSocket.
Configured parameters should be extended similarly here:
core/src/configure/server_params.rs
Lines 17 to 21 in c3563f7
This will make it possible to configure websocket manually for testing.
DCLOGINQR code scheme can also be extended to support passing websocket path.For implementation, there are two libraries:
tungstenite looks good, the main difficulty is using our own connection establishment code. We want to use our own DNS, proxy and TLS connector, so cannot use tokio-tungstenite as in examples.
Once there is a possibility to configure websockets manually, we can also test it together with chatmail/relay#1030 and think about discovery later.
For reference, XMPP and IRC support websockets too. I have looked a bit into what they do, they both use message/frame structure of websockets, but in our case it's fine to ignore it and use websockets for streams. No need to try to put SMTP/IMAP commands into separate messages. IRC also uses WebSocket subprotocols, I don't think we are going to use them and don't need to allow selecting them. For IRC it just complicated things, IMO IRC should have defined a single binary protocol and make the client deal with invalid UTF-8 locally.