I'm not trying to be rude by saying this, but these names "Vector" and "Matrix" are far from Google-able, and sometimes (esp. in game development, and other scientific fields I'm sure) not even clear in person-to-person discussion.
Agreed, I think it's an unfortunate naming choice. As a physicist (and hence also mathematician and programmer) this term is already terribly overloaded.
"Slack" is clever because it's not an obscure word but also not something one would normally Google for. Most brandings seem to just opt for really obscure words or made up words, which also works.
I'll just add that in biological sciences both "vector" and "matrix" are also overloaded with yet more meanings in addition to the mathematical ones. (e.g. "plasmid vector", "extracellular matrix")
well, Matrix is Latin for 'womb', so it's fairly safe to say that the word is heavily overloaded already. Given we have the top google slot (having gone incognito) for Matrix Chat and Matrix Protocol etc. I'm not /that/ worried...
Usually I would type in "Vector IM" or another word I associate with what I'm looking for if I forgot the domain. Just like "GoLang" and "DLang" when I google for those languages.
Edit:
Come to think of it I'm surprised Google doesn't offer alternate search suggestions in "Web" searches as they do in "Google Images" it would make searching the web more interesting. I think all major search engines should give that approach a try. I know Google shows options to enhance your Google Images searching.
I google'd "Go" and didn't see what you meant. When I searched "Swing" I found it. I think that should be either on the side at the top somewhere, or before results if possible.
I've been using Vector for Android the last days and I must say I am VERY impressed. Both the vector.im web interface and the smartphone apps are looking polished at a level that I'm very unused to when it comes to open source projects.
I must say though that people are becoming more and more unfamiliar with decentralization. Naming the standard one thing (Matrix) and the main phone app another (Vector) is IMHO a move that only a technologist would come up with. The logic might seem crystal clear to all you working on the project. But if you want traction (hell, you could actually be a serious alternative to Slack!) you should've register something like matrix.im and named the app Matrix.
Matrix is the protocol that Vector uses. Matrix itself is being marketed to developers to build their apps using it. Vector is aimed at end users who want a chat system, and they don't really have to know or care what Matrix is. A good analogy is Matrix : Vector :: Email : Gmail
Except Vector and Matrix are two different things :) Matrix wants as many apps built upon it as possible, Vector is just leveraging the power of Matrix to provide good collaboration services
Ah, after actually reading, and not only using, I understand. So, will the end user looking for a chat and collaboration tool (or alternative to Slack or IRC) only see the Vector "brand" and not Matrix?
Matrix is an extremely promising project. It has everything I'm expecting from IM platform so far: it's very open; it's decentralized (I can host my own server and it'll talk to others); it's centralized (one server for many clients); it's modern (HTTP, JSON, REST); it supports push; it synchronises a single history between all clients. It has VoIP, file transfers. There are numerous clients and few are surprisingly mature.
Honestly, it's the best protocol out there. I don't know any other protocol with all those features. I really hope, that Matrix will be the IM of our future, it's good enough for that, in contrast to every other popular IM platform.
I used vector.im as a web interface, and it just works.
I'll try to deploy Matrix as our tiny company internal communication tool. Currently we use a mix of e-mail, skype, whatsapp, telegram, and it just not as good as it could be. I can't force my friends to move to other IM, but I can influence my colleagues, and, hopefully, it'll be the trend.
What Matrix really need is some marketing. It's so awesome, I couldn't believe, that I'm so rarely read news about it. Very few people know what it is, and that's a sad situation.
I was only at the first six hours of the Decentralized Web Summit and I missed your demo. Tim Berners Lee was promoting solid github.com/solid as an open framework. I have just started looking at Solid and I would appreciate your comparison of Matrix and Solid.
Solid seems to have very similar goals to Matrix, but seems to be a bit more abstract at this point. I had some brief conversations with Tim at the summit about how to collaborate, and as you can see he's been using Vector to participate in the conference chat. I'm sure that we'll get the two to bridge or converge in future!
This may be helpful to other people, as I myself was a bit confused in the beginning.
Vector.im is a client to the protocol called "matrix.org".
This is equivalent to using XChat(client) on the IRC protocol.
In this case, matrix.org also runs their own servers (but you can host your own), so it is like IRC protocol (matrix protocol) + Freenode (matrix server).
One big difference though is that the users on one server could communicate with users on another server. In the world of IRC that would mean that users from Freenode and EFnet could communicate with each other in the same channel. Pretty awesome.
But wouldn't clients have to decide which federated servers it wanted to participate in? E.g., if I join #python on Freenode...
- Do I necessarily want my chat to be intermingled with #python on EFNnet, OFTC, etc.?
- How would you prevent new users from auto-subscribing to a spam server? Do you just ban the spammy server? Would every server operator need to manage such a ban individually?
Bridged rooms are namespaced by whoever runs the bridge - e.g. #freenode_#python:matrix.org is the alias for the bridge to #python on Freenode that's run by matrix.org. Similarly #efnet_#python:matrix.org would be the alias for the EFnet room, if we ran an #efnet bridge. It's possible for a malicious user to try to bridge unrelated rooms together, but this is an abuse problem no different to someone floodjoining or otherwise trying to harm a room.
Handling spam and abuse in general is a huge issue for Matrix which we're putting massive focus on at the moment (in fact, it's why we're in SF at the Decentralized Web Summit currently). The whole decentralized web movement has a crisis on the horizon if there isn't a decentralized identity/reputation/abuse system of some kind to track miscreants and help admins and users mitigate spam.
Edit: in other words, right now a server admin would have to manually blacklist bad servers. In future there'd be a decentralised data structure of some kind (stellar ledger, blockchain, matrix DAG, IPFS DAG or whatever) tracking the greylist of servers/users/gateways to help decide who you want to talk to.
But that's how IRC was originally designed, and it didn't work out in the long term.
There was only one network and any server could join it. But you could set up malicious servers can cause havoc on the network. Eventually all the Hubs but one closed their doors so only authenticated servers could be added. The remaining holdout was eris.berkeley.edu
And so the network split into the Eris-Free network (or EFnet) with the remaining servers connected to eris forming the Anarchy network (or Anet). Anet died out reasonably quickly.
There have been a few more splits over the years, until you reach the current situation, with around 6 major networks and hundreds of smaller networks.
IRC's federation is closed - you can't just spin up a new server and join Freenode unless you work for them. Matrix's federation is open (like email, or XMPP) - anyone can spin up a server and own their own conversations :)
Matrix and vector look more interesting by the week. I would really like to see the Android port on F-droid. I haven't done a tonne of research, but I believe Vector uses Google Play Services, specifically GCM. This makes it impossible for me to use on my GAPPS-less phone. It also bars it from F-droid.
Yes the Vector Android app uses GCM, but it's opensource so you might be able to tweak it so that it works on F-droid? Sorry I don't know much about the differences there...
Leaving people no option but to use Google's infrastructure (if they want to participate with anything better than a browser) seems an ENORMOUS gap, given the rest of the project's goals. If you want to use it on mobile, it IS still centralised around Play Store and GCM (where Google can collect all your metadata).
You can't even install the Matrix mobile app on open source Android phone that doesn't have all the Google bloatware installed (which you can't do on decent OS's like Copperhead yet while keeping a signed & verified boot loader).
You've done some great work, so I don't want to be too critical (I don't have time to implement the fix for a start!) - but this is almost like how Signal claims to be open source, but you can't ACTUALLY USE the iOS version, because GPL is incompatible with Apple Store.
You claim to be open source and decentralised, but you can't actually use it on an open source and decentralised platform. So I kinda don't see the point.
Have you actually tried using it on a phone with no Google Play Services? I'm involved with the project and I remember someone reporting it works just fine. Vector for Android falls back to polling if GCM isn't supported/working afaik.
I hadn't tried it, no. Was just going on what others had said here. That's great to hear it has at least some sort of fallback! Polling however is typically too battery draining to be practical. Battery drain was one of the biggest reasons XMPP lost traction.
If Matrix adds something like XEP-0357 Push Notifications, enables verifiable builds & FDroid distribution, plus gets full featured XMPP bridge implementations done, then I think you're onto a winner. It gets extremely hard to convince people to install N+1 different IM clients once N>5, let alone the >10 that're becoming common. The XMPP Push XEP is working fantastically in Conversations IM and extremely fast too BTW (much snappier than Signal at least).
Congratulations on your work on the Olm implementation too!!! Now that Signal Protocol has been locked up in legalese (turns out Open Whisper WEREN'T really open), you guys are THE leading E2E implementation. It's really a fantastic contribution to the community and we owe Matrix devs a huge thank you!
We do have a similar equivalent to XEP-0357: http://matrix.org/docs/spec/push_gateway/unstable.html. We can and will make Matrix do smarter than polling though, especially for the case that GCM isn't available. For instance you could use the websocket transport that's available today.
Glad you like Olm :) I think OWS are trying to find a way for their impl to be appstore compatible too, so hopefully the user wins twice over!
Re OWS; yes, I still keep some small hope that they've just been too preoccupied and not completely thought/worked things through. People are human and they've clearly had a lot going on! Their position as stated really did surprise a lot of people. Matrix.org's views on decentralisation certainly sounds FAR closer to the future I'd like to see for the net. Being able to evolve or change clients and integrate new technologies, without cutting off the entire network, seems clearly a very good thing indeed.
FWIW, my understanding is websocket connections isn't robust under all mobile carriers, as most drop connections when you try to upgrade to a websocket, since they assume http upgrade is for ssl, and also there are problems with periodic disconnects.
Yes, see https://matrix.org/docs/spec/olm.html. An implementation of that spec is in final testing and expected to land into master within a couple of weeks.
It's a double-ratchet, very similar to Signal protocol, but unencumbered by the GPL/iOS licensing issues that Signal's implementation has.
Yup, fallback to polling should work fine. In future, when folks implement more efficient transports for Matrix than HTTP+JSON then Matrix itself could be quite a compelling open alternative to GCM for push notifs :)
Microg is not an option as it requires signature spoofing, which requires security to broken in various ways. Forces rooting the device or running Xposed, or applying dodgy kernel hacks and prevents using verified boot, which is a sensible security requirement.
F-droid builds everything from source so there would have to be a build flag that would remove GCM functionality. From what it looks like, when GCM is disabled, vector reverts to polling the server for information instead of messaging interrupts[0]. This is of course highly inefficient and an alternative has been proposed in the issue, but I can't speak to it.
It looks like the team previously made Google Analytics opt-out-able[1]. I didn't look at the commit to see if it's a build flag or just a GUI toggle. I believe to be on f-droid it would have to be absent the binary entirely.
I found an issue relating to allowing a GCM opt-out[2]. I think this would realistically require the polling issue to be solved though.
Here is the f-droid request for addition[3].
I'm not sure about a solution and all I've done is comb the issue log a bit. The Conversations app currently on F-droid is able to handle timely messaging with low battery consumption and no GCM. They're different protocols entirely, I realize, but maybe some ideas can be gleaned from that implementation. In a perfect world, all open-source decentralized applications would depend on zero closed-source centralized services, but I know the cost/benefit analysis of the implementation overhead may not always weigh out.
Nobody has said the word "slack" yet... but am I interpreting this correctly? An open source clone of slack? If so, it's very interesting. I wonder if they are taking any steps towards solving the "fragmentation" issue that slack teams seem to cause. I have a few contacts that are shared between 2-3 different slack teams and I can never remember where to find my PM conversations.
Edit: okay someone else did say "slack", should have refreshed the page before posting :)
Vector runs on top of the Matrix protocol (matrix.org), which is built precisely to fix fragmentation - hence the name Matrix :) Anyone within the Matrix ecosystem can talk to anyone else, whether they're using Vector, another Matrix client (http://matrix.org/docs/projects/try-matrix-now.html), or a bridged system like Slack, IRC, XMPP, etc. We want to open up all those silos to talk to one another.
Vector does address the same market as Slack, with similar feature set but also leveraging Matrix to bridge to other systems like Slack, and IRC, and others soon.
And yes Vector allows you to be part of several teams without switching between them.
Thanks for the reply! To clarify, you mean to say that a single user-account can be the exact same entity on multiple teams? And so point-to-point communication is not affected by team boundaries?
What about server boundaries? Can they be federated somehow? Sorry if you are trying to answer this with your point about Matrix; I'm not familiar with it.
Edit: ah! Arathorn answered my question about federation. This is super cool stuff!
Yes basically the concept of closed teams doesn't exist in Vector: you are a member of different chatrooms, public or private, with other people, each having its own focus, no matter what is the project scope or the topic.
I still don't understand why Matrix was made when XMPP is already a thing; if you're not happy with the existing standard participate in the process, don't just make up a new one. https://xkcd.com/927/
They have completely different architectures and philosophies. Matrix is a decentralised conversation database - it's all about synchronising communication history between the different silos. It has a single monolithic spec, for better or worse, so you know that if your client and server supports the Matrix v0.1.0 spec, they will work with all the features available for the particular use case (e.g. mobile voip).
XMPP instead is federated messaging and presence (and a whole bunch of stuff on top). It's passing stanzas between servers rather than synchronising historical stanzas between servers. The specs are highly modular and extensible and built out of XEPs. It's just a totally different way of approaching the problem of open communications.
You could make the comparison that XMPP is a bit like SMTP, and Matrix is a bit like NNTP (Usenet). They both fulfil the same end goal - letting folks communicate openly over the internet. But they have totally different designs and there's room on the 'net for both.
After all, you can just bridge XMPP to Matrix and everyone wins! :)
There's a larger narrative, I think, about how standardization bodies that are focused on backwards-compatibility can move more slowly than a newly-built ecosystem. While the web has huge commercial players dedicated to making it a first-class experience in an interoperable way, it's unclear that XMPP has the same impetus to evolve. Google Wave could have saved XMPP, but look how that turned out. I think it's very reasonable for Matrix to unfetter themselves from XMPP politics in a world where Slack the Quadricorn is the gold standard.
> I still don't understand why Matrix was made when XMPP is already a thing
Have you tried... thinking about it a bit more? I could come up with roughly 20 different reasons without trying very hard. For someone involved in XMPP, that is one hell of a thing to say.
Seriously, calling out XKCD927 on a massive project like Matrix is extremely disrespectful to its contributors.
Tell me, what could Matrix have done to save XMPP? Publish a hundred different XEPs nobody would ever bother to implement? Make broken clients/servers that don't follow the spec just to try fix a protocol that lost? Magically fix everything and tell people "No really guys, XMPP is better now I swear!"?
They went and tried a new approach and they're doing really well with it... have some respect for that.
I actually think it's very good thing that people are asking that question (why not fix XMPP)!! We know from Bob Metcalfe's Law, that starting new networks has a very high cost, either in adoption/migration, lost investments in past standards, duplication of efforts when multiple need to be supported, or when they fail to gain critical mass. There's a limited pool of attention and resources and it's right for people to be instinctively cautious and have the discussions.
For me, the more I learn about Matrix, the more persuaded I am that it really does have merit. If I were a Matrix developer, I wouldn't feel disrespected. I'd be super glad that people are asking questions and genuinely seeking to test that the idea is right. From their dialogue with the community that I've seen so far, the developers are doing great and seem to thoroughly appreciate there's been a lot of false starts by various groups over the years.
TLDR;) - It may be obvious to you, but it's GOOD people are having the conversation. Questions and even dissent should be embraced. It's not about disrespect, it's about testing & validating new ideas.
I should add, that the ability to bridge networks, means that XMPP, IRC and others won't/don't need to be cut off from Matrix either. That's kind of the point and interop is one of the big features it will have going.
Looks very interesting, but the site is still lacking some important information (or not very clear) from an end-user perspective. Why is there no description of the features? Don't tell me "just try it". There are so many chat clients out there I can't try all of them. But I'm always on the look out for a chat client that also supports group voice chat and group screen sharing.
The page says "VoIP", but with no explanation or details at all. The demo doesn't seem to contain that. Does it exist?
Screensharing is not mentioned at all. Does it exist?
Does this run on Windows / OSX / Linux? Neither is mentioned anywhere.
Maybe even more important would be an end-user oriented site for the Matrix server. Is this a thing? The matrix.org site is very confusing as it has no clear focus. It's all a mix between detail-free overview of the overall idea and low level protocol specification. Where is the end-user friendly page about the Matrix server? What features does it have and how do I set it up? Where is the "tutorial" / blog post about how to successfully setup my own server and install a client in three easy steps to have a full team communication solution (group-text, -voice and -screensharing)?
One thing I really like about Slack is they have great documentation and great customer support. Matrix and Vector may be great, unfortunately it's too difficult to find out.
So far the site is just a quick one-page overview - we haven't had a chance to flesh out any of the detail yet at all; sorry about that :) To answer the questions:
* 1:1 VoIP is supported on WebRTC on the web version, Android, and iOS coming very shortly. On Web you hit the call buttons on the bottom right; on Android it's currently hidden behind the top-left menu.
* Multiway VoIP is very beta, but supported on the web version. Hit the call buttons when in a room.
* Screensharing is even more beta, but happens to be there as an undocumented easter egg on Web. Currently it only works if you're running on Chrome with the --enable-usermedia-screen-capturing commandline option, and shift-click on the video call button. Obviously this isn't intended remotely for serious use yet, but we're working on it.
* The three platforms supported are Web/iOS/Android. You can of course run the Web client fine on Windows/OSX/Linux. If you want a different native client, go experiment with the other options on http://matrix.org/docs/projects/try-matrix-now.html
* The page you failed to find for the Synapse server is probably the read me at https://github.com/matrix-org/synapse. Agreed we need to make this clearer, and provide much better simple overviews and tutorials for getting up and running.
* Agreed that Slack have amazing documentation - it's something we desperately need to do better at. I'd like to think our "customer support" isn't too bad, though; good luck in getting one of Slack's co-founders answering your feedback on HN ;D
Thank you for the in depth reply. Glad to hear these things are on the roadmap. I'm really looking forward to when they are ready for serious use. (Although I'm a bit skeptical about WebRTC. Browsers have hyped it for over five years now and is still barely beta quality.)
PRIVACY CONCERN: I had to disable Privacy Badger simply to create my account. When I clicked the link in my email for verification, it asks me to prove that I'm not a robot, but didn't have anything for me to click or do to prove that. Only after disabling privacy badger would it produce a simple checkbox which I clicked, thus proving I'm not a robot.
Designers: Could you please provide an alternate method of human-verification if the user has enabled something like privacy badger?
I Just got weirdly excited by this. I had heard of it before but never really though about what I could do with it. But then I'm never really sure if I understand it completely yet.
If i just want to set up a server that me and my friends would use. I can just make a server. they would register on it and we would be good to go? I don't have to join the federation if I don't want to? I understand the advantages of doing so though.
Also, how does the vector apps go on battery use and all that. comparable to other messaging apps?
Precisely: just setup the server and off you go, you don't have to federate, although as you say that would be missing part of the fun ;)
The Vector app on Android (using GCM) has pretty good perf battery consumption-wise. Unsure how it compares with other apps but we haven't had any particular complaints about it.
As someone who has self hosted my own XMPP server before and still cries over the move taken by Google and Facebook with their messengers, can someone from the Matrix people explain what is so fundamentally different from the protocol, that it couldn't be done in XMPP?
Please don't say "it is XML based". I know the situation with the clients is XMPP-land is appalling, but it seems to me that if Matrix does get any kind of traction, it will face the exact same kind of problems.
With Vector you have the choice between using the hosted version of Vector or host it yourself.
And being built on the Matrix (http://matrix.org) standard, it's a completely distributed architecture: run your own server and own your own data!
Like any other Matrix compliant app, Vector supports out of the box all the bridges and integrations the community contributes to the Matrix ecosystem. So today it bridges to Slack and IRC, soon Mattermost, Rocketchat, Skype, Lync... And Github, Jira, Jenkins for the integration side, with much more to come, including Slack webhooks.
On the UX side of things, Vector doesn't force you to create an account per team like Slack does and allows the creation of public chat rooms which can be referenced in a directory.
Rooms can be invite-only or just "hidden" (anyone with the link can access) or fully public (anyone can access).
Also every message is indexed and has a permalink to it, so easy to share information, especially given people can access rooms as guests (if the room allows), no need to create an account.
In terms of Real Soon Now stuff:
- End to end encryption will be landing in a couple of weeks
- Vector web and Android support voice and video conferences via WebRTC (it needs additional polish so consider it as beta, but it's here)
- Proper nice UI to provision the bridges and the integrations in the room (couple of weeks)
And I feel like I'm missing stuff... But that's probably the main bits
> In terms of Real Soon Now stuff: - End to end encryption will be landing in a couple of weeks
Will this be based on Axolotl? If so, and you want to avoid the Signal problem of there being a log of messages being passed between users, how are you dealing with that? Or is the idea that to make that type of security guarantee you have to self-host conversations? If so, surely there's still a log of messages being sent there. Maybe you could employ a rubberhose-like setup where you send fake messages that mask the real ones?
Yes, it's using a Double Ratchet implementation - an independent implementation we wrote in C/C++ called Olm (https://matrix.org/git/olm/about). We've also added a new group ratchet called Megolm which lets users in the room share the same ratchet to decrypt the group messages.
The actual ratchet itself does nothing to protect metadata - it's just encrypting the payload of the messages in the room, and providing a 1:1 ratchet to exchange the details of the group ratchet for the room.
Obfuscating metadata is a Hard Problem, and if you don't want your server admins to be able to see who's talking to who, you'll need to look at something like Vuvuzela or Ricochet or Pond. In future we may go down the metadata protecting rabbit-hole, so to speak: https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E... has the details.
In terms of architecture, it's entirely different. Rather than being a centralized service (like mattermost), Matrix is a decentralized protocol that can be federated across servers. And vector.im is just one (web) interface for using this protocol.
It just happens that it can be used for similar things that Slack can. It's more like IRC (but distributed/federated)
Right now you have to run your own integration from the list of Application Services at http://matrix.org/docs/projects/try-matrix-now.html, or use one of the existing ones which someone's running out on Matrix. In the near future Vector will provide self-service hosted integrations for those who don't want to run their own.
there's a very basic and experimental pidgin plugin at https://github.com/matrix-org/purple-matrix, but the impedance mismatch between purple2 and matrix is pretty bad (eg limited support for synchronised conversation history). It needs more features before it can be used in anger - patches welcome ;)
Is this yet to be clarified? (Maybe the Google vs. Oracle case makes it slightly less relevant, but needs to be clarified).
What stops Matrix getting everyone aboard, then releasing new CLOSED versions of the major server and clients with a new spec (as the protocol formerly known as Axltl did), and carrying the critical mass of user base with them? Sure, the implementations are ASLv2, so in theory the community could fork, but in practice that doesn't always work. Is there going to be incentive to keep it open? (Signal was an 'open' implementation and spec too, but that didn't work out as people expected, even though OWS are non-profit).
