Yup, agreed. We're planning to provide domain vhosting (ie point the SRV for your domain to matrix.org and you'll get your own server instance) which should help a bit, although doing that for free could start to get…
We're still alive and going strong - currently supporting glossy client development like Vector.im and building out bridges to as many other networks as possible (IRC, Slack, HipChat etc) using…
[Matrix lead here] The open source clients for both Matrix and XMPP are improving a lot currently. On the Matrix side there's vector.im; on XMPP there's Kaiwa and Conversations.im. If you want to help break the…
Whilst we're not trying to replace XMPP, Matrix.org does provide an entirely different architecture (decentralised and evetually-consistent history, high baseline feature set, HTTP-based, etc) that can be used for group…
Matrix.org is heavily inspired by Wave, albeit using HTTP rather than XMPp, for those searching a more alive option :)
This is precisely the problem we're working on with Matrix.org - providing a standard API that can be used to bridge together all of these different protocols in one decentralised model. It's better than Trillian in…
There's no harm in having loads of options - you just get a Darwinian survival of the fittest for which app works best. Competition is healthy. The thing that sucks is that as end users we end up having all our chats…
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…
This would be a really cool use for Matrix - the eventual consistency and offline operation stuff is a perfect fit :D You don't need an email address to sign up currently - the way it works is that it's up to the…
There is no link between RedMatrix and Matrix.org - the fact that both have Matrix in the name is total coincidence. On the Matrix.org side, we came across RedMatrix for the first time a few months ago when stumbling…
Yes, it's deliberately much harder for this failure mode to happen: 1. Matrix's baseline featureset is much more comprehensive than XMPP and doesn't yet support API extensions; only datatype extensions. So for a Google…
XMPP and Matrix are fundamentally different things. XMPP is all about message passing. Matrix is all about state synchronisation. In many ways Matrix is more like an eventually consistent distributed DB like Cassandra…
Matrix is basically an eventually consistent object database with open federation and pubsub. It's optimised for messaging at the moment - you can use it for group chat, or WebRTC signalling, or M2M/IOT stuff, or…
We've also been looking at Axolotl as a better-than-OTR for the E2E crypto. But nothing is set in stone yet.
Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is: curl -XPOST -d '{"msgtype":"m.text",…
It's a shame that XMPP didn't save us from this situation. My hunch is that the baseline featureset over federation was too low: no federated medsage history; MUCs are single point of failures. We're trying to fix this…
Oops - I should have called it out more clearly in the blog. The biggest difference we have over XMPP is probably that messages in Matrix get synchronised over all the participants of a conversation... so you get…
SIP+SIMPLE/MRSP's overheads are just as bad as HTTP/1.x, if not worse. We decided to build Matrix after 10 years of fun doing commercial SIP and XMPP work; we have some experience. For instance, the worst scenario we've…
rpdillon is totally right - the term is overloaded. We're using "realtime" exclusively here to mean synchronous human communication - like the RT in WebRTC. In other words, IM or VoIP - anything where you expect to get…
Yup, agreed. We're planning to provide domain vhosting (ie point the SRV for your domain to matrix.org and you'll get your own server instance) which should help a bit, although doing that for free could start to get…
We're still alive and going strong - currently supporting glossy client development like Vector.im and building out bridges to as many other networks as possible (IRC, Slack, HipChat etc) using…
[Matrix lead here] The open source clients for both Matrix and XMPP are improving a lot currently. On the Matrix side there's vector.im; on XMPP there's Kaiwa and Conversations.im. If you want to help break the…
Whilst we're not trying to replace XMPP, Matrix.org does provide an entirely different architecture (decentralised and evetually-consistent history, high baseline feature set, HTTP-based, etc) that can be used for group…
Matrix.org is heavily inspired by Wave, albeit using HTTP rather than XMPp, for those searching a more alive option :)
This is precisely the problem we're working on with Matrix.org - providing a standard API that can be used to bridge together all of these different protocols in one decentralised model. It's better than Trillian in…
There's no harm in having loads of options - you just get a Darwinian survival of the fittest for which app works best. Competition is healthy. The thing that sucks is that as end users we end up having all our chats…
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…
This would be a really cool use for Matrix - the eventual consistency and offline operation stuff is a perfect fit :D You don't need an email address to sign up currently - the way it works is that it's up to the…
There is no link between RedMatrix and Matrix.org - the fact that both have Matrix in the name is total coincidence. On the Matrix.org side, we came across RedMatrix for the first time a few months ago when stumbling…
Yes, it's deliberately much harder for this failure mode to happen: 1. Matrix's baseline featureset is much more comprehensive than XMPP and doesn't yet support API extensions; only datatype extensions. So for a Google…
XMPP and Matrix are fundamentally different things. XMPP is all about message passing. Matrix is all about state synchronisation. In many ways Matrix is more like an eventually consistent distributed DB like Cassandra…
Matrix is basically an eventually consistent object database with open federation and pubsub. It's optimised for messaging at the moment - you can use it for group chat, or WebRTC signalling, or M2M/IOT stuff, or…
We've also been looking at Axolotl as a better-than-OTR for the E2E crypto. But nothing is set in stone yet.
Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is: curl -XPOST -d '{"msgtype":"m.text",…
It's a shame that XMPP didn't save us from this situation. My hunch is that the baseline featureset over federation was too low: no federated medsage history; MUCs are single point of failures. We're trying to fix this…
Oops - I should have called it out more clearly in the blog. The biggest difference we have over XMPP is probably that messages in Matrix get synchronised over all the participants of a conversation... so you get…
SIP+SIMPLE/MRSP's overheads are just as bad as HTTP/1.x, if not worse. We decided to build Matrix after 10 years of fun doing commercial SIP and XMPP work; we have some experience. For instance, the worst scenario we've…
rpdillon is totally right - the term is overloaded. We're using "realtime" exclusively here to mean synchronous human communication - like the RT in WebRTC. In other words, IM or VoIP - anything where you expect to get…