Matrix 1.0 and the Matrix.org Foundation
matrix.org
matrix.org
It's not exactly easy to do (iMessage requires a dedicated Mac, for example), but it's possible. And it works pretty well. Pulling out my phone to tap out an SMS when I have a full keyboard in front of me seems silly at this point. Hopefully the bridging will continue to evolve and become more accessible to the average user, because it's amazing.
I start by looking into Hangouts matters, because I use Hangouts to talk to some of my family, currently only on my phone and not on my laptop; and I see three projects listed in https://matrix.org/docs/projects/try-matrix-now: matrix-appservice-hangouts, mautrix-hangouts, and Hangouts Bridge. https://matrix.org/docs/projects/bridges/#hangouts lists two, matrix-puppet-hangouts and matrix-appservice-hangouts.
Bridge, puppeting bridge, appservice—I have no idea what any of this means. I’m generally hoping for something like an instruction to install a piece of software on my laptop with `curl … | sudo bash` or some unsigned .exe or something. (Are any of these things basically a Matrix server that I could run on localhost, or do they slot into a Matrix server that I’d need to host elsewhere?)
And so I give up. The content formatting of those pages on matrix.org was super-ugly anyway, it’s clearly either not a good product or not for normal people. (This remark may seem harsh, but this is how most will think.)
What do I need to do for all of this to get Hangouts, SMS and Slack working in Matrix? Is Matrix ever going to focus on users and make questions like this easier to answer, or will it remain a niche product that I should not bother with?
For certain things it's pretty easy. Bridges like IRC, Gitter, and Slack are a couple clicks from within the Riot app, although you do have to go goof around in the settings for those third party services to get it talking to Matrix. There's also starting to be some hosted services for bridging public rooms where you can just invite the bridge bot to the room to get things going. Like here: https://t2bot.io
The thing that I find particularly exciting about Matrix is that it 1) has support for doing that kind of thing, and 2) it can scale pretty gracefully from a 1-to-1 chat all the way up to a room with thousands of users. So you can (even if it isn't always easy, currently) bridge a 1-to-1 Hangouts chat, or a Slack room with a few dozen people, or a Discord server with thousands.
I'm not trying to oversell it right now. Many of the bridges are difficult to set up and not really something the average user will be able to do (although there are many that are). But it's pretty damn cool that we're able to do it, and I expect it to get easier as things progress. Matrix itself is only just now leaving beta, and even then the reference server is slow and still missing some big features. So the "extra" stuff written by the community is going to take a while to develop into "click to enable".
Given that the documentation you're reading is for sysadmins, it shouldn't be a surprise that its not targeted to end-users (assuming that is what you meant by "normal people")
> but it’s only a killer feature if it’s accessible.
Again, depends on your definition of accessible. Personally, if there is a feature I really like, I don't mind being patient and spending couple of hours to understand the docs.
I'm not denying that Matrix needs to improve the issues that you've pointed out, but that shouldn't make one disregard how useful it is.
Dont underestimate the value of a easy user interface for a products success.
This is useful, but why is it killer ? Stuff like this has always existed even with IRC or XMPP. The annoying part with all these proprietary services is reverse engineering their APIs and APIs not being stable etc. Once you do the main legwork, can't you pipe it to anything, whether it's Matrix or not ? What does Matrix add to this ?
Unlike that, matrix has the concept of Application Services, which are priviledged "users" that can pretend to be any number of users that are bridged over from other protocols.
You had me really excited until this part. I'm moving away from a Macbook soon and my most missed feature will be desktop texting.
Having said that, I bought an old Mac Mini off of ebay for about $100, and it's been working pretty well for the past year or so. It's not an easy solution, but as far as I know it's the only solution for using iMessage on an Android or non-macOS desktop.
What software did you use to make it work?
I installed the bridge and provided as the readme specified all the config options. Upon startup it started spamming requests at my matrix instance all of which were failing. After some tinkering I got it to relay about 70% of the messages from discord to my matrix instance and about 80% of my messages to discord. The server in question was not overloaded but idling at a load of around 3 (8 cores total).
The "common denominator" functionality is a joke that establishes on the minimum I would consider functional for a chat client, not what either Matrix or Discord could offer.
It seems to be getting brought up each time Matrix is mentioned, with a standard reply that it's not unique, and available in XMPP for a while.
Would it be possible to get the Bifrost[2] to integrate with ActivityPub?
[1] https://github.com/ma1uta/mxtoot [2] https://github.com/matrix-org/matrix-bifrost
Bifrost would be a nice framework for writing such a thing - it's basically a bridge server you can plug protocols into as needed, a bit like Bitlbee is for IRC.
About the only thing I miss is a full keyboard for sms & iMessage. And I have an old Mac Mini laying around that could be put to use if necessary.
A good place to get a basic rundown would be here: https://matrix.org/docs/projects/bridges For the puppet bridges (which is what I'm running), you can take a look at this repo: https://github.com/matrix-hacks/matrix-puppet-bridge. You're also very welcome to ask around in #matrix-puppet-bridge:matrix.org about getting the bridges set up. We're pretty friendly in general :)
Anyone know of a bot that will send emails for messages in a room? I basically want to bridge a room with an already existing email list to send out announcements using Matrix.
I'm not sure why every matrix post seems to be met with a lot of negativity here on HN, but I always appreciate the way devs handle it.
Well done!
Responding to SMS encourages people to keep using it.
Try filling out all the characters available within a single message, then replace one of them with something unusual (let's say "ć" for example). What used to fit into a single SMS will now be three.
With that said, though, I don't think it is going anywhere any time soon. Portable accounts/identity is on the spec roadmap and is a personal passion of mine, so moving servers while keeping all of your identity will hopefully be possible in the not-too-distant future.
One of the problems we saw with other protocols when starting Matrix was that often it was hard to pick a good server to host your account, and the project’s “ground zero” server was often overloaded or unavailable. So we consciously made the decision to keep the matrix.org server running to help bootstrap Matrix - but the second we have decentralised accounts we will gently start encouraging users to migrate off to alternatives, assuming that good trusted public alternatives exist. We envisage this to be seamless though; users will just need to click something to opt into storing their account on their new server, and their account will then replicate across the servers where it is hosted. Over time, we might then ask people to stop using the matrix.org server if they empirically are using other servers too, and hopefully eventually get to the point where we have both closed signups on matrix.org and even turned it off. But we are categorically not going to leave any users high & dry.
It’s worth noting that running a massive server like matrix.org is a significant burden and distracts badly from actually building Matrix (especially when things go wrong), so we would love to spread the traffic out as soon as we can.
All this remains scifi for now though, although MSC1228 gives some hints on how it could evolve.
That also sounds like it would solve my biggest issue with running my own server; if my home internet drops or I spill coffee on it I can't talk to anybody until I get it fixed. Having an alternative way of accessing my account would solve that entire worry.
P2P Matrix could perhaps be layered on top of this, using some kind of overlay to route the traffic around such that you no longer have to trust any server. We have some ideas around this, but need to write up them up as an MSC. https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barr... has some thoughts on what the transport could look like for this.
I used to be very enthusiastic about projects like this but AFAICT, decentralized governance ultimately amounts to a contradiction in terms.
Instead, we clearly define the terms under which new folks can join and leave the spec core team, code core team and Guardians in https://github.com/matrix-org/matrix-doc/blob/matthew/msc177... and more formally in https://matrix.org/media/2019-06-10%20-%20Matrix.org%20Found....
So this defines how the wider community can get involved at the top level; and in turn, anyone is welcome and encouraged to submit patches (for implementation) and proposals (for spec) - thus providing a relatively decentralised end result. Our emphasis is more on open governance than decentralised governance for the sake of it.
That said, if Aragon or some similar project came along and convinced us of a better governance model, we’d of course consider it :)
In those days we worry about how to talk with each other. Share info. In fact find friends. Or server.
Whilst the the technology moves on you have E2E in beta and bridge to join other communication technology but is this addressing the more fundamental question of today’s real internet.
<driver of my worry you can skip>
The internet now is fragmented by either firm (Facebook) or country bloc (Eu data and copyright law; china e-wall).
The internet is great to share but also a great way to isolate and record and arrest people. China is a good example of what is great and nasty of this IP protocol in the real world. Social credit system where you are not allowed to sit in train (or lately bus) and suppressing of freedom of speech is hard in the real world but with internet it is so much easier.
A global communication media without firm and country is what we dream of. Yes there would be troll. But we can find ways to anti-spam, may be using lisp like Paul has done. But we can dream to hack our way back to the original free internet.
I use this to measure everything. Can it help us or empower us to program, to hack, to share and just to chat freely
<end of driver>
Can you work in today world?
Have you listened to the call for national internet by supreme leader of china or the cut off of internet link by Russia. Can you work in Eu data privacy and copyright law?
Can you empower individual... is there essentially a tor mode there?
Or even better can client talk to client direct without server so no one can have a record of what any guy (or girl as trinity would have said) said so to arrest him (or her).
Can we interop freely is my real question?
"Or even better can client talk to client direct without server so no one can have a record of what any guy (or girl as trinity would have said) said so to arrest him (or her)."
On Internet as we know it, even P2P does not implement that. Any router you bounce on can be an eavesdropping server. Actually we now know that some of them are, thanks to wikileaks and Snowden.
Server-less is just a guarantee against a narrow range of blocking techniques. To prevent eavesdropping by governments, you need end-to-end encryption. If you have a good encryption technique, using gmail is not a problem.
"Can we interop freely is my real question?"
It took me a while to realize that no technical hackery will ever guarantee that. This is not a technical problem. The incredible power of asymmetric cryptography gave us the dream that we could evade any kind of surveillance, but in the end, a government can always outlaw crypto and arrest people who use it. There is no technical way around it. Using Tor in China may protect your data but will put you on a suspect list.
A government may install spyware on every communication device that are sold nationally (as Syria did on smartphones) and record screenshots or cleartext messages as they are typed.
You can't solve this problem without doing some politics. Crypto needs to stay legal, governments need to refrain from installing spyware and privacy violations need to be seriously prosecuted.
We have the tools to get around surveillance in a state that guarantees some kind of freedoms, or that is clumsy in its implementation of surveillance techniques, but the gap between hackers and authorities have closed in many dictatorships and is very small in democracies as well.
If the problems you mention are of real concern to you, get involved in politics, donate to EFF and FSF.
I think your question boils down to: do you have to trust a server? Today, the answer is yes. In future, the idea is to have a hybrid p2p and client-server architecture where users can participate simply from an app if they want... but if they want to trust a server to also replicate their account, they can.
However, if you are capable of running your own server today (or know a trusted person who can), you can still have autonomy. For instance, there look to be many autonomous servers running behind the GFW.
Not at the moment really. There is a tracking bug for it[1] (which includes the idea of supporting .onion homeservers). The main issue I found when digging into it is that Twisted doesn't appear to have a way to set a SOCKS proxy for requests (there are several open bug reports about it) -- meaning that you couldn't get the hidden homeserver to proxy all their connections through Tor nor could you get the other servers to use Tor to contact the hidden homeserver.
But I am hoping this could be done eventually.
As far as we know, we have addressed all known issues in the original algorithm - which is why we have declared ourselves out of beta. Matrix 1.0 has an entirely new state resolution alg, as well as many other security fixes.
Performancewise there are still issues, but we know what needs to be done to fix them, and this will be landing shortly now 1.0 is out.
But in the end, the onus is on us to make sure there's enough stuff of value in the wider open network that the idea of someone using the protocol to try to create a walled garden is laughable and clearly missing the point - much like running a private email network is somewhat missing the point, or for that matter a walled garden like the web content on old-school AOL.
Hopefully we're on the right track to ensure there's enough stuff of value on the public Matrix network to make participation in it a no-brainer.
It'd certainly be more compelling if it was an actual feature though. Joking aside, federated machine learning could be an interesting approach, if the value that Matrix provided included a decentralised search engine which could help you sift through all the available content to find the chatrooms and communities you're interested in (and hide the ones you're not...)
XMPP has hardly been extinguished. There are something like 8 server implementations and zillions of client implementations. With OMEMO and Let's Encrypt it has has actually undergone a sort of resurgence lately. There are 100+ public XMPP servers out there. Matrix could only hope to be so extinguished...
So I am not really sure how you could EEE Matrix even if you wanted to do so for some reason. Something like this is hard to extinguish. If the network of servers was functional before it would still be functional after some entity pulled their server. Decentralization is sort of the point here.
Matrix is not there yet, cross device signing has to land. But the way it is moving is way more promising than XMPP.
(I also remember that federating with Google was always painful)
Yes, though I would say that decentralised MXIDs (and generally being able to transfer users) is an incredibly important part of this. Otherwise users will have immense inertia stopping them from migrating from a big homeserver that is being used to EEE the system. Luckily that is something that's being worked on.
Furthermore, the openness of the protocol allows free software projects to emerge and exist independent of the matrix company and even the foundation. Such projects can be developed by your contributions and the FOSS community's support until the end of time. One of those projects, for example, is one I started [disclosure] called the Matrix Construct server: https://github.com/matrix-construct/construct and your support of this project is necessary to that end.
If a lot of companies would provide XMPP as a way to contact them, then what Google did would be as silly as taking email private.
Instead, most people are completely used to isolated messaging systems.
So I guss for Matrix, the challenge is to make sure that the dominant use of Matrix remains public. To some extent Matrix is ahead due to the bridging with large IRC networks.
But there are also quite a number of people trying to set up non-federated Matrix servers.
As a concerete example; imagine next month Google announces their own Matrix instance. All gmail users are automatically signed in. The instance works with other Matrix instances. A year after that, Google stops federating anything but bare text to other servers, claiming protocol limitations. They continue to make interaction worse for non-google users until the non-google users have no choice but to join google or loose their social network.
Now lots of people start using one particular Matrix instance for that kind of communication.
Now the popular instance stops federating and people can't reach the companies they want to talk to anymore.
The way Google took over was by offering a better user interface than other public XMPP services.
If Google is obviously worse than other Matrix instances, then people will quickly drop them.
Though XMPP had to deal with a number of paradigm shifts: images, markup, audio and video calls, persistant history, disconnected operation, security, threading, multi device operation. And I probably forgot a few.
Today messaging is much more established. So the matrix team has many more examples of features that are in common use and how other people designed user interfaces.
So it may be harder for Google to win through engineering. They may just break other matrix clients on android.
Honestly I think that we need implementations with smaller RAM requirements. Last time I've heard that it's recommended to have 2 GB RAM for Matrix. That's a lot. I can run VPN, SMTP, IMAP, HTTP, Tor servers along with operating system in a 256 MB VPS. I can imagine that a lot of folks are employing similar low-power VPS for personal needs. Now if they want to launch Matrix, they have to significantly upgrade their VPS. I see no reason why personal home server with few users should require more than a couple of megabytes. I hope that alternative implementations like Dendrite will be better in that aspect.
I don't believe that will ever be possible. Winning with technology seems like the only way to do it. Google wants even IMAP.
As a side-note, I think the copy on the Matrix website could use some love - it's a little wordy and not immediately clear what Matrix is, and why/how you would use it. I've read a few other commenters make the same point.
Are you open to some suggested wording? If so, how would you prefer to receive it?
Proposals for changes are very welcome (although we can't guarantee we'll accept them verbatim); the new site lives at https://github.com/matrix-org/matrix.org. PRs welcome.
We were seriously evaluating Matrix as a replacement for Hipchat (about a few months back) through their hosted service modular.im . We didn't end up going for it because it didn't have privacy controls (there's no concept of an org like Slack) and integration with Auth mechanisms like SAML/Google,etc.
I'm glad that matrix.org is now a very different organisation than New Vector. Hopefully it should allow you to focus on polishing the user facing product, Riot.im
I have already used the re-designed Riot - it's nice from a UI perspective, but there's a lot of enterprise use cases that are missing.
I found this https://github.com/matrix-org/synapse/tree/master/docker
but the last update is 21 days ago.
I guess for now, installing from source is the only option to get 1.0?
Did they fix the barely working and maintained bridge ecosystem (ie, everything other than IRC)?
I'm someone who ran a Matrix server in the past and got burned by it, the announcement doesn't seem to address any of the issues I encountered running my server or make the UI any more discoverable for non-technical users compared to alternatives like Discord.
It feels more like this 1.0 announcement was done so they could have 1.0 and declare to have done it, without actually fixing the glaring issues in the Matrix ecosystem. At this point, the ActivityPub Ecosystem (Pleroma, Misskey, Mastodon) offers more versatile and user friendly experiences. I hope someone builds a chat server on top of AP.
From the fourth paragraph: "...we have deliberately not focused on performance or features in the 1.0 release - so I’m afraid that synapse’s RAM footprint will not have got significantly better..."
"Crippling resource consumption" is an interesting viewpoint, however - I'm federating to the four largest rooms currently available and using <.75g RAM, so unless you consider every modern browser "crippling"...
This was less than 3 months ago on a fresh install based on Docker with no modifications to the code other than instructed in the installation guide.
They also built the thing without specifying a protocol which was the original goal. I once attempted to implement a matrix client and the majority of doc pages on the protocol are "TDB" or "look at server source"
Alternatively, you could take a scalpel to matrix-react-sdk and strip it down to do what's needed.
Maintaining UI SDKs like this is very time consuming, and we're currently putting our time into ensuring matrix-react-sdk (and thus Riot) pull their weight against Slack & Discord etc.
/ˈmeɪtrɪks/
noun
noun: matrix; plural noun: matrices; plural noun: matrixes
5.
an organizational structure in which two or more lines of command, responsibility, or communication may run through the same individual.
"matrix structures are said to foster greater flexibility"
> - Editable messages! (These are in Synapse 1.0 and Riot already, but still stabilising so not enabled by default)
Is there some way to enable editing on a locally hosted server to play with? (In my case I don't care if federated servers don't handle it). I've poked around the code a bit and I don't see anything obvious documented…
"features": {
"feature_message_editing": "labs"
}
experimental_msc1849_support_enabled: true
> so I’m afraid that synapse’s RAM footprint will not have got significantly better, and your favourite long-awaited features (automatically defragmenting rooms with lots of forward extremities, configurable message retention, admin management web-interface etc) have not yet landed
We know that admin management interfaces are critical, and we'll be adding them now 1.0 is out asap.
Meanwhile, I filed https://github.com/vector-im/riot-web/issues/10025 for "hide the upload button" feature req.
Funny that this submission arrives nearly after a project called Desktop Neo.
Rust is an example of doing this very well. Take a couple of release announcements, for example: https://blog.rust-lang.org/2015/05/15/Rust-1.0.html, https://blog.rust-lang.org/2019/05/23/Rust-1.35.0.html. Both clarify what Rust is in the first paragraph.
Anyway thanks. Now has a lead.
That's not to say that we shouldn't have verifiable builds (we totally should), but if we follow this line of logic we will never be able to call anything secure. By the time we have verifiable builds we will have identified other security risks that also need to be addressed.
Apps like Riot are secure compared to the majority of alternatives available today. Arguably we shouldn't use a binary term to describe that, but I'm sympathetic to the idea that consumers think in those terms and that it's not too harmful to use them. Other metrics typically don't see this kind of feedback (for example, you hardly ever see anyone complaining about someone marketing their app as 'fast', even though performance is also not binary).
Even better if these claims could be backed, if not by a formal proof, at least an informal definition of these terms as used in the claim and reasonable justification as to why the models being promoted would not tend to collapse into greater centralization, weaker security over time.
You make a very interesting point about recognizing whether the tendency of a group coordination model is to drift toward one of the poles of centralization over time (not sure I follow that same reasoning with regard to security though).
This comment would have been much more relevant had it been made in the other story about making efficient decisions in a flat hierarchy.