ara4n

6 ms·

1.
by ara4n 11y ago
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 uneconomic. W
2.
by ara4n 11y ago
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 http://github.com/matrix-
3.
by ara4n 11y ago
[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 fragmentation and h
4.
by ara4n 11y ago
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 chat/VoIP&
5.
by ara4n 11y ago
Matrix.org is heavily inspired by Wave, albeit using HTTP rather than XMPp, for those searching a more alive option :)
6.
by ara4n 11y ago
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 that the defra
7.
by ara4n 11y ago
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 - /however/ that data may be end-to-end encr
8.
by ara4n 11y ago
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 and identity fragm
9.
by 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 AP
10.
by ara4n 12y ago
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 homeserver to d
11.
by ara4n 12y ago
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 across http:/&#x
12.
by ara4n 12y ago
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 to bec
13.
by ara4n 12y ago
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 or Riak, albeit optimi
14.
by ara4n 12y ago
...where "We" is the Matrix team :)
15.
by ara4n 12y ago
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 anywhere else you
16.
by ara4n 12y ago
We've also been looking at Axolotl as a better-than-OTR for the E2E crypto. But nothing is set in stone yet.
17.
by ara4n 12y ago
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
18.
by ara4n 12y ago
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 with M
19.
by ara4n 12y ago
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 distributed chat history fo
20.
by ara4n 12y ago
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'v
21.
by ara4n 12y ago
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 to "why not extend SIP" is that SIP stacks
22.
by ara4n 12y ago
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 a resp
23.
by ara4n 15y ago
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 )