Show HN: Vector: a Matrix-powered open-source collaboration Web/Android/iOS app
vector.im
vector.im
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 hope they will offer the same on their web search
"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'd pronounce it as "vector-eem", which is probably odd, but also kinda cool.
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.
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.
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).
- 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?
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.
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.
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.
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!
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.
It's a double-ratchet, very similar to Signal protocol, but unencumbered by the GPL/iOS licensing issues that Signal's implementation has.
https://github.com/microg/android_packages_apps_GmsCore/wiki...
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.
Keep up the good work either way.
[0] https://github.com/vector-im/vector-android/issues/167 [1] https://github.com/vector-im/vector-android/issues/61 [2] https://github.com/vector-im/vector-android/issues/87 [3] https://f-droid.org/forums/topic/vector-a-polished-matrix-ch...
We did this call yesterday with them, the Video element uses FreeSWITCH Video MCU. You should check it out. Its very interesting.
/b
Edit: okay someone else did say "slack", should have refreshed the page before posting :)
And yes Vector allows you to be part of several teams without switching between them.
[disclaimer: I'm from Vector team]
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!
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.
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.
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.
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.
* 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
Designers: Could you please provide an alternate method of human-verification if the user has enabled something like privacy badger?
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?
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.
I wonder how integration with phabricator would work/look like.
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.
It just happens that it can be used for similar things that Slack can. It's more like IRC (but distributed/federated)
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
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?
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.
It seems really unclear from the site & repo: https://github.com/matrix-org/matrix-doc, https://matrix.org/docs/spec/ (apart from being copyright to Matrix.org)
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).
Thanks.
Is the Matrix Spec public domain too?
>Soon, protect your conversation with state of the art end-to-end encryption using Matrix's Olm cryptographic ratchet.