3 ms·

Thanks for the suggestion. I skimmed their docs before briefly; I'm giving it a second look now, and realizing I passed by way too quickly last time. It looks

Thanks for the suggestion. I skimmed their docs before briefly; I'm giving it a second look now, and realizing I passed by way too quickly last time. It looks like they did tackle acausality head-on; I like what I see about previous message IDs being included in https://matrix.org/docs/spec/#pdus https://matrix.org/docs/spec/#pdus Nervous about ever christening JSON "today's technology". JSON has the same problem XML in XMPP does: can't tunnel binary e.g. video without extreme backbending (jingle for XMPP is pretty much a textbook example of "too much friction -> not fit for purpose and near zero adoption"). But it looks like matrix is pluggable on transports, too, so that's potentially a sweet spot for lazy REST clients and powerful performance situations to coexist. ... And I popped into their self-hosted chat room. Observation 1: It works (!). Observation 2: the devs are dogfooding and seem both knowledgeable and friendly :) I haven't taken the leap to self-host yet (will later!); but from preliminaries, matrix is looking remarkably solid and well thought out. I'm going to try to build something with this! Thanks again for the link!

rakoo 11y ago
> Nervous about ever christening JSON "today's technology". I use this to say "XML was the hot when XMPP was created, the way JSON is the hot today, when Matrix is created". I 100% agree with you that using a non-binary-friendly format sucks for pretty much anything that goes beyond plain text messaging: - encryption - files/emoticons/voice - on the server side, any routing stuff But still, like XMPP I hope this will not be enough to hamper its development. > jingle for XMPP is pretty much a textbook example of "too much friction -> not fit for purpose and near zero adoption" Amen to that. XMPP is basically an entity-to-entity messaging protocol, and yet because it can't handle binary there needs to be a negotiation step and yet another connection for binary stuff... blah.
ara4n 11y ago
The client-server API of Matrix only uses http+json as the lowest common denominator baseline for compatibility. Folks are more than welcome to implement custom more efficient transports like COAP/CBOR or whatever. The server-server API is currently just targetting https+json just for expedience in getting started, but nothing to stop us negotiating more efficient transports in future - capn proto has come up a lot in conversation as a possible option. Handling signing is a bit more fun as we currently rely on signing canonical json, but surmountable. As for binary transfers... well, random blobs are just handled as pure HTTP with a mimetype currently :)

rakoo 11y ago

> Nervous about ever christening JSON "today's technology". I use this to say "XML was the hot when XMPP was created, the way JSON is the hot today, when Matrix is created". I 100% agree with you that using a non-binary-friendly format sucks for pretty much anything that goes beyond plain text messaging: - encryption - files/emoticons/voice - on the server side, any routing stuff But still, like XMPP I hope this will not be enough to hamper its development. > jingle for XMPP is pretty much a textbook example of "too much friction -> not fit for purpose and near zero adoption" Amen to that. XMPP is basically an entity-to-entity messaging protocol, and yet because it can't handle binary there needs to be a negotiation step and yet another connection for binary stuff... blah.

ara4n 11y ago

The client-server API of Matrix only uses http+json as the lowest common denominator baseline for compatibility. Folks are more than welcome to implement custom more efficient transports like COAP/CBOR or whatever. The server-server API is currently just targetting https+json just for expedience in getting started, but nothing to stop us negotiating more efficient transports in future - capn proto has come up a lot in conversation as a possible option. Handling signing is a bit more fun as we currently rely on signing canonical json, but surmountable. As for binary transfers... well, random blobs are just handled as pure HTTP with a mimetype currently :)