I used to host a homeserver for myself up until very recently, but during their most recent conference, some folks decided to conduct a harassment campaign where they repeatedly posted CSAM in the Synapse Admins channel. Synapse didn't really offer me any built-in tools to preempt that sort of behavior - you can't even block domains. I found a third party moderation bot but it didn't look quick or easy to set up.
Being exposed personally to that sort of thing was bad enough but making sure it wasn't persisted in backups and my S3 buckets was way more trouble than it was worth, so I shut the service down and nuked the whole thing. I was mostly hanging out in public channels and using bridges; I only had one small group of IRL friends that I talked to on it and they practically leapt at the opportunity when I suggested moving the group chat to a different platform.
I see that "Trust & Safety" is on their list of things to tackle next, so perhaps I'll check it out when they announce Matrix 3.0.
Content only gets stored on your local server if a local user downloads it by viewing it before the message or the original content gets deleted. Separately, you can block abusive servers manually if needed (e.g. https://element-hq.github.io/synapse/latest/usage/configurat...).
For instance, this is better than email, where if someone sends you email with abusive attachments, it'll end up hitting your mail spool and likely your imap server whatever.
That said, agreed that moderation and anti-abuse tooling is fragmented currently, and we're working away on improving it. Recently a lot of time got taken on authenticated media (to make it much harder to distribute abusive content): https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate... but the top priority for The Matrix.org Foundation is to improve the anti-abuse situation (by securing funding for more folks to work on it).
Earlier I was writing about how its an issue in federated system , but now I have come to realisation that this is an issue in any encrypted system (even discord can have csam but it can detect it)
and to be honest , thus becomes a compromise , encrypted but you have the risk of csam or unencrypted , but to be really honest , I think considering edward's snowden blow on the nsa , I think I am much more safer in the encrypted land
here was my original post which I was writing
csam is an issue in federated systems (whether its p2p or non p2p) (source I read once on HN that some friend had created in the 1990's a sort of thing similar to chitchatter.im , only to it spread out of word and then came the csam)
for some people , encryption is a must because you never know what the govt. thinks is right or wrong and simply giving the govt. power to surveillance is quite powerful to govt. because then they can tweak that info into metaphorically speaking whatever they like.
there are entire communities based on this idea
For example r/privacy , https://discuss.privacyguides.net/ on which you rather have discussion on which protocol is more "encrypted" and "decentralized" in some sense to the extreme (like recent was simplex vs cwtch )
Very exciting! I'm particularly pleased to see the invisible encryption stuff mentioned.
One of the biggest pain points I had when setting up a self-hosted Matrix instance and getting all my devices signed in was the crypto stuff. At least in the client I use, Element, I was bombarded with tons of popups with vague "Upgrade your encryption!" prompts upon logging in the first time. The copywriting on the "Security & Privacy" page was less than helpful in illuminating what I was actually "upgrading" or setting up, since specific technical terms (e.g. recovery key/security phrase/security key) were all used more or less interchangeably. If that kind of confusion can be reduced or swept under the rug for end-users, it'd be a huge improvement on user experience.
Yup. One of the biggest learnings of E2EE in Matrix is that the complexity is 95% user experience. However, in Element X, we've been determined to get it right - although there is still some temporary UX in there while full-blown Invisible Crypto is still rolling out (as it requires a breaking change to stop encrypting/decrypting with unsigned devices - the equivalent to a browser refusing to talk TLS to self-signed certs).
Standardized terminology is an awesome step. I'd love to see some of standardized file format for setting up the right keys on different devices. In the past I'd had annoying issues getting all the messages to decrypt on multiple devices, especially if I wasn't using the same client every device. Honestly though I suspect I was doing something wrong.
If you want to host a homeserver but feel overwhelmed about the amount of services you'll have to host (especially if you want to have bridges to other services), check out matrix-docker-ansible-deploy [1]. It's pretty much a set and forget experience with reproducible deployment, and the documentation walks through any decision you need to make.
Ironically i just spent all weekend writing a new "quick start" guide for Matrix 2.0 deployments using docker-compose (so you literally just set some env variables, `docker compose up` and that's it; no ansible involved). I just shifted to the debugging phase, but once it's ready, it might be even easier than matrix-docker-ansible-deploy as a super-fast way to get started :)
Having more deployment options and quick-start guides is always great!
That said, the Ansible playbook provides various benefits that you cannot currently get with any other Matrix deployment method. For one, it seems to be the only deployment method that supports hundreds of Matrix and related services which all tie together nicely.
Getting started quickly and easily is an important part, but is not the end. Most people will sooner or later need "that extra service" (bridge, bot, etc.) and it's always a hassle to get it added to a "quick & dirty" deployment.
Using the Ansible playbook, enabling an extra service is usually one extra line of configuration and you're up & running with a deployment that has been battle-tested and improved by hundreds/ thousands of others. You're not alone debugging a hand-made "Synapse worker configuration" or "Matrix Authentication Service" integration - there are many others iterating on the same exact setup.
Another compelling reason to go with the playbook is maintaining your deployment over time - handling major Postgres version upgrades, backups, uninstalling old/deprecated services (to replace them with newer alternatives), etc.
Yes, Ansible can be slow and clunky (and the YAML format is definitely annoying), but it seems like a reasonable tradeoff that provides plenty of benefits.
I'd say the primary benefit of ansible is it makes you document everything. It's easy to simply set and forget with tools like docker compose, but then when you need to change something again, you have to recall what you did originally and fix that.
For me the benefit of the ansible playbook is that it installs not only synapse and element web but also a ton of bridges and other services like the chatgpt bot. It handles the configuration of those etc.
can you give it a codename that's not impossible to remember if you do add such a docker? something that is likely I'll be able to remember it in a couple of months?
I'm Aine of etke.cc, and yes, we can ease your pain by managing the server part of the matrix on your behalf, be it on-premises or hosted in the cloud by us.
I love the idea, but I have tried this three times and failed each time.
Sure I was learning docker and ansible at the time, and I did get a little bit of 'tech suggestions' from those in the know.. (enable less things to start)
It seemed to install a lot of things and get close.. it could be because I was trying debian 10 when it was made for debian 9 or whatnot..
I just need to mention that as much as it may be an all easy solution for some, it does not always work and turned out to be a big time waster for me three times (although I'll chalk up learning some docker and ansible as not being time spent that I consider wasted) - it did delay me getting a matrix / element setup running.
I think nginx is doing some things different in latest debian as well that effed up some of the tutorials and chat support.
but it's been some months, maybe it works fine now on latest debian without issues, but my experience has shown it to be very finicky.
Alternatively, you can just get your server managed by https://etke.cc - the developers of the MDAD paybook - and not worry about the server part at all
If there was a way to deploy there and make a snapshot of it that could be cloned to my own server, change DNS settings (to point the domain to my own server and re-grab the ssl certs) and be good to go.. I'd jump on that.
especially with the addons setups offered, that could be nice.
I'm sorry to hear that you got overwhelmed and gave up on Matrix!
Below, I'll try to explain why it can overwhelming and how one might navigate things better.
While the Ansible playbook's documentation is huge (which can be both good and bad), one does not necessarily need to read through everything to get started.
The playbook's documentation tries to guide you through the required steps to get started and always tries to suggest "skipping ahead" and staying with the recommended defaults. It does mention additional services, but branching off into reading about esoteric additional features from the very beginning is not necessary.
It's better to follow the steps and start with the basics. You can add additional services and tweak the existing ones later on at any time.
That said:
- just like a production-ready email system is complicated to deploy, so is Matrix (even with the Ansible playbook). Some learning and planning is necessary. Important decisions (with regard to domain names, etc.) need to be made upfront
- the playbook's documentation may benefit from a new and dedicated "quick-start guide" which would not even mention most or any of the additional services. This could help people get started quicker, instead of making them give up due to analysis paralysis
As for the latter, there are various articles (blog posts) online where people guide you through using the playbook (they act as a "quick start guide"). A downside to those is that some may be out of date and/or skip through steps which may turn out to be important later.
The playbook's documentation is extensive, because it not only aims to get you running, but to also instill knowledge as to how things work so that you're more capable of managing the deployment later on. It's a bit like the Arch Linux Wiki in this regard - it gives you more to read (and walls of text can be scary), but is also there for you for when you need help.
> Why would someone use a walled-garden instead of a protocol ?
Because it actually works. I've tried countless of times to use Matrix with different groups of people and every single time there comes a point after a few days where one of the participant can't read messages from another, or can't send messages anymore, etc. And that's was even the case with computer literate people (computer scientists or developers).
So yes, I see your point and in a world where Matrix actually does work and is simple to self-host, your point would be entirely valid. Sadly in real life, setting up a Mattermost instance is easy and it just works, while Matrix, even without the hassle of self-hosting, doesn't.
>Why would someone use a walled-garden instead of a protocol ?
>It's a very similar feeling for Bluesky.
Is this actual wondering on your part, or are you just rhetorically framing these as questions, as a means to express frustration? I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access. That's all there is to it. In the case of Bluesky, though, you have to take into account the political stances surrounding how the platform is viewed as well.
> I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access.
Can you share your sources for the "much larger user bases" ? It's hard to get the figures, I just googled them for 5 minutes and got contradictory results. Some pages say 30 million daily active users (DAU) for discord, some say 150. Slack seems to be at 30 million.
For Matrix, the official site says "The open network has grown from 80.3M to 115M addressable users." but there was only "250 DAU" in january for matrix.org, the public instance. The French gov's deployment of Matrix says 0,3 million DAU. https://element.io/case-studies/tchap
Could you please recommend a guide for how to set up something like a Slack/Discord replacement with Matrix? Do I understand correctly that this will be self-hosted?
I find it very difficult to get good solid information on actually using Matrix in the ways I use Discord.
Self-hosting is possible but optional. You can create rooms/spaces on matrix.org or any other matrix server of your choice. If you want control over your data, you may want to self-host, but if you consider Slack or Discord to be acceptable for your use cases, you can probably use a standard Matrix server without any issues.
You can create a "space" that's pretty close to a Discord server. Spaces include rooms ("channels") or even other spaces. This means you could set up a "Friends of pixelpoet" space with a bunch of channels like on Discord, but also a "pixelpoet Corp" server with in it spaces for "General", "Project Jabberwocky", "HR", and "Janitorial staff", each with their own rooms and ACLs inside of it.
How I would approach your setup: I would create a new space, then create a few rooms in that space (your #general, #games, #offtopic, etc). I'd also maybe add a "video room", which works a bit like Discord's audio/video channels, though not many clients support those yet (I think they're in beta?).
Then, go to the "space home" (as Element calls it), and make sure to check every channel, and set the "mark as recommended" flag, so that people joining the space will be guided to join all of the channels as well. It's possible to join a space but not join all channels, which can be useful for some but is probably pretty awkward for most. People that don't join all channels still can join after the fact, but you probably want everyone in every room by default.
For larger servers, you want need to configure ACLs before letting people in. Do note that unlike on Discord, settings change for a Space do not apply to rooms that are included in it automatically; you may need to manually alter ACLs for every room or find a bot to do it for you. If it's just a space friends or coworkers, you hopefully don't need to bother, though.
Then, to get other people into your "server", invite them to the space, or share a generated link. Just right click the space and pick "invite".
If you like the Discord UX, you might want to try Cinny, a Matrix web client that's pretty much a Discord clone in terms of design. It doesn't support everything Element supports, but it's good enough that I'd be willing to recommend it to others if they're not the ones setting up the server.
For data safety, you can leverage Matrix's encryption feature to end-to-end-encrypt everything even if you're storing your space on another server. This can have some annoying side effects (like people losing access to their old messages when they forget their recovery password, because, well, they're encrypted) and using the feature securely requires a) verifying other people and b) verifying every device you log into with another device or by entering a backup key. This is harder than in other messengers but it's also a more secure design. Could be useful if you don't entirely trust Matrix.org, could also be useful for setting up channels for sharing sensitive documents, but it's probably best for general usability to disable encryption at first. I enable encryption everywhere, but I don't think encryption/decryption is trouble-free enough that I'd be able to convince my friends to fully enable it in chat rooms as well.
I've had Element X installed for a while -- couldn't use it for a while after EMS shut down their small instances and I started self-hosting, but it works with my self-hosted Synapse now.
The only problem is that it's got too many paper cuts. I can live without Spaces, even though I use them on Desktop. But notification channels are a harder sell, and missing avatars on notifications is just annoying. Neither are exactly core features, but notifications are the most common way I interact with Element on mobile and for me, the improvements (and there are many) aren't worth the downsides.
> But notification channels are a harder sell, and missing avatars on notifications is just annoying.
huh. on Element X iOS, the notif support is genuinely great - you get avatars and groupings and reliable notifs on e2ee msgs. the only thing is missing is quick-reply (which has been blocked behind full multi-process support in matrix-rust-sdk, hopefully coming soon).
I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
> I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
Aren't you Element's CTO? I feel like you shouldn't need to make assumptions into how the app works, you should just know (even if you're not personally daily driving it). If not you, is anyone in charge of ensuring that the project's vision and goals are met?
I’m in south east Asia and I have a lot of friends using matrix but the whole is unbearably slow to me. Most of the time it takes more than 10 seconds to sync and messages don’t go through. I’d be happy to look at the infra to see what’s happening though. It’s also what breaks my notifications on iOS.
Element X has a few notification issues on Android (I use it daily): you don't get quick reply (which can be fixed by adding conversation shortcuts in Android), and you get a notification for every single message. Element X doesn't stack up the notifications, so if someone floods you 20 lines of text in less than 10 seconds, your phone will vibrate 20 times in under 10 seconds. It's quite annoying.
I treat Element X as an alpha client. Half the features I use aren't implemented and I get signed out every few weeks. The parts that do work, work very well, but the parts that don't are
After the last update, I can't seem to log in anymore, which is a first. Fluffychat is my go-to on mobile these days. It supports Material You, which I like, and does things like notification channels well. It still has the occasional bug and I get the feeling it's consuming more power, but it's the best Android client I know of in terms of features versus stability.
From what I've read, most of the Element X work seems to have been put into iOS, because Android has had a few app rewrites over the years already but the iOS version was still based on some very old code base.
Does this change anything for notifications? I've had to pause using Matrix (self-hosted Synapse plus Schidichat for Android after Element had the same issues) to talk to my friends because we routinely get shit like:
- Message is sent to the server but nobody else's phone gets notified about it for minutes / hours
- Message just can't be sent to the server even though the sending phone has Internet and a desktop web client on the same account works great
If the problems were caused by issues in the old Element Android (or Schildichat) app then yes - the Element X rewrite will likely fix it. It supports UnifiedPush, so if you're self-hosting a push gateway it should nicely integrate (as does Schildichat Next).
If the problem was in your push infrastructure, then the new app won't fix anything - however, UnifiedPush should be reliable these days (especially if you host your own instance; some of the shared ones are overloaded and/or deliberately throttle Matrix push). FCM obviously should be reliable too.
I have the opposite problem with Element Desktop. I hear messages coming in on my phone but it takes up to 10 seconds before they appear on the web client. Really annoying.
Off topic but I love the YouTube player interface. Instead of loading it by default (and adding invasive Google tracking to the page), you get the option to opt in. Very nice.
I tried navigating to youtube-nocookie.com and got an http cert error, so that doesn't seem like an option.
The support page you linked to talks about "Privacy Enhanced Mode". The language there does not sound like it really protects privacy.
> The Privacy Enhanced Mode of the YouTube embedded player prevents the use of views of embedded YouTube content from influencing the viewer’s browsing experience on YouTube.
So they're not promising not to track users. They're saying they won't use their tracking to personalize anything.
I just opened Element X, tried to decline some spammy invite - "sorry, unknown error occured". Tried opening backup section in settings - "sorry, unknown error occured".
what server is this on? (as these sound like serverside issues). please can you submit debug logs so we can take a look? needless to say, this shouldn't be happening.
I join from the official matrix.org server.
It also federates to Gnome server and maybe some others, but they never synced properly so I never used it.
Readit News
Being exposed personally to that sort of thing was bad enough but making sure it wasn't persisted in backups and my S3 buckets was way more trouble than it was worth, so I shut the service down and nuked the whole thing. I was mostly hanging out in public channels and using bridges; I only had one small group of IRL friends that I talked to on it and they practically leapt at the opportunity when I suggested moving the group chat to a different platform.
I see that "Trust & Safety" is on their list of things to tackle next, so perhaps I'll check it out when they announce Matrix 3.0.
Because of that I still idle in the synapse admins channel, though I have it muted and haven't opened it for years.
It makes me worry that csam from the muted channel could be sitting on my hard drive somewhere.
For instance, this is better than email, where if someone sends you email with abusive attachments, it'll end up hitting your mail spool and likely your imap server whatever.
That said, agreed that moderation and anti-abuse tooling is fragmented currently, and we're working away on improving it. Recently a lot of time got taken on authenticated media (to make it much harder to distribute abusive content): https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate... but the top priority for The Matrix.org Foundation is to improve the anti-abuse situation (by securing funding for more folks to work on it).
and to be honest , thus becomes a compromise , encrypted but you have the risk of csam or unencrypted , but to be really honest , I think considering edward's snowden blow on the nsa , I think I am much more safer in the encrypted land
here was my original post which I was writing
csam is an issue in federated systems (whether its p2p or non p2p) (source I read once on HN that some friend had created in the 1990's a sort of thing similar to chitchatter.im , only to it spread out of word and then came the csam)
it happens on matrix as well.
there are entire communities based on this idea
For example r/privacy , https://discuss.privacyguides.net/ on which you rather have discussion on which protocol is more "encrypted" and "decentralized" in some sense to the extreme (like recent was simplex vs cwtch )
One of the biggest pain points I had when setting up a self-hosted Matrix instance and getting all my devices signed in was the crypto stuff. At least in the client I use, Element, I was bombarded with tons of popups with vague "Upgrade your encryption!" prompts upon logging in the first time. The copywriting on the "Security & Privacy" page was less than helpful in illuminating what I was actually "upgrading" or setting up, since specific technical terms (e.g. recovery key/security phrase/security key) were all used more or less interchangeably. If that kind of confusion can be reduced or swept under the rug for end-users, it'd be a huge improvement on user experience.
If you haven't seen MSC4161 (https://github.com/matrix-org/matrix-spec-proposals/blob/and...) i highly recommend it as evidence of how we've made a serious effort to fix the terminology and copy - not just for Element X but across all Matrix clients.
1. https://github.com/spantaleev/matrix-docker-ansible-deploy
That said, the Ansible playbook provides various benefits that you cannot currently get with any other Matrix deployment method. For one, it seems to be the only deployment method that supports hundreds of Matrix and related services which all tie together nicely.
Getting started quickly and easily is an important part, but is not the end. Most people will sooner or later need "that extra service" (bridge, bot, etc.) and it's always a hassle to get it added to a "quick & dirty" deployment.
Using the Ansible playbook, enabling an extra service is usually one extra line of configuration and you're up & running with a deployment that has been battle-tested and improved by hundreds/ thousands of others. You're not alone debugging a hand-made "Synapse worker configuration" or "Matrix Authentication Service" integration - there are many others iterating on the same exact setup.
Another compelling reason to go with the playbook is maintaining your deployment over time - handling major Postgres version upgrades, backups, uninstalling old/deprecated services (to replace them with newer alternatives), etc.
Yes, Ansible can be slow and clunky (and the YAML format is definitely annoying), but it seems like a reasonable tradeoff that provides plenty of benefits.
Disclaimer: I'm the author of the matrix-docker-ansible-deploy (https://github.com/spantaleev/matrix-docker-ansible-deploy) playbook
nginx or caddy or something?
I'm Aine of etke.cc, and yes, we can ease your pain by managing the server part of the matrix on your behalf, be it on-premises or hosted in the cloud by us.
Sure I was learning docker and ansible at the time, and I did get a little bit of 'tech suggestions' from those in the know.. (enable less things to start)
It seemed to install a lot of things and get close.. it could be because I was trying debian 10 when it was made for debian 9 or whatnot..
I just need to mention that as much as it may be an all easy solution for some, it does not always work and turned out to be a big time waster for me three times (although I'll chalk up learning some docker and ansible as not being time spent that I consider wasted) - it did delay me getting a matrix / element setup running.
I think nginx is doing some things different in latest debian as well that effed up some of the tutorials and chat support.
but it's been some months, maybe it works fine now on latest debian without issues, but my experience has shown it to be very finicky.
Disclaimer: I'm Aine of etke.cc
especially with the addons setups offered, that could be nice.
I feel overwhelmed at the number of options there are in this ansible thing. Now I definitely don't want to try it either way.
While the Ansible playbook's documentation is huge (which can be both good and bad), one does not necessarily need to read through everything to get started.
The playbook's documentation tries to guide you through the required steps to get started and always tries to suggest "skipping ahead" and staying with the recommended defaults. It does mention additional services, but branching off into reading about esoteric additional features from the very beginning is not necessary.
It's better to follow the steps and start with the basics. You can add additional services and tweak the existing ones later on at any time.
That said:
- just like a production-ready email system is complicated to deploy, so is Matrix (even with the Ansible playbook). Some learning and planning is necessary. Important decisions (with regard to domain names, etc.) need to be made upfront
- the playbook's documentation may benefit from a new and dedicated "quick-start guide" which would not even mention most or any of the additional services. This could help people get started quicker, instead of making them give up due to analysis paralysis
As for the latter, there are various articles (blog posts) online where people guide you through using the playbook (they act as a "quick start guide"). A downside to those is that some may be out of date and/or skip through steps which may turn out to be important later.
The playbook's documentation is extensive, because it not only aims to get you running, but to also instill knowledge as to how things work so that you're more capable of managing the deployment later on. It's a bit like the Arch Linux Wiki in this regard - it gives you more to read (and walls of text can be scary), but is also there for you for when you need help.
Disclaimer: I'm the author of the matrix-docker-ansible-deploy (https://github.com/spantaleev/matrix-docker-ansible-deploy) playbook
Why would someone use a walled-garden instead of a protocol ?
It's a very similar feeling for Bluesky.
Because it actually works. I've tried countless of times to use Matrix with different groups of people and every single time there comes a point after a few days where one of the participant can't read messages from another, or can't send messages anymore, etc. And that's was even the case with computer literate people (computer scientists or developers).
So yes, I see your point and in a world where Matrix actually does work and is simple to self-host, your point would be entirely valid. Sadly in real life, setting up a Mattermost instance is easy and it just works, while Matrix, even without the hassle of self-hosting, doesn't.
Ended up going on signal.
>It's a very similar feeling for Bluesky.
Is this actual wondering on your part, or are you just rhetorically framing these as questions, as a means to express frustration? I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access. That's all there is to it. In the case of Bluesky, though, you have to take into account the political stances surrounding how the platform is viewed as well.
Can you share your sources for the "much larger user bases" ? It's hard to get the figures, I just googled them for 5 minutes and got contradictory results. Some pages say 30 million daily active users (DAU) for discord, some say 150. Slack seems to be at 30 million.
For Matrix, the official site says "The open network has grown from 80.3M to 115M addressable users." but there was only "250 DAU" in january for matrix.org, the public instance. The French gov's deployment of Matrix says 0,3 million DAU. https://element.io/case-studies/tchap
According to this page, lots of NATO agencies are already using Element https://element.io/blog/nato-ni2ce-messenger-utilises-the-po.... This other page lists several other deployments https://element.io/blog/element-is-combusting-with-excitemen....
It's hard to get the number of DAU users of a decentralized network, I couldn't get any for Mattermost.
I find it very difficult to get good solid information on actually using Matrix in the ways I use Discord.
Unless your data should be on your server, in this case yes you have to launch your own instance.
Once you're logged in, there is a "+" sign on the left. Create a public or private space and then add channels to it.
You can create a "space" that's pretty close to a Discord server. Spaces include rooms ("channels") or even other spaces. This means you could set up a "Friends of pixelpoet" space with a bunch of channels like on Discord, but also a "pixelpoet Corp" server with in it spaces for "General", "Project Jabberwocky", "HR", and "Janitorial staff", each with their own rooms and ACLs inside of it.
How I would approach your setup: I would create a new space, then create a few rooms in that space (your #general, #games, #offtopic, etc). I'd also maybe add a "video room", which works a bit like Discord's audio/video channels, though not many clients support those yet (I think they're in beta?).
Then, go to the "space home" (as Element calls it), and make sure to check every channel, and set the "mark as recommended" flag, so that people joining the space will be guided to join all of the channels as well. It's possible to join a space but not join all channels, which can be useful for some but is probably pretty awkward for most. People that don't join all channels still can join after the fact, but you probably want everyone in every room by default.
For larger servers, you want need to configure ACLs before letting people in. Do note that unlike on Discord, settings change for a Space do not apply to rooms that are included in it automatically; you may need to manually alter ACLs for every room or find a bot to do it for you. If it's just a space friends or coworkers, you hopefully don't need to bother, though.
Then, to get other people into your "server", invite them to the space, or share a generated link. Just right click the space and pick "invite".
If you like the Discord UX, you might want to try Cinny, a Matrix web client that's pretty much a Discord clone in terms of design. It doesn't support everything Element supports, but it's good enough that I'd be willing to recommend it to others if they're not the ones setting up the server.
For data safety, you can leverage Matrix's encryption feature to end-to-end-encrypt everything even if you're storing your space on another server. This can have some annoying side effects (like people losing access to their old messages when they forget their recovery password, because, well, they're encrypted) and using the feature securely requires a) verifying other people and b) verifying every device you log into with another device or by entering a backup key. This is harder than in other messengers but it's also a more secure design. Could be useful if you don't entirely trust Matrix.org, could also be useful for setting up channels for sharing sensitive documents, but it's probably best for general usability to disable encryption at first. I enable encryption everywhere, but I don't think encryption/decryption is trouble-free enough that I'd be able to convince my friends to fully enable it in chat rooms as well.
Dead Comment
The only problem is that it's got too many paper cuts. I can live without Spaces, even though I use them on Desktop. But notification channels are a harder sell, and missing avatars on notifications is just annoying. Neither are exactly core features, but notifications are the most common way I interact with Element on mobile and for me, the improvements (and there are many) aren't worth the downsides.
huh. on Element X iOS, the notif support is genuinely great - you get avatars and groupings and reliable notifs on e2ee msgs. the only thing is missing is quick-reply (which has been blocked behind full multi-process support in matrix-rust-sdk, hopefully coming soon).
I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
Aren't you Element's CTO? I feel like you shouldn't need to make assumptions into how the app works, you should just know (even if you're not personally daily driving it). If not you, is anyone in charge of ensuring that the project's vision and goals are met?
After the last update, I can't seem to log in anymore, which is a first. Fluffychat is my go-to on mobile these days. It supports Material You, which I like, and does things like notification channels well. It still has the occasional bug and I get the feeling it's consuming more power, but it's the best Android client I know of in terms of features versus stability.
From what I've read, most of the Element X work seems to have been put into iOS, because Android has had a few app rewrites over the years already but the iOS version was still based on some very old code base.
- Message is sent to the server but nobody else's phone gets notified about it for minutes / hours
- Message just can't be sent to the server even though the sending phone has Internet and a desktop web client on the same account works great
If the problem was in your push infrastructure, then the new app won't fix anything - however, UnifiedPush should be reliable these days (especially if you host your own instance; some of the shared ones are overloaded and/or deliberately throttle Matrix push). FCM obviously should be reliable too.
https://support.google.com/youtube/answer/171780?hl=en#zippy...
The support page you linked to talks about "Privacy Enhanced Mode". The language there does not sound like it really protects privacy.
> The Privacy Enhanced Mode of the YouTube embedded player prevents the use of views of embedded YouTube content from influencing the viewer’s browsing experience on YouTube.
So they're not promising not to track users. They're saying they won't use their tracking to personalize anything.
I don't think it is ready for prime time.