The not-so-talked-about but killer feature of Matrix is that you can bridge other services into it. I'm currently able to send and receive messages from Hangouts, iMessage, SMS, and Slack all from within Matrix. If I'm working on my laptop I can put my phone in my bag and not even touch it for 8 hours, because there's no need. I have Riot running on my laptop with a full keyboard and access to all my communication platforms.
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.
This interests me, as a potential user; but it’s only a killer feature if it’s accessible.
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?
The most mature bridges are available today via a user-friendly appstore if you click on the integration button in Riot. The matrix.org site is intended for developers rather than end-users. If you want to see user-focused stuff, go to Riot.im. That said, there is still work to be done to make the UX around bridging better.
Maybe "killer feature" was the wrong way to put it. Matrix has good support for things like bots and bridges, but those bridges are written by people like myself who are mostly just trying to hack something together and make it work. Over time they're becoming more solid and easy to use, and hopefully at some point it will just be a matter of `pacman -S hangouts-bridge` or whatever.
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.
This interests me too; just this weekend I tried to set up a matrix homeserver with matrixsms, puppet-hangouts and puppet-facebook integration and I got no single integration working. I did try to get it working in docker containers, but still.. I would be very grateful to learn if anyone has a recent, detailed write-up! (I also planned to integrate with Skype and WhatsApp, but didn't get that far)
I personally think horses are far more complicated to "own" (and operate) than a car; however, horses were freely available back when, and cars were not.
>The not-so-talked-about but killer feature of Matrix is that you can bridge other services into it
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 ?
Well, not directly, but for seamless bridging to work properly, your protocol must support being able to mock users easily. Many new protocols simply don't allow that. This means you need to fall back on a protocol session per user (like with IRC, telegram, etc), Bot Api hacks (Discord, Slack), or, worst of all, putting the name of the chat participants into the message.
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.
Is that any use when the bridged protocols don't support mocking users? It might look a bit cleaner to you in your Matrix client but not to the users on the other services
I thought the idea is that there is one bridge running per room. For example a discord room would be bridged to a matrix room by one running bridge. In discord, unless the API allows impersonating multiple users so that they appear as normal users in discord, the bridge couldn't mirror messages from all users in the matrix room and make them look like discord users. Unless I am misunderstanding how it works completely?
Yeah sorry :/ There isn't an iMessage API to talk to, so the only way that anyone has found to bridge with iMessage is to have an instance of macOS running, logged in as you, and to send messages through the iMessage app via AppleScripts and to watch the filesystem for incoming messages. It would be great if there were some API you could use to send messages through, but Apple has worked hard to keep iMessage locked down to Apple devices.
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.
If you're willing to ditch iOS, Android has Messages for Web (an official service by Google) which lets you view/send SMS from any browser and supports file attachments etc. It's pretty great.
Probably not so talked about because, in my experience, it barely works. The bridges I've tried to install were either largely outdated for either matrix or the service it's federating to (Discord for example), or dropped a lot of messages going through (Slack, IRC), or had incredibly annoying limitations (SMS, Hangouts). I don't see how that is a "killer feature" if it's barely developed.
The bridging API in matrix hasn’t really changed since day 1, so unsure how they can be outdated for Matrix. For something like Discord, folks are constantly hacking on the bridge; PRs merged 5 days ago on https://github.com/Half-Shot/matrix-appservice-discord for instance, and last I checked it worked relatively well and targets the highest common denominator of functionality between Matrix and Discord. Lost messages sounds like the server is overloaded (certainly there is performance work still to be done). Unsure it’s fair to say that it’s barely developed...
Well, here is my experience with the discord bridge:
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.
Is there a way to bridge Matrix with ActivityPub? I see MXToot[1] as an option, but I'm hoping for something a little less Mastodon-specific. I'd like to be able to bridge Matrix with Mastodon, Hubzilla, Peertube, Pixelfed, and the other ActivityPub federated services that are popping up.
Would it be possible to get the Bifrost[2] to integrate with ActivityPub?
There isn't a particularly sophisticated ActivityPub bridge yet, but there's also nothing stopping someone from writing one.
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.
It very much depends on the kind of bridging you want to do and on the service you want to do it with. My iMessage bridge, for example, is a "double puppeted bridge", meaning the people receiving messages from me via iMessage don't even know I'm using a different service, and they show up in Matrix as if I got a message from a matrix user. It's also possible to bridge the contents of an entire room (on, say, Slack or Discord) into a matrix room. The two rooms mirror each other and anyone who talks in either room has their messages relayed to the other.
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 :)
I'm also really interested in setting up a bot/bridge with our Matrix server.
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.
Huge props to the Matrix team! It's given me back ownership of my messages for which I am very grateful. Simple integration is a really killer feature!
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.
I wouldn't call it bad, but I would call it incredibly expensive if you're using non-English alphabet.
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.
I'd bet he's implicitly expressing his concerns about SMS's vulnerabilities in terms of security, especially compared to other, more secure alternatives.
I am thrilled to be one of the newly announced Guardians of the non-profit foundation. I'm happy to answer any questions people may have, though bearing in mind that I'm going to be a little distracted for the next while until my son goes to bed.
Are there any firm plans for what happens to the matrix.org matrix server in the future? I worry that all the friends and family that I've been convincing to register an account on matrix.org are going to one day be asked to migrate their account to somewhere else, and that feels like it could be a big bump in the road for the non-technical ones.
So, New Vector (the for-profit org that the foundation has just spun out of) operates the matrix.org homeserver on behalf of the community.
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.
Yup, to echo this: the matrix.org homeserver isn’t going away anytime soon.
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.
Thanks, that's very encouraging to hear and exactly what I would hope for.
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.
Where can I learn about your proposed path to decentralization of control, custody, costs and accountability given that it is, (as with any novel initiative), it is currently centralized on the dozen or so members who form the core of your foundation.
I used to be very enthusiastic about projects like this but AFAICT, decentralized governance ultimately amounts to a contradiction in terms.
We don’t have any plans for formal decentralised governance at this time; it’s hard enough making rapid progress with an open standard with ~12 people helping steer it without opening it up to the whole world to bikeshed.
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).
First, for the record, I find it unfair to compare EU copyright laws to China e-wall. China blocks connections. People who block connections because of GPRD are people who oppose it, without good reasons IMO. To be in compliance, don't invade people privacy. That's it. Things only get complicated if you do.
"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.
> Can you empower individual... is there essentially a tor mode there?
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.
This is exciting. Glad to know they're focusing on making a stable, secure protocol, and that development is going strong. Great job and keep up the great work!
there are some big security and performance holes in the DAG resolution algorithm, but hopefully more funding will give them the resources to revisit some of their dangerous assumptions.
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.
Honest question.
What's stopping Matrix from being adopted by, say, Google or Facebook, and then pulling a XMPPEEE?
Imagine Matrix gets really popular, more even than Discord. So they offer their own "version" but add features like free 250GB on Google Drive or things like that. After they get everybody on board they do what they do best and cease control of it.
We're obviously very aware of this risk, and one approach is to try (as the Foundation) to steer uptake as best we can to ensure that no single 800lb gorilla ends up adopting Matrix and smothering it with love(?), even if they have the best intentions. So if Google did suddenly start using Matrix, we'd do everything we possibly can to ensure that at least one of Microsoft/Facebook/Amazon/Apple/Samsung/etc jumped on board too, to try to balance things out and ensure that the value of participating in open network outweighed the risk of proprietary extensions leaking in.
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.
Very interesting. I wonder if there's a killer feature that would appear when you follow that line of thought. So even if adoption looks like 60~70% users and 30~40% enterprise, if you're indispensable to either of them, it would still prevent a take over because of the network effect. And the fact that you have an API that developers can trust would solidify the position even more.
If that feature ever surfaces I hope it doesn't involve blockchain or machine learning.
Well, the feature might just be one of ubiquitous interoperability, much as email provides today. Particularly in an enterprise context: if you want to do some kind of realtime collaboration with someone, you might just reach them directly via Matrix rather than sending them an Email with a link to Slack/Zoom/whatever.
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 was not really extended by Google in any way that mattered. Their federation hardly even worked even in the beginning.
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.
My experience with Matrix compared to XMPP, is that Matrix is way ahead in usabiliy. I wanted to get people to use XMPP for years, but I always found too much lacking.
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)
> 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.
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.
Matrix is an inherently decentralized system. You can run your own fully featured instance on your own property. If the company behind Matrix is acquired, the foundation being announced here today stands in the way of the intellectual property becoming a toxic liability to your own use. This is very good news today.
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.
One problem I see with XMPP is that there is a lot on isolated use and not a lot of public use.
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.
Matrix is not as popular as email, again, what prevents Google from taking Matrix and EEE'ing it to death?
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.
What if google offers a better interface than most matrix instances? Given, Riot isn't exactly a high bar to meet so it should be possible with minimal resources.
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.
We should launch more alternative servers and avoid central big servers as much as possible. There's no reason to buy Matrix if they don't have a lot of users.
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.
These "what if" questions will always be relevant because of the nature of big (and small) tech companies. Creating a monopoly, data mining, and controlling the flow of information are simply irresistible - if not necessary - for tech companies like Google or Facebook. The only real solution is to have educated users that care about their privacy and security. In that case, if Google turns a free, open source protocol into a surveillance machine, the only solution is to step away from it and not use it. We cannot stop big tech companies from creating user-friendly, tempting malware.
Or even dendrite. The Ruma author said on Reddit that they are waiting for async/await to stabilise in Rust before they continue working on Ruma because they'd likely need to rewrite it later if it was written without async from the start.
Yup, I've been following the Rust discussion too. I am quite excited to see this happen -- as someone who tried to wrap their head around tokio two years ago I'm glad something more akin to other languages is around the corner.
Matrix has been on my to-do list for some time - I'm interested in exploring it as a replacement for team Slack.
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?
So we just reworded some of the site, but agreed it needs more love. We're (hopefully) much better at writing communication protocols than describing them to a broad audience.
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.
Did 1.0 fix the crippling resource consumption of their "reference implementation" or are they still tinkering on something half done?
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.
> Did 1.0 fix the crippling resource consumption of their "reference implementation" or are they still tinkering on something half done?
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"...
I did run a Matrix server for a while. It continously consumed between 4 and 6 Gigabytes of RAM with about 5-10 users active at all times. Joining on of the larger rooms took 3 days, 2 days unil I didn't just receive plain errors and then another day until it would let me open the room without timeouting. While joining large room sit consumed almost all available CPU and several database connections for IO.
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.
Matrix works great once setup but they really need to work on install process. All the "easy ways" are unofficial. Some of the clients, like Riot, appear to be really well written, but the server itself gives me pause. Just from looking at the configuration, the codebase appears to be a mess.
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"
the client-server API has been stable and fully docced since early 2016, which explains why there are so many matrix clients out there. you must have been attempting a long time ago...
What's the best option available for chat embedding right now? E.g. if I want to build Facebook's chat feature or Fiverr's Inbox feature and have it integrated into my main web app.
We haven't published an official embedded chat SDK for Matrix yet, but there are a bunch of options from the community. https://gitlab.com/sanlox/tangent is one, which is very new and immature but looks to be headed in the right direction.
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.
It's unfortunate that "Matrix" has nothing to do with actual matrices and that "Synapse" has nothing to do with neuroscience or even neural networks. Makes me want to name my next matrix (actual rows and columns of numbers) library something like "advanced telephony and messaging" but a stupid name for a stupid name makes the whole world utterly ungoogleable so I'll refrain.
I note the announcement says this about things coming soon:
> - 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…
On Riot/Web, you’ll need to enable it in labs settings (in config.json) - riot.im/develop already has it turned on. On synapse there is a config flag called experimental_aggregation_support or something, but it’s optional (it makes reactions/edits more efficient).
that's the one :) Editing unsent/sending messages should land tomorrow, and then the feature is pretty much done. Sorry for not having the right config details when answering on my phone yesterday!
Are there decent Admin tools for hosting your own homeserver now? Last time I checked it out I could neither disable file uploads completely nor remove users from the server short of editing the database.
you can disable fileuploads completely from the config (set a max filetransfer size of 0). however, we still need to build a proper admin web interface for it. the admin API is improving however, but it's a matter of hitting the API with curl currently (for removing users etc).
Setting the max filetransfer size to 0 still showed the button and allowed uploading of 0 byte files. Probably just a UX oversight but annoying nonetheless.
Not having a simple to use admin or even moderator interface makes Matrix unusable for my purposes for the time being.
right, understood. this is why the original post explicitly says:
> 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.
https://matrix.org/docs/spec/#matrix-versions. Matrix 1.0 is the blanket term for the set of various specific API releases we just cut: CS API 0.5 etc. We could have bumped them all to 1.0 for the sake of it (and perhaps we should have), but it felt cleaner to let each API version evolve independently, and instead say “hey, as of this set of versions, we consider the protocol stable”.
My guess is that fewer than two people reviewed it before hitting publish. For a project with the level of ambition that Matrix has, when they release 1.0 I would expect more attention than that. Just my two cents though.
Blog posts that you can reasonably expect may be shared in places where context will not be known should start out by clarifying what the subject of the post is.
Should it be in the first thing to do is to explain who you are and what your project is doing? Not everyone is in the matrix or everyone are but not woke up. Need to say.
Checked my history. Before I opened the matrix link in the top left iirc( mobile)
It took me to the try now page. Maybe not, but that’s where I ended up
At least I learned a lot from the github issues their hacker opened. Wonder if there are any surviving archives of those that the repo owners did not delete in shame.
They were for signing the Debian and Ubuntu packages of the matrix.org Debian repos. But Debian also has its own packages for matrix-synapse (with the latest version usually available in experimental) -- so you could just use those instead.
End-to-end encryption is all well and good but until the app stores provide verifiable builds I think promoting messaging apps such as Riot as "Secure decentralised chat/VoIP" is unprovable and therefore somewhat misleading.
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).
Words like security and decentralization are indeed not binary, but referring to them as being on "a continuum" or something similar is not particularly helpful either. I wish I saw more application of them as modalities, such that they refer to not to a perpetual state but a systemic tendency toward an ideal (if asymptotic) structural equilibrium over time, as in "X tends toward greater decentralization", "tends towards greater security" over time.
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.
It's unfortunate that you posted this comment in a nearly drownvoted thread under a story submission about a product announcement.
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.
I disagree that it’s totally hopeless but OTOH verifiable builds sounds like an awesome idea to increase security. Still, at the end of the day you always are trusting some entity or machines...
Fdroid looks to be heading in the general direction of verifiable builds where possible. Failing that it’s really not that hard to build yourself. But in the end you have to be trusting trust somewhere...
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.