| 17 Aug 2019 |
 Mo 🛰 | * The main point for using web sockets over sse was that it allows me to detect broken tcp connections. This is a big issuue with flaky connections and a device that wants to sleep all the time :) . | 21:18:21 |
 Matthew | so is this matrix over WS? or a separate push mechanism? | 21:24:49 |
| Mo 🛰 | In reply to @matthew:matrix.org
so is this matrix over WS? or a separate push mechanism? it is a push gateway + push provider for push notifications. the actual martix-stuff uses /sync long-polling. | 21:26:23 |
| Matthew | ah, separate push | 21:26:24 |
| * Matthew nods | 21:26:34 |
| Matthew | on the matrix side our plan is to make /sync so light that you can use it for push | 21:26:55 |
| Mo 🛰 | In reply to @matthew:matrix.org
so is this matrix over WS? or a separate push mechanism? * it is a push gateway + push provider for push notifications. the actual matrix-stuff uses /sync long-polling. | 21:27:04 |
| Matthew | and then you’d get e2ee push for free | 21:27:11 |
| Matthew | and not have to worry about two transports | 21:27:22 |
| Matthew | but we haven’t got that far yet :| | 21:27:41 |
 Nico | This is the proposal for a sse sync endpoint: https://github.com/matrix-org/matrix-doc/issues/2024 Would be interesting, if flaky connections would still be an issue then and the proposal should use websockets instead. | 21:34:46 |
| Mo 🛰 | Matthew that sounds great, but i'm afraid ... syncing and pushing are two separate bags of problems. right now, with long polling .. device has to be awake to sync. a lighter version would be indeed using server sent events. as long as the device is awake, screen on and the user is activele using the client ... it will probably work. but i'm not sure if it could be used as actual push mechanism. .... the connection between a mobile client and server get's 'broken' all the time, so the client needs to actively reconnect if that happens. ... but with sse, it's very hard for a client to detect a broken connection, if not impossible without complicated workarounds . | 21:36:49 |
| Mo 🛰 | basically, a client can only detect a broken tcp connection by trying to send some data to the server. this can be done on tcp level since every connection is a duplex one. in http world, however, there are no duplex connections (at least not in http1.1) ... that means using SSE with http1.1 just doesn't allow for sending 'pings' from the client to the server. http2, does allow duplex connections, but is terribly complex and library support is limited. you would have to force every client to use http2, to take full advantage of the api. | 21:45:04 |
| Mo 🛰 | websockets, however, work with all http versions, are duplex connections, and even have 'ping-pong' commandos built in. thats why i chose them. library support is also quite ok. | 21:47:07 |
| Matthew | Mo 🛰: i understand this :) but my point is that if Matrix was better, its transport could be used for both push & sync (complete with fast recovery in the face of network outages for both push & sync) | 21:47:31 |
| Matthew | as push is a subset of sync | 21:47:36 |
| Matthew | it's literally a filter that says "please only send me events which are notifs. and btw i (probably) don't care about any of the fields on the events; i just want to be woken up". | 21:48:08 |
| Matthew | this is why we experimented with the CoAP transport for Matrix | 21:48:16 |
| Matthew | as per https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barrier-with-matrix-meshsim-coap-proxy | 21:48:25 |
| Matthew | (which btw outperforms both SSE & WS by a factor of about 50 in terms of bandwidth - and gives you as good semantics for detecting connection outages ;) | 21:48:58 |
| Matthew | however, we haven't progressed much further than the initial PoC in terms of improving /sync to be push-based (rather than long poll) and have push-style filtering semantics, or hooking up to CoAP, sadly | 21:49:33 |
| Matthew | but ftr this is the direction we've been considering for Matrix. | 21:49:39 |
| Matthew | it would also have the nice side-effect that any FLOSS project that wanted Push might get Matrix for free | 21:49:49 |
| Matthew | which would be a great step in terms of having Matrix as a general purpose FLOSS messaging infrastructure for the wider world (rather than using bidirectional msging in Firebase and getting locked into Google, or whatever) | 21:50:36 |
| Mo 🛰 | oh wow :) i didn't know that. that sounds very interesting. i wiil have to watch the video. I'm reading for the first time about CoAP 🙈
thats definitely a very nice perspective / vision for matrix ❤️ | 21:53:03 |
| Matthew | (btw, sputnik looks super-impressive, now i've got to a laptop and able to look at the repos :) | 21:53:04 |
| Matthew | if you look at the slides for that talk (prolly easier to flip through https://matrix.org/blog/wp-content/uploads/2019/02/2019-02-03-FOSDEM-Low-Bandwidth.pdf rather than hear me drone on) you'll see i evaluated http in various flavours (albeit not WS or SSE admittedly) and how we converged on CoAP + Noise | 21:54:02 |
| Matthew | CoAP is fun because it looks & smells like HTTP, and so maps really easily to Matrix | 21:54:12 |
| Matthew | but you also get an OBSERVE method, which lets you do SSE-style behaviour | 21:54:21 |
| Mo 🛰 | In reply to @matthew:matrix.org
(btw, sputnik looks super-impressive, now i've got to a laptop and able to look at the repos :) thanks, but it's still in a very early stage and there is still a lot to do :) | 21:54:20 |
