I tried to adopt matrix for our small business and here is summary of my experience.
- Synapse is very resource hungry even for a small server
- Synapse creates a gazillion of TCP connection and keep them open, it was a real problem for my ISP router (SOHO router for 1gbit/s) and it took a very long time to debug, be sure to limit the number of TCP connection on the server
- Synapse is hard to get a good idea of the health of the server, the federation can break without warning
- If the federation broke for some reason, when submitting messages, they will show as delivered, this was one of the major problem for us
- Encryption is very cumbersome to get right for non technical users, there should be a server wide option to make it "easier but less secure". Even for me, it was hard to get rid of a warning popup about some device error.
- Group VOIP is hard to setup, it should be as easy as discord to be viable.
- Webhook is really hard to setup too, I want to be able to right click a channel and "copy webhook URL" to be able to post to it with CURL (discord has that)
- Globally it is very slow when joining federated rooms, it can take days to sync 500+ people room
In the end we just use discord, it's free and do the job. Of course they can read our messages and this is a problem for me as I am for privacy and encryption, but it works for everybody, it is friendly and easy to use.
I will keep a close eye on matrix and try to adopt it again, but right now it is not usable for us.
We’ve been running a Synapse server with quite a bit of federated rooms, even larger ones like you mention. Never noticed a single issue like this that I recall.
I wonder if the reason is that we’re doing whitelisting, instead of federation with everyone by default. The whitelisting is quite liberal; I’ll add a server as soon as I’m in a conversation thread with someone from that server, or just want to see their avatar. Sometimes when I’m waiting for something else I’ll just scroll through a room and add a handful of servers. Essentially this is my proxy for only federation with “legit” servers and avoid being DDoSed.
> there should be a server wide option to make it "easier but less secure"
Disagree. Sure, UX can be improved, but compromising here defeats the purpose of why we’re doing this in the first place.
Another one of mine:
- E2EE seems complex to implement and very few of the clients implement it fully and properly.
This is the one point I think needs to be resolved before Matrix can be ready for wider adoption. It’s kind of pointless without E2EE, or if Element is the only client that can work for all rooms and messages.
I didn't whitelist anything, maybe that was a source for issue.
> Disagree. Sure, UX can be improved, but compromising here defeats the purpose of why we’re doing this in the first place.
The thing is, as I ran my own server in my office, SSL (with no E2E) is already a good privacy. And even with that setup, the server users got "harassed" by the UI asking them to sync devices keys.
For many users, a single prompt about security is enough to discourage them.
If I try again to "convert" non technical people around me, I'll try to document properly what is wrong in the UX and experience. (but maybe it will all be fixed)
> I didn't whitelist anything, maybe that was a source for issue.
Should have mentioned: I think my approach works fine for single-user or small-closed-community servers. Nobody should do this on servers with public rooms and/or open registration as it will lock out minority servers and cause further centralization.
Your problems are with synapse. I had a similar experience with it in 2019. Dropped matrix for a while and started using Dendrite in 2020.
It still lacks features compared to synapse but I'm happy with the performance. Notifications are sorely missing but I think the PR to add them is finally ready to merge.
Give it a year or two and you'll have a full featured matrix home server that can run on a raspberry pi.
Official server should have never been in Python anyway. Not a proper language for the network server. They should have adopted Go or Rust servers as the official ones, and pour resources there instead.
I sympathise with your aggravation but they're balancing doing that while not trying to migrate the existing user base too early and keeping supporting people with production workloads.
Fundamentally they've 'lucked' into a 'nice problem to have' type situation here, and I get how annoying it is - I was freenode staff during a period where the irc<->matrix bridging was unexpectedly popular enough to be a 'nice problem to have' for everybody involved and the author of the blog post we're discussing probably remembers some sharp words on my part during the process - but frankly on balance I'm mostly impressed.
Heads up for anyone thinking about trying out a homeserver or two. To my knowledge there is no way of moving from one piece of homeserver software to another. So for example if you start with conduit you're stuck with it. I think there are a bunch of plans all over the place to mitigate this, but I don't think they're there yet.
When was this? I suspect most of the problems here are due to users joining lots of big federated rooms, which will use loads of resources irrespective of how many local users you have. This is also what Fast Joins are trying to improve (at least for join speed) from the original post. Likewise the matrix-hookshot webhook bridge.
Tried Matrix (and Synapse) the 3rd time a couple of months ago and gave up after a few days.
Joining any larger federated room took days or did not complete at all. And then the messages were also delayed for quite a while. That must be the stupidest design I have seen.
If it was not so messed up, Matrix probably would have become huge by now.
I agree with others in comments, devs should have probably improved the federation and written the official server in some compiled language and provided it as a single binary.
It might be worth reading the actual post to see how we're fixing slow joins.
In terms of the language: it's not Python's fault at all. Instead, Synapse baked in a bunch of naive assumptions (being originally a prototype) which we have been steadily fixing... while also adding features, which pulls in the opposite direction. Given a choice between a featureful server that's resource-heavy (which we can then make go faster later) versus one which lacks the features to compete with centralised alternatives, we chose the former.
Sorry, it was not clear from my comment. I do not blame Python. Of course it was design/code issue.
I just think that having a single binary would improve adoption. I like projects that provide a single binary. Without the need for docker, or setting up complex environments.
I kind of disagree about the language. Not because I wouldn't want an implementation in a fast language, but because I think a well designed chat system must be performant even if your language is an order of magnitude (or two) slower than it has to be. If you need to start throwing brute force at it, something's up with the design. Get the design right first and demonstrate it is right by showing that even a slow system has no trouble with it.
Sorry, it was not clear that I do not hate the language (I write in python myself) and I fully understand that it is the design choice that is the problem. I simply think that having a single small binary can be advantageous for adoption.
I'm running a small (at the beginning it was completely public, now I'm keeping an eye on registrations) homeserver with synapse for a few years - I really like Matrix on a conceptual level and I'm happy that it exists even through it's not perfect it works pretty well mostly. I don't want to be too harsh because it's the best decentralized alternative for chat at the moment and it's open-source and there is a lot of progress but damn' it was a pain in the ass to run that server... we solved our problems mostly with throwing resources and memory on the problem... it's a nice tour de force if you want to learn about debugging distributed systems but it's nothing to install somewhere and just keep running.
synapse is quite a mess and there are a lot of hidden footguns if you just run a server - this is just the tip of iceberg to keep the postgres database somewhat sane: https://levans.fr/shrink-synapse-database.html - lot's of other issues in the issue-tracker where you can just scratch your head.
bridges are all subtly broken - the xmpp bridge is horrible and broke in so much interesting ways that I'm not going to touch it ever again - telegram works okay most of the time, irc-bridge also have some warts - but it's easy to criticize from my chair and probably unfair to talk so negative about it here but it's often buggy and broken for edge-cases - it works most of the time pretty okay but it's quite a mess to get a mental model for the code and so it's difficult to debug things.
moderation/spam/etc.pp is all hackable but not there out of the box - it looks and feels like mostly quickly hacked up nodejs code that at least for us exploded in all kinds of interesting ways. https://github.com/matrix-org/mjolnir writing 3tb of logs in a few day and eating memory like crazy for instance. You have to babysit it and there is no simple ui for anything.
So it's powerful but requires quite a bit of dedication and patience to get right. It's a full blown distributed system and often state is all over the place and once you make a mistake it's difficult to impossible to get that thing do work correct again without starting over.
But there are so much promising projects that I'm confident that these issues will be resolved and it will only get better but in my experience it will break badly on all kinds of edge-cases - the mentioned xmpp-bridge created usernames that can't be deleted via the http api for instance. someone bridged 1000 channels via our telegram-bridge and there is no code to remove those channels - you have to code something up in python for yourself. irc bridge kicks you after 30 days idle because they can't handle the connections - freenode (before the takeover) said it's not them - maybe single threaded nodejs is not such a good idea for that.
Could I do it any better and delivering? Probably not. But except some adventure and if you want to deploy it for an org carefully test any assumptions you take for granted. It's cool but it's also kind of quick'n'dirty in a lot of ways. Still better than anything else I'd use it over any megacorp messenger anytime but maybe don't switch your family yet.
But for using it you don't have to care - and there are great projects like https://github.com/spantaleev/matrix-docker-ansible-deploy that solve most of the problems out of the box and mobile clients and web clients and E2E crypto also works really well.
I've looked into putting Cactus Comments [1] on my website, but I kind of had to can that plan when I found out that it requires the slow and resource hungry Synapse homeserver implementation at this point in time. I was hoping to use Conduit or Dendrite, but those are simply not ready yet.
In my opinion, the biggest problem with the current Matrix platform, especially if you self-host, is the server implementation. It's not buggy, but it's just awfully slow. The "dpt of ping" [2] section at the bottom of the weekly Matrix updates show that five seconds of latency between servers (measured by basic ping bots) is far from uncommon. The latency is still significant in the non-synapse version of the graph, but it's much better already.
With the speed new MSCs are accepted every month I don't think any alternative server stands a chance at catching up to Synapse any time soon, and I don't know how I feel about that. Yes, Matrix is an open platform with an open source spec, but it's effectively impossible to develop an alternative backend implementation with the way development is currently done, unless you've got a lot of developers and money to throw at the platform.
I'll probably look into Conduit again in a few months, hopefully the project will keep up it's impressive pace so that it's useful for my purposes.
I'm running Synapse and Cactus chat on a 1gb memory, 1 vCPU Linode and it's just fine.
Given, I have a small blog (ie low load on cactus), but I'm in many (15+) medium sized (100-1000 members) federated chats and it's just fine on a day to day basis.
There are some limitations tho:
- I can't join large rooms (2000+ members and whatever number of servers that entails on average)
- Initial sync (first time log in on new client) is crazy slow - syncv3 will hopefully fix this
My definition of not being resource hungry is being able to run on a 1gb, 1 vCPU VM - however you and me might have a difference in that opinion
I think the initial sync issue is one of the worst problems, because someone joining in to leave a quick comment will be waiting for the system to synchronize. You can run the system on 1GiB/1 vCPU, but that comes with a performance penalty.
My instance of Synapse definitely can't join any matrix.org chatrooms, no matter how hard I try. Even rooms with a few hundred participants are awfully slow and leave scrollback state a broken mess. When I tried to join the main Matrix channel, both of the CPU cores I had dedicated to Synapse were pinned for at least half an hour, even after I tried to cancel joining the room!
I hope sync v3 lives up to the hype, but I'm wary. Synapse's Pythonic base seems ill-fitted for an instant messenger backend in my opinion, and no amount of protocol trickery can work around that.
It's not that I think the 1GiB is necessarily that excessive, but Dendrite and Conduit are blowing Synapse out of the park in terms of performance, to the point that I'd almost rather see the Matrix folks dedicate their development efforts more on bringing Dendrite up to speed than to expanding functionality.
Well, you can try sync v3 today via sync-v3 proxy (which is written in Go) and Hydrogen, as per the video linked in the post. It solves the initial sync problem completely; it’s not hype; it’s real.
The main thing that bogs down Synapse is if users join massive federated rooms and you end up replicating huge amounts of traffic onto your server. So we’re working on that too via Fast Joins and better-than-full-mesh federation for P2P.
I once installed Litecoin Core (on Windows 10) on my desktop PC. I had Comcast (branded as Xfinity) broadband, whatever speeds my region and apartment supported. I had a 1TB monthly limit before throttling. I lived in the east SF bay area. I downloaded Litecoin Core software at the beginning of the month. I got dial-up speeds for the rest of the month. I got a 5x average bill that I had to negotiate down. Nobody on my server even cared about the federated rooms, it was just me trying to give them more flexibility.
Allowing federation with Matrix has the same issue, and I know it's being addressed, but I want to hammer this home. Self hosting means normal, poor people, too, not just EU government entities and Upcoming Big Tech partners. I know you know this, but every advocate needs reminders here and there.
Totally agreed. Our goal is to support self-hosting on an RPi on modest broadband... or just to self-host P2P on the app itself. We are categorically not optimising (in the medium/long term, at least) for requiring massive hardware in order to self-host.
> I think the initial sync issue is one of the worst problems, because someone joining in to leave a quick comment will be waiting for the system to synchronize
The initial sync issue is only a problem for large accounts which have joined many rooms. Cactus comments creates a guest user for non-logged-in commenters, and an empty guest account is pretty much instant to load in my experience.
I have been using matrix for quite a while now, and managed to get the people I write the most with on it too!
Back then I rented matrix hosting with modular.im (now called ems) once I noticed that I did use Riot/Element on a daily basis, and the latency of matrix.org servers was too big for my taste, combined with the lack of online status display.
Now that dendrite is starting to finally mature, I will probably switch to hosting it myself to save some costs.
Main things stopping me are the possible headaches around domain names and federations: How hard is it to move to a different hoster once I have an instance running?
I read in the documentation that things can become problematic if I don't carefully backup parts of my dendrite matrix instance. What would happen if I (or rather my hosting provider) lose my files and have to setup my matrix instance from scratch, will my domain then remain blocked on the federation, even when I still have control over the domain?
It's not that I don't do backups, but I'm curious what would happen in a worst case scenario.
I believe federation recovery should be possible assuming you have access to the server's signing key. Without it, you'll probably run into conflicts.
You'll definitely have problems with missing rooms, missing user encryption, the lot of it. I think it should be possible to re-create and re-import signing keys onto a new server, but I wouldn't rely on it. You'll probably end up with broken clients for ages. You'll also definitely run into loads of clients 404ing on your server, trying to download media that no longer exists. Personally, if I'd lose access to my server, I'd just start over with a new domain and get my backups in order that time.
If you have backups you can recover, you can get everything up and running painlessly by pointing DNS to the new server and waiting for DNS propagation to finish.
As for moving between hosters, there's a tool for that: https://ems.element.io/tools/matrix-migration; it's a tool that'll invite your new account into every room your old account was part of, transfer profile pictures and such and optionally kick the old client from rooms after migrations. That'll only help if your new account is on a different server, though.
I'd also like them to name homeserver.yaml in the Synapse Debian package to something akin to homeserver.example.yaml so that updates don't make me have to diff changes to figure out what I need to add (since accepting the package version overwriting my homeserver url is unacceptable). But that's neither here nor there.
I asked about migration guide in the chat a couple weeks ago. Found 2-3 on random internet sites that made it sound too easy - so I was expecting some gotchas to be mentioned, but got crickets.
I will be trying to migrate to a new server at different host/data center in about a week - hope it's as simple as the base guides I bookmarked make it sound.
Definitely would love an official guide and some kind of check things script maybe - but we'll see, maybe it's not too hard - dunno yet.
I think this scenario isn't handled too well, and I'm afraid servers that have seen your previous server will refuse to talk with it, and continue spamming the old address. Make sure to backup your server's private key so that you can properly leave rooms. It's usually better to leave all rooms prior to decommissioning a server, too, but I am not 100% sure it would prevent that issue.
Really get good vibes from the company, can't quite put my finger on it... Never hearing back from them about a job was a bigger disappointment than usual.
Problems with synapse are true, but it was a good compromise to push out an early implementation so things could get rolling quicker with getting people to actually use the clients.
Just when I get used to some issue/missing feature in the clients, they seem to fix it.
And in general I trust and know that decisions with the spec are being made carefully.
I use it for an intimate chat server with never more than 8 users, so I can't speak to some of the problems. I can just say the trajectory itself for Matrix is strong. A good effort to fight slack and discord. Wish all the discord servers people use were matrix instead.
> And in general I trust and know that decisions with the spec are being made carefully.
This is one place where I strongly disagree.
Almost all features have "We will add encryption later" which is not a way to build a secure messenger. Stickers, polls, profiles, spaces, relations, reactions... they all start with and unencrypted version with the promise that "encryption will come in a later MSC". They should really take "secure" out of the tagline until they actually add E2EE for all of these features. Basically all clients allow users to use these insecure features in encrypted rooms with no warning at all.
And I constantly see hacky quick fixes get accepted because "we need to do something", "no clear use case for $X" (even when there is) and "N other MSCs depend on this so we'll merge it in and deal with a proper solution later". For example the relations MSC just got merged with support for only 1 relation per message even though it is clear that editing replies would be a problem with this system.
I love Matrix and hope it does in fact unify messaging but I think "carefully" is not the way to describe how the spec is progressing. More like "shoved in whatever direction is needed to implement the newest Element feature". Maybe that is for the better, we do need a featureful protocol to get users after all, but personally it irks me the wrong way. Especially when security and privacy are ignored "for later".
This is a really interesting point. We deliberately built Element to help prove the spec and define its direction (including ensuring it has decent privacy properties), to avoid all the failure modes where folks build a protocol without a real app or product in mind and end up with something which tried to be all things to all people and useful to none.
While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec. And judging by some of the rest of the thread, we didn’t so well even then; it would have been even worse otherwise.
I think it is helpful to have Element to test out the spec. I think the problem is that the "bar" for accepting features is too low for my taste.
> While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec.
I get the decision. But it leaves a sour taste in my mouth that Matrix advertises itself as "secure" but almost any user is leaking sensitive information without knowing. I suspect that 95% of users would be surprised if you told them about the number of things that leak in E2EE rooms. Probably the better approach would have been to skip pushing E2EE as the default, and disable all insecure features in Element for E2EE rooms (or have an explicit opt-in). The marketing team would hate this approach but it least it is honest and safe.
There isn’t a marketing team for Matrix, unless you count me & the dev advocacy team. I actually have another (big) blog post called Metadata And Matrix which attempts to enumerate the privacy properties we have today to try to educate everyone, and how we’re improving it in future - will post it shortly. Agreed it could be better, but if you’re on your own server you are in a pretty good place.
I want to voice strong agreement with kevincox. I use an encrypted Matrix room daily and had no idea that reactions, relations (does that mean that edits are in cleartext??), etc are completely unencrypted. I've read a little bit of the spec (though clearly not very much), I've written a bot, I've patched the Element desktop client, I've even been working with a JSON export of my message history and didn't notice—perhaps I should have, but my point is that it's not obvious at all, and users SHOULD be proactively made aware of what's encrypted and what's not.
Sending things unencrypted that users have every reason to think are encrypted is extremely irresponsible. And I assumed, as I think is perfectly reasonable, that everything in an E2EE room is in fact end-to-end encrypted. I'm very disappointed to find out this way that it's not (and won't be for the foreseeable future), and I don't see any justification for failing to making users aware of that.
All that said, I love Matrix, will continue to use it every day, and am hugely rooting for the success of the project. Thanks for all your hard work on it!
Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions? One could encrypt the emoji itself, but it doesn't seem like a massively sensitive datapoint in its own right. (That said, we will encrypt them eventually, but it's just not very high priority given the fact it doesn't practically feel very high impact, relative to all the other things we could be doing to improve Matrix).
> Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions?
Why couldn't the client simply count the number of reactions?
I can't imagine it'd be a performance issue. After all, if you didn't have reactions you'd have a bunch of in-band "+ 1" comments; if such a thing would bring down the server then I'd assume you'd have much bigger problems.
Just chiming in as a plus one updoot etc. here. I understand the balance of complexity and resources needed to make essentially meaningless data encrypted, and I fall firmly on the side of "do it anyway". I can explain to users that things take longer because they're encrypted, I can't explain to them why they have general sentiment analysis derived from emojis used over time intercepted by <X> in a room they thought was secured.
If communications are generally encrypted then that absolutely is surprising. In that example all the clients could be counting the emoji bs or whatever individually without any server even being aware of the message content.
Very nice blog! I was looking at Signal with their closed-doors development these days, and you have no idea of how much a post from time to time detailing the progress makes means for someone willing to contribute.
Some of the most exciting features for me are:
- Dendrite: we really need some efficient replacement for Synapse
- Sync V3 and Fast Joins: it will erase the feeling of slowness when I open the web client
- MLS: It will help to scale E2EE groups [1] (remember the 256 limit in WhatsApp groups ?)
- P2P: We received this year a first glance of what a network of Bluetooth Low-Energy devices can do with the Apple Find My network. A true p2p instant messaging system is not just a dream anymore.
- Metaverse, file storage: I have no idea if they will accomplish any of them, but having a new non-profit working in the field is always welcome.
> "Social Login via multiple SSO providers (MSC2858) - almost 50% of new registrations on the Matrix.org homeserver now use social login!" Interestingly the split of SSO usage is roughly 70% Google, 12% GitHub, 11% Apple, 6% Facebook and 1% GitLab.
Congrats to the matrix team, really great work. However, I'm a little confused by the excitement around "social login". Why is it such a great thing? Aren't you just giving someone else power to shut you out of Matrix? We hear so many stories about lives ruined because of arbitrary (often automated) account locking that I just don't understand why anyone would risk using social login at all.
The excitement purely comes from the fact it makes it way easier for casual users to try out Matrix (even at the expense of then being beholden to the SSO providers), and it forced us to dogfood and land first class SSO support :)
If someone uses a third party SSO provider, can they create recovery codes to mitigate the risk of having their account closed by that provider? That would be a nice feature to prompt such users to make use of, once they've tried Matrix out for a while and have built up some chat history and connections they wouldn't want to lose.
This seems like a flippant insubstantial criticism. Facebook is one of many many options—including first-party username+password auth.
It's more like, "Welcome to our federated decentralized service. You can log in with your Facebook account if you want to." Which doesn't sound like a bad thing to me.
More choices for users is usually a good thing. If users' choices have bad consequences, that's not Matrix's fault. Though maybe Matrix should warn people that if 3rd-party cuts them off they'll be locked out of their Facebook account too—choices need to be informed!
android element. why can't we forward a text or a photo or anything? i have to "share" and then select a chat or a room to forward to. any reason for this issue to exist? i personally never joined whatsapp and quit telegram during the last mass exodus to telegram.
In the sense that they take almost an entire screen, yet do not convey information comparable to an entire screen's worth of text.
The hex of these types of graphics is that they don't actually say a lot at all beyond "one thing is slightly bigger than the other", or "the thing is a bit faster now".
There are things that are easier to convey with a picture than with words (like the how much bigger the sun is compared to the earth, "really really big" doesn't quite cut it), but this is not such a case.
A big thank you to the entire matrix team. You've tackled a big problem space and made great progress. Here's to a great 2021 and and even better 2022!
Everytime I’m fighting with myself to not be sarcastic when speaking about this issue, but I want to say I have hard time believing that Element could we a main communication platform for anyone without this being fixed. It drives me mad, and I have just two people to communicate with!
Weird; the reason we haven't prioritised it is in that in practice it doesn't seem to be a big problem? You don't get push notifs while you're active in the app itself, and the fact that i get push on my phone while also reading on desktop almost feels like a feature (I often read the msg first via push on phone before then going and hunting on it desktop, especially as Element Web's notification panel needs love).
It's not a problem; it's an intense frustration. It is irritating to be told "here's a new message X" at your desk, only to see and hear the same notification "new message X" on a phone within a few seconds. Your phone even vibrates, as if to demand your attention and chide you for not acknowledging the message. It's an additional distraction when we're all short on time.
My previous work used a system which queued notifications for delivery. The logic was something along those lines:
- send notifications for urgent items, e.g. incoming calls, immediately to all devices
- if there are no active devices, send all notifications immediately
- otherwise send to all active devices st internally along with testers.
I ended up tweaking this; it took us a few tries to get it right. I'd be flabbergasted if Facebook messenger, iChat, discord et al haven't done something similar.
I can second this, I love being able to answer quickly from my mobile (I type [actually swipe] faster on mobile). It's also amazing how the push notifications clear when read somewhere else, this is not to taken for granted, it's not implemented on most other chat apps and it's a huge advantage of Element imho, sometimes it's buggy¹ but it's easy better than not having it and only Telegram is better in this regard from my experience.
Maybe you have a different use case for it, than my problem. It seems you are happy when you get a notifications on mobile when web client lost focus. My case is that it notifies me all them time, even if when client is fully in focus and I actively have a conversation.
Often when my phone is left behind somewhere in the apartment, my SO will ask me to do something with those notifications, or just will move my phone away from her (and/or my tablet).
BTW it seems that other communication devices did it right. I just tested Google Chat, and I remember that I did not have this issue neither with Slack.
I've been attempting on and off the last few years to spin up a non federated matrix server in my homelab to make an alternative to discord for my friends. I run into some various issues every time. I'm pretty good at tech, but for whatever reason the barrier to getting a working self hosted matrix server seems too high for me.
I really would like to move to an e2e encrypted discord alternative. Maybe someday I'll be able to do that with matrix, when ether it gets easier, or I get smarter.
Have you seen this repository[0] that automated most of the configuration? I have a similar goal to you (get family off of Google Chat), and I was pulling my hair trying to manually set things up. Now the hard part of getting them to migrate...
I was just looking at this yesterday, actually! Thank for sharing. It looks very promising. I think my main issue is my only hypervisor right now is unraid, and I'm a bit hesitant to open ports on my firewall directly to a VM on unraid since it's also my personal NAS (I think there's security questions there, even if it is just a VM on it's own vlan? Not sure how possible VM escape is on unraid with this playbook).
Can I use separate identities in the same Element instance yet? Especially with Spaces I feel like this is an obvious feature where it should be easy for people to protect their privacy by using different accounts for different hobbies or peer groups.
I would love to finally be able to use my employer's chatrooms with my real name, the animal rights group with my one pseudonym and the techie chat with the other one.
Fluffychat allows multi-account logins on the same device, if that's what you're looking for. I haven't tested it myself, but it seems similar to the way the Gmail app operates with multiple accounts (you switch over to a new account and get content specifically for that account, rather than mixed rooms from different accounts all in one list).
In practice, though, I'd be impressed if you could even find three different circles that are all on Matrix. I haven't found many people who are willing to switch yet over, anyway.
> In practice, though, I'd be impressed if you could even find three different circles that are all on Matrix. I haven't found many people who are willing to switch yet over, anyway
Kind of funny, but my experience over the last year as been the opposite. Probably because the kinds of communities I am interested in are focused around various FLOSS projects, but it seems like everywhere I look the "Contact Us"/"Get Involved" page for a project linked to their Matrix room(s). Anecdotally, the momentum that Matrix has in the FLOSS space is reaching a critical mass where it will almost be the de-facto communication tool (I am starting to be surprised when I see an IRC link instead...)
Outside of the tech world, I agree with you. Adoption of Matrix is tricky, but honestly it does not seem much worse than trying to get your friends to move the MMS group chat onto any other platform (WhatsApp, GroupMe, etc). Only extra challenge is helping them understand what "homeserver" they should use.
It sounds like you're asking for a Slack style configuration, e.g. where each workspace (in Slack terminology) needs to be authed into and can use different accounts within one app instance?
Slack is a bad example here because you can't really use different accounts at a time (at least on web). It just provides a relatively easy link to switch between them. Maybe app/mobile are better?
But yes, I think OP is asking to be logged into two accounts and see the rooms/contacts/notification from both in the same application. This is not currently supported in Element and I don't think it is on the near roadmap. But some other clients do have multi-account support.
I'd actually prefer the focus to be having a better UI to change your display name for every space/room. What remains public then is very limited and that should be a much better experience than changing accounts every time (I use this heavily with Telegram Plus - 4 users and it's super annoying). I'm ok with my username being public...
I have been through two unsatisfactory home servers (librem and privacytools) and am trying to decide what to do next, maybe even self-host. In the meantime, Signal :--P
Whatever I step to, I will need to get my extended family onto it, and that is a big enough hassle I don't want to repeat another move..
I saw that, E2E notwithstanding, your home server has plaintext access to all traffic, which makes me leery of using cloud servers.
The other big roadblock is that I don't know of any client that can manage multiple accounts. I would have to use e.g. fluffy for personal, and element for work.
And I found what was labeled a Signal-Matrix gateway, but could not figure out how to set it gu he. If you are not accessible via Signal, your existence fades.
> nightmarish pain point that is the amount of time we spend implementing the same features across the three different platforms
I've been toying with the idea of providing dynamic extensions to Matrix rooms by sending a WASM payload as an event.
That WASM could then provide new UI elements, interactions, interpret events, etc. This could be used to implement polls (I know it's coming, but that's an example) or whiteboards inside existing clients.
It's just an idea, not sure how it would work in practice... But if anyone wants to have a go at it, be my guest!
That sounds terrifying from a security perspective. I know wasm is sandboxed, but it's in a sandbox with all the user's data and parts of the user interface, which is quite enough to do damage.
I agree that the attack surface needs to be carefuly thought about. It shoudln't be much harder than current "widgets", though.
I was thinking of something that only does I/O with data contained in the room it's in. I think the UI would be the hard part, but it could be doable with a few HTML tags and an extensible UI.
For instance: add an "insert poll" button, or an "add voice message" button. Or an "add sticker"/emoji/gif, etc. Currently every client needs to build this individually. Users could pick the features they want in their clients.
Moreover, not every plugin needs to be third-party. A "trusted store" could very well be maintained.
I still can't believe there's been no response to the nickname colour proposal. This has been sitting in the queue for 2!!!! years now.
It's ridiculous.
Last I checked we needed a git account o upvote things or something - but even then I'm not sure we'd get a change in the roadmap / prioritization... I've considered hiring some peeps to make the code and offer it up to the community ti merge it or whatever. This and a few other important to me/my users, but really kind of superficial things in general that needs to attention imho.
- Synapse is very resource hungry even for a small server
- Synapse creates a gazillion of TCP connection and keep them open, it was a real problem for my ISP router (SOHO router for 1gbit/s) and it took a very long time to debug, be sure to limit the number of TCP connection on the server
- Synapse is hard to get a good idea of the health of the server, the federation can break without warning
- If the federation broke for some reason, when submitting messages, they will show as delivered, this was one of the major problem for us
- Encryption is very cumbersome to get right for non technical users, there should be a server wide option to make it "easier but less secure". Even for me, it was hard to get rid of a warning popup about some device error.
- Group VOIP is hard to setup, it should be as easy as discord to be viable.
- Webhook is really hard to setup too, I want to be able to right click a channel and "copy webhook URL" to be able to post to it with CURL (discord has that)
- Globally it is very slow when joining federated rooms, it can take days to sync 500+ people room
In the end we just use discord, it's free and do the job. Of course they can read our messages and this is a problem for me as I am for privacy and encryption, but it works for everybody, it is friendly and easy to use.
I will keep a close eye on matrix and try to adopt it again, but right now it is not usable for us.