Viewing profile — ara4n

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 do…

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, HipCh…

[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.…

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…

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 …

For now, it's an implementation detail (rather than specced) as to how homeservers persist their state. The synapse implementation stores all data unencrypted in sqlite or postgres…

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 …

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 tran…

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…

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 …

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; onl…

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 con…

...where "We" is the Matrix team :)

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 …

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 …

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…

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…

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.…

So, for context: we ended up writing Matrix after literally 10 years of building SIP infrastructure, so we have some experience in SIP (and XMPP's) shortcomings :) The short answer…

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 V…

At least Apple's failure to deliver on their promises on Open FaceTime leaves an opening for other folks to deliver (e.g. http://jointheseen.com/sdk )