Matrix 2.0: How we’re making Matrix go voom(fosdem.org)
fosdem.org
Matrix 2.0: How we’re making Matrix go voom
https://fosdem.org/2023/schedule/event/matrix20/
176 comments
That seems like a pretty good open-core project with the core under the Apache 2.0 license. Still, unlike GitLab, I haven't heard of many running their own custom Element and until I do I'm a bit wary of lock-in.
I've been self-hosting a federated Matrix homeserver since 2018. It's small (about 20 active users), but it was enough like Discord and Slack that the less technically-inclined in the group have had little trouble adjusting to it. The main friction points have been the UI changes in Riot/Element over time ("where do I put the homeserver URL thingy again?"), and the fact that my friends seem to constantly forget their passwords and (this is really a separate issue from Synapse itself) setting up an account for transactional emails is a pain in the ass.
Amusingly, two of my co-workers from a previous job also run their own homeservers, one a smaller private instance similar to mine and the other a single-user node that bridges many different chat systems together for personal use. The two of them also interact with the users on my homeserver on a regular basis in various public and private channels.
I should note that only one of the active users in the channels on my server is from matrix.org - everyone else is from the same server or federated instances run by other people. Matrix.org could go down tomorrow and things for us would mostly keep running just fine.
I do wish Synapse had a proper account invite system for private servers, and not the "spin up a matrix.org account and chuck the hapless fool in the hopefully-federated room" method that was there the last time I tried.
Amusingly, two of my co-workers from a previous job also run their own homeservers, one a smaller private instance similar to mine and the other a single-user node that bridges many different chat systems together for personal use. The two of them also interact with the users on my homeserver on a regular basis in various public and private channels.
I should note that only one of the active users in the channels on my server is from matrix.org - everyone else is from the same server or federated instances run by other people. Matrix.org could go down tomorrow and things for us would mostly keep running just fine.
I do wish Synapse had a proper account invite system for private servers, and not the "spin up a matrix.org account and chuck the hapless fool in the hopefully-federated room" method that was there the last time I tried.
> my friends seem to constantly forget their passwords
I'm hosting a small set of services (Nextcloud in particular) for a group of friends, and the same thing is happening here. At some point, I added an email reset to my LDAP system so that people can reset their passwords themselves. I don't know how "normal" people live like that. I can't remember the last time I used a password reset other than for technical reasons.
I'm hosting a small set of services (Nextcloud in particular) for a group of friends, and the same thing is happening here. At some point, I added an email reset to my LDAP system so that people can reset their passwords themselves. I don't know how "normal" people live like that. I can't remember the last time I used a password reset other than for technical reasons.
You could add OIDC auth, e.g. facebook/twitter/google/... for your friends
How do you deal with the complexity of hosting Matrix?
I was in the same position, wanted to set one up - decided it was too much work.
I was in the same position, wanted to set one up - decided it was too much work.
There's not much complexity really. This handbook takes care of most stuff for you:
https://github.com/spantaleev/matrix-docker-ansible-deploy/
Been hosting it alongside some bridges(like irc) for a while now.
https://github.com/spantaleev/matrix-docker-ansible-deploy/
Been hosting it alongside some bridges(like irc) for a while now.
I'm happy to hear that my Ansible playbook for managing Matrix is helpful to people and is being appreciated!
Shameless plug - for people who'd rather not maintain their own server manually with Ansible, a few others and I are running https://etke.cc - a completely FOSS service service built on top of the Ansible playbook. Hopefully, this provides the best of both worlds - ease of getting started (on your own or on a rented server), everything built on top of FOSS, no vendor-lock-in (you can migrate to using the playbook yourself at any time, etc.).
Shameless plug - for people who'd rather not maintain their own server manually with Ansible, a few others and I are running https://etke.cc - a completely FOSS service service built on top of the Ansible playbook. Hopefully, this provides the best of both worlds - ease of getting started (on your own or on a rented server), everything built on top of FOSS, no vendor-lock-in (you can migrate to using the playbook yourself at any time, etc.).
I use AVENTER-UG's docker-matrix container for Synapse, and a separate VM for PostgreSQL. Element-web I currently upgrade straight from the tarballs. Upgrades are fairly seamless, and it's been well behaved for the past 24 months or so - the teams behind the Matrix ecosystem have been phenomenal.
But you want sysadmin pain points, here are some random pointers in no particular order:
- Familiarity with reverse proxies helps a lot. I recommend terminating both client (443) and federation (8448) traffic through nginx or similar.
- The Synapse Github (https://github.com/matrix-org/synapse/issues) is one of the first places I start trawling if something gets weird.
- Federation is the second-hardest part, and if something goes wrong and you're not watching the Synapse logs it can fail silently - here it helps to have friends on other instances there to check connectivity (and blame you when THEIR instance breaks federation, that's fun). https://federationtester.matrix.org and similar help a lot too, and it's good to at least have a couple of bots from matrix.org to poke at if you suspect something's amiss.
- Fuck everything about troubleshooting STUN/TURN. Newer playbooks may make coturn deployment easier.
- It's easy to test migrations/deployments with an update to your hosts file - you can verify that your clients connect to the new server and that data has been restored without doing anything to the original server.
EDIT - Keep in mind that a lot of the above went on from 2018-2019 (except the server migration, but that was easy) and the documentation/automation has improved quite a lot since then.
But you want sysadmin pain points, here are some random pointers in no particular order:
- Familiarity with reverse proxies helps a lot. I recommend terminating both client (443) and federation (8448) traffic through nginx or similar.
- The Synapse Github (https://github.com/matrix-org/synapse/issues) is one of the first places I start trawling if something gets weird.
- Federation is the second-hardest part, and if something goes wrong and you're not watching the Synapse logs it can fail silently - here it helps to have friends on other instances there to check connectivity (and blame you when THEIR instance breaks federation, that's fun). https://federationtester.matrix.org and similar help a lot too, and it's good to at least have a couple of bots from matrix.org to poke at if you suspect something's amiss.
- Fuck everything about troubleshooting STUN/TURN. Newer playbooks may make coturn deployment easier.
- It's easy to test migrations/deployments with an update to your hosts file - you can verify that your clients connect to the new server and that data has been restored without doing anything to the original server.
EDIT - Keep in mind that a lot of the above went on from 2018-2019 (except the server migration, but that was easy) and the documentation/automation has improved quite a lot since then.
I run my own self-hosted synapse (backend) and element (front-end).
It's been working flawlessly since I deployed it (about 2 years ago now).
It's been working flawlessly since I deployed it (about 2 years ago now).
How can you get locked into an open protocol?
By getting locked into tools on top of it.
I think generally the point here is: if you're worried about getting locked into a totally open ecosystem, there's nowhere for you to go.
I specifically mentioned something that I was more comfortable with: GitLab
So I don't know where you got "there's nowhere for you to go" from.
Element has open source apps and that's great. It just seems to not have a very strong culture of people self-hosting it. Though one comment did provide me a place to look and I found this and am now more comfortable with it. https://schildi.chat/ Still it would be great to see it have some big instances like GitLab does with Debian, Freedesktop, and others. Then I wouldn't feel I was going it alone if I self-hosted it.
So I don't know where you got "there's nowhere for you to go" from.
Element has open source apps and that's great. It just seems to not have a very strong culture of people self-hosting it. Though one comment did provide me a place to look and I found this and am now more comfortable with it. https://schildi.chat/ Still it would be great to see it have some big instances like GitLab does with Debian, Freedesktop, and others. Then I wouldn't feel I was going it alone if I self-hosted it.
Oh! Well, a couple things:
- Matrix is the protocol, Element is confusingly both the hosting service and the mobile app, and Synapse is the server -- just to get terminology right
- Matrix actually does the "multiple clients" thing really right [0]
- I think a lot of people self-host; I did and there are a few others in this thread. It's easy if you've any experience hosting web API servers. A core Matrix goal is to be decentralized, so self-hosting is thus also a core goal. You can see docs here [1], or docs for Docker here [2] if that's your thing.
[0]: https://matrix.org/clients/
[1]: https://matrix-org.github.io/synapse/latest/
[2]: https://github.com/matrix-org/synapse/tree/master/docker
- Matrix is the protocol, Element is confusingly both the hosting service and the mobile app, and Synapse is the server -- just to get terminology right
- Matrix actually does the "multiple clients" thing really right [0]
- I think a lot of people self-host; I did and there are a few others in this thread. It's easy if you've any experience hosting web API servers. A core Matrix goal is to be decentralized, so self-hosting is thus also a core goal. You can see docs here [1], or docs for Docker here [2] if that's your thing.
[0]: https://matrix.org/clients/
[1]: https://matrix-org.github.io/synapse/latest/
[2]: https://github.com/matrix-org/synapse/tree/master/docker
Like https://element.debian.social for instance? ;)
Yeah that's pretty good. Not quite to where GitLab is, but in the right direction. GitLab is really helpful with self-hosting.
What do you mean not quite? There are much more options than with GitLab, and a lot of people are self-hosting it actually.
I mean Element's website says very little about installing it and encourages using mobile apps which require going through the app store, while GitLab has all kinds of resources for self-hosting. They do try to steer you to self-hosting the ee version though.
Element: landing page https://element.io/solutions/self-hosted-or-cloud-collaborat...
GitLab: all the things https://about.gitlab.com/install/ at the bottom is the Debian package, but if you go to the Docker Page and click the username you can see gitlab-ce there as well.
Element: landing page https://element.io/solutions/self-hosted-or-cloud-collaborat...
GitLab: all the things https://about.gitlab.com/install/ at the bottom is the Debian package, but if you go to the Docker Page and click the username you can see gitlab-ce there as well.
Gitlab and Element's website structure is different. element.io is the site for the managed product, so even their "on-premise" installer is meant to be used in a commercial relationship. For install docs you'd probably have to purchase their product (which isn't available freely).
You probably want to read the open-source software's installation instructions at: https://github.com/vector-im/element-web
TLDR, check out the project, run `yarn install`, then edit the config file, then `yarn build`.
And, yes, that is all there is to it. It's significantly simpler to deploy than GitLab.
Finally, you keep mentioning self-hosting; you _can_ just use a non-self hosted application like the downloadable version of Element, SchildiChat, Fluffychat, or any other client.
No reason to bring hosting into the mix for the client, if that's causing concern.
You probably want to read the open-source software's installation instructions at: https://github.com/vector-im/element-web
TLDR, check out the project, run `yarn install`, then edit the config file, then `yarn build`.
And, yes, that is all there is to it. It's significantly simpler to deploy than GitLab.
Finally, you keep mentioning self-hosting; you _can_ just use a non-self hosted application like the downloadable version of Element, SchildiChat, Fluffychat, or any other client.
No reason to bring hosting into the mix for the client, if that's causing concern.
Using an official build of element makes it feel less open, unless the builds are reproducible. Are they?
To me it looks like they come with proprietary stuff: https://element.io/pricing
Especially Group Sync seems like something to drive you into their paid offerings, I assume by keeping the code close to the vest.
To me it looks like they come with proprietary stuff: https://element.io/pricing
Especially Group Sync seems like something to drive you into their paid offerings, I assume by keeping the code close to the vest.
Element is a for profit company that creates one set of clients and a hosted service for the matrix protocol. To find alternatives, look at https://matrix.org/discover/
Really ? I have been self hosting for atleast three years.
Dendrite, conduit and synapse - matrix homeserver software (you have to use one of them) have thousands of stars.
I'm pretty sure atleast 10k+ matrix homeserver deployments exist - maybe someone from matrix.org can give a better number because each homeserver is probably federating with theirs.
And thats to say nothing of unfederated servers i.e. orgs hosting matrix for internal use.
Dendrite, conduit and synapse - matrix homeserver software (you have to use one of them) have thousands of stars.
I'm pretty sure atleast 10k+ matrix homeserver deployments exist - maybe someone from matrix.org can give a better number because each homeserver is probably federating with theirs.
And thats to say nothing of unfederated servers i.e. orgs hosting matrix for internal use.
I do! It's a Docker container. I also run the Element web client, also as a Docker container. I kick back 5 bucks a month to the Matrix.org Foundation since it's probably my most-used piece of software behind my OS and my browser. Been absolutely rock solid for about 3 years now.
There’s lots of element instances out there and alternative clients like Cinny. What’s harder to duplicate is the homeserver, Synapse. But even there there’s also Dendrite
Conduit as well, although AFAIK it's not an "official" homeserver, while Dendrite is
Well, I haven't heard of any and your comment doesn't help me to find any. I had heard of Cinny but currently I am assessing Element.
The whole point of matrix, though, is that it’s an open protocol. If Element were proprietary, that wouldn’t be the same sort of problem as we have with discord/slack because anyone could just implement the protocol according to the specs and be an equal participant at the table.
This is a list of public home server instances: https://joinmatrix.org/servers/
Great, thanks. I didn't think to look there since a Matrix homeserver is a different thing, but that shows a bunch of self-hosted Element instances!
matrix.org has a listing of clients. There are plenty if you only need basic features, but Element is the only feature-mostly-complete client.
I had to look up each of them. This looks to be the only one that is based on Element:
https://schildi.chat/
https://schildi.chat/
Is it a requirement that you use an Element-based client?
No, but since Element led by some of the same people as Matrix, I want to observe the type of open core project it is. Is it more like GitLab or more like Supabase? GitLab has a lot of help for self-hosting, while with Supabase if you want to run its components on your own it's up to you.
Unlike GitLab, Matrix is not open core, and so isn't Element or Synapse, they properly and fully open source.
Also, Element is just some JavaScript in your browser or electron shell, there's no need to self-host it really, although you can (just put some HTML+CSS+JS up on a webserver) — you want to self-host Synapse, and that's trivial to do (there's a Debian package, a Docker image and so on).
Also, Element is just some JavaScript in your browser or electron shell, there's no need to self-host it really, although you can (just put some HTML+CSS+JS up on a webserver) — you want to self-host Synapse, and that's trivial to do (there's a Debian package, a Docker image and so on).
Scalar (the integration manager) is not open source [1] (though there was some effort to reverse-engineer its protocol [2]); and some of their anti-abuse scripts aren't public [3]
[1] https://github.com/vector-im/element-meta/issues/260
[2] https://github.com/turt2live/matrix-dimension/blob/master/do...
[3] https://github.com/matrix-org/matrix.org/issues/557
[1] https://github.com/vector-im/element-meta/issues/260
[2] https://github.com/turt2live/matrix-dimension/blob/master/do...
[3] https://github.com/matrix-org/matrix.org/issues/557
> Matrix is not open core
I'm comparing Element.
> and so isn't Element
It sure seems to be. Look at the red X's and green checkmarks in the comparison: https://element.io/pricing There are different opinions on what Open Core means though.
I'm comparing Element.
> and so isn't Element
It sure seems to be. Look at the red X's and green checkmarks in the comparison: https://element.io/pricing There are different opinions on what Open Core means though.
Some of their bridges (e.g. Teams bridge) aren't open source. But those are separate software projects. AFAIK synapse and element aren't open core but fully open source (with apache licensing).
This is in fact a bit of a problem wrt. funding: https://matrix.org/blog/2022/12/01/funding-matrix-via-the-ma...
This is in fact a bit of a problem wrt. funding: https://matrix.org/blog/2022/12/01/funding-matrix-via-the-ma...
I think that comparison is just heir hosted offerings, not what the software (open source code) supports.
[deleted]
Conduit was pretty straightforward to set up, I just have it running with podman+systemd. It also works great with heisenbridge, which is an IRC gateway.
Well, I'm also running a small company (software house) and we're also using Element for it, but it's self-hosted, managed via https://etke.cc/. I believe migration to element.io or from element.io would be rather seamless.
My self hosted matrix instance just imploded and we had to move 20 users off of it. I'm sure it was due to a sloppy mistake during a server upgrade or whatever but it seems pretty brittle to me.
How are voice calls?
Edit: looks like there's a 50 user minimum for business plans?
Edit: looks like there's a 50 user minimum for business plans?
If you host a server yourself you can hook in coturn (it's enabled by the linked playbook by default):
https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
https://github.com/coturn/coturn
https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
https://github.com/coturn/coturn
I've been happily running a Synapse homeserver with Matrix on top. It has a couple of bridges (Discord/Telegram/Signal) so the people I invite through those platforms can use my server to get to those services, optionally. Slowly but surely my friends have been migrating.
In my experience Element for Android starts off pretty fast, but as the weeks progress it gets slower and slower to load chats. Element on Linux does not have that problem, and neither does Schildichat for Android. It is my client of choice, anyone frustrated by a slow client should try that one on for size.
That said I'm excited for the new version. I used this Ansible/Docker setup, easy as pie:
https://github.com/spantaleev/matrix-docker-ansible-deploy
In my experience Element for Android starts off pretty fast, but as the weeks progress it gets slower and slower to load chats. Element on Linux does not have that problem, and neither does Schildichat for Android. It is my client of choice, anyone frustrated by a slow client should try that one on for size.
That said I'm excited for the new version. I used this Ansible/Docker setup, easy as pie:
https://github.com/spantaleev/matrix-docker-ansible-deploy
In the talk they explain why the app gets slow now and how the app they plan to release by the end of 2023 fixes it with sliding sync.
Hopefully that improves your situation
Hopefully that improves your situation
Link to YouTube video since FOSDEM video isn't loading.
https://www.youtube.com/watch?v=eUPJ9zFV5IE
https://www.youtube.com/watch?v=eUPJ9zFV5IE
Thanks for providing. Both the .webm and .mp4:
"No video with supported format and MIME type found."
Not a great UX, but certainly not worth anyone getting upset about, given FOSDEM is seemingly volunteer driven.
"No video with supported format and MIME type found."
Not a great UX, but certainly not worth anyone getting upset about, given FOSDEM is seemingly volunteer driven.
Thanks for the link.
May I say, I am SHOCKED at how much they have been able to accomplish. Incredible. I'm sure it's not all rainbows but the demos were amazing.
May I say, I am SHOCKED at how much they have been able to accomplish. Incredible. I'm sure it's not all rainbows but the demos were amazing.
I hope their security is better than in 2019 when the French Tchap service based on Matrix was immediately compromised by a trivial attack [1].
Matrix.org has also been breached in the past [2].
That's ignoring the fact their project was born out of a company that operates front offices for one of the world's most aggressive spy agencies...
[1] https://medium.com/@fs0c131y/tchap-the-super-not-secure-app-...
[2] https://matrix.org/blog/2019/04/11/we-have-discovered-and-ad...
Matrix.org has also been breached in the past [2].
That's ignoring the fact their project was born out of a company that operates front offices for one of the world's most aggressive spy agencies...
[1] https://medium.com/@fs0c131y/tchap-the-super-not-secure-app-...
[2] https://matrix.org/blog/2019/04/11/we-have-discovered-and-ad...
1. The Tchap issue was specific to the French deployment, rather than being a bug in Synapse or anything Matrix specific. (It was actually a bug in python, fwiw: https://bugs.python.org/issue34155. Agreed that it should have been caught internally though)
2. Yup, unfortunately matrix.org got pwned 4 years ago. (Thankfully E2EE means that encrypted conversations weren't compromised). This was a (bad) sysadmin fail; again, nothing to do with Matrix, the protocol, or the implementations (and the rest of the network was of course unaffected).
3. I've never seen any evidence of Amdocs being involved in spying, and many of the accusations there seem to be rooted in antisemitism. They acquired the two companies (one UK, one French) which turned into Matrix in 2010; we span out and set up Element in 2017.
2. Yup, unfortunately matrix.org got pwned 4 years ago. (Thankfully E2EE means that encrypted conversations weren't compromised). This was a (bad) sysadmin fail; again, nothing to do with Matrix, the protocol, or the implementations (and the rest of the network was of course unaffected).
3. I've never seen any evidence of Amdocs being involved in spying, and many of the accusations there seem to be rooted in antisemitism. They acquired the two companies (one UK, one French) which turned into Matrix in 2010; we span out and set up Element in 2017.
No Mossad conspiracy theories needed on Amdocs. Aren't they a major supplier of CALEA interception equipment to US law enforcement agencies?
I think that last claim deserves a citation.
Got a source for that third claim of yours?
https://en.wikipedia.org/wiki/Matrix_(protocol)#Funding_Cris...
AMDOCS has been accused multiple times of being an extension of Mossad, including in the US where the investigations got quietly ended. Leaked cables from 2009 showed they were also on the radar of South Africa's intelligence agency [1].
[1] https://www.news24.com/news24/spy-cables-were-israeli-spies-...
AMDOCS has been accused multiple times of being an extension of Mossad, including in the US where the investigations got quietly ended. Leaked cables from 2009 showed they were also on the radar of South Africa's intelligence agency [1].
[1] https://www.news24.com/news24/spy-cables-were-israeli-spies-...
Thanks for the links! It is very interesting, but I', not sure how/if what kind of influence this has on Matrix. Just because they were born out of a shady company, doesn't invalidate the project. Heck, we're using software (Disassemblers) that are maintained by the NSA (Ghidra) these days. Since they are open source (just like Matrix and Element) we can still be pretty sure that they're not doing anything shady.
> Just because they were born out of a shady company
shady because of accusations?
shady because of accusations?
I would guess the general idea is that the shadiness causes the accusations, not the other way around.
and what exactly is shady about Amdocs ?
Once this is deployed, Matrix will finally be providing the bare minimum to be actually workable. About time.
Then we can finally try and bring in everybody who's currently trapped in proprietary IM.
Then we can finally try and bring in everybody who's currently trapped in proprietary IM.
You're not exactly wrong, but you could have worded that a lot more kindly.
I'd say that this will remove my last hesitation I've had in recommending Matrix to people.
I'd say that this will remove my last hesitation I've had in recommending Matrix to people.
I tried (being kind).
What Matrix 2.0 fixes were true pain points which didn't keep me from using Matrix with my closest friends, but kept me from pushing Matrix to most people.
For a complete example, not that long ago (couple months), I had to wait over 10 minutes to send a message to somebody on Element on Android (on the street, trying to meet with them), because I turned connectivity on at that moment for the first time that day, and syncing took that long.
Now, this is instant, so is joining new rooms; This meets most people's expectation.
Having native videoconference is also very welcome, but the old hack was not a deal-breaker.
What Matrix 2.0 fixes were true pain points which didn't keep me from using Matrix with my closest friends, but kept me from pushing Matrix to most people.
For a complete example, not that long ago (couple months), I had to wait over 10 minutes to send a message to somebody on Element on Android (on the street, trying to meet with them), because I turned connectivity on at that moment for the first time that day, and syncing took that long.
Now, this is instant, so is joining new rooms; This meets most people's expectation.
Having native videoconference is also very welcome, but the old hack was not a deal-breaker.
> because I turned connectivity on at that moment for the first time that day, and syncing took that long.
So you had to sync all of the messages on the server first before sending a message?
So you had to sync all of the messages on the server first before sending a message?
That definitely used to be the case with Matrix. Sync has been improving gradually over the last year to alleviate that issue, though, assuming your server regularly gets updated and you keep your clients up to date.
Sync still takes a second in large rooms, but you no longer need to download a thousand messages just to see the three latest ones.
Sync still takes a second in large rooms, but you no longer need to download a thousand messages just to see the three latest ones.
When was that the case? I can't remember tbh, and it would have been insane for rooms like Matrix HQ.
Maybe before 2020?
Maybe before 2020?
At least a year ago, maybe longer. Syncing with the larger rooms in the Matrix homeserver definitely took its toll on self-hosted servers. Took minutes (at least) and couldn't be canceled.
Most of the problems lie in the clients though.
Which should improve with element X.
AIUI Element X is just an element build with these "Matrix 2.0" features. It is not a new client.
Both the servers and the clients will have to be updated to leverage them.
Both the servers and the clients will have to be updated to leverage them.
Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).
The features already exist serverside; we're just working on getting them out of beta.
The features already exist serverside; we're just working on getting them out of beta.
Thanks for the pointers, had no idea.
I am hopeful it also improves resource usage, bringing it closer to hydrogen.
Is this also for the desktop/browser version?
I am hopeful it also improves resource usage, bringing it closer to hydrogen.
Is this also for the desktop/browser version?
Also curious to know if it has web clients and desktop clients.
We're not planning to rewrite Element Web/Desktop in Rust (yet), so the current app will remain there - although we're going to give it a fairly major UI refresh to match the new mobile apps.
Also some performance optimizations would be most welcome for someone like me who is stuck with low power computers.
Is verification being implemented in hydrogen?
That'd make hydrogen minimally usable. Currently, all the other clients that are logged in constantly nag about an unverified and unverify-able hydrogen session existing!
Hydrogen works on older / weaker computers, where element is unusable.
That'd make hydrogen minimally usable. Currently, all the other clients that are logged in constantly nag about an unverified and unverify-able hydrogen session existing!
Hydrogen works on older / weaker computers, where element is unusable.
Please consider supporting running Element X natively on macOS M1/M2/etc devices, if you can do it. There is currently no native client for macOS at all.
I've been dogfooding the iPad layout of Element X under macOS on Apple Silicon since day 1 - it works pretty well. We could also ship it via Catalyst to run as a pure macOS app (albeit with the iPad layout) on both Apple Silicon and Intel, once https://github.com/rust-lang/rust/issues/106021 is fixed.
Unfortunately making it a "real" macOS app is much harder, as the UI is currently uses UIKit in a bunch of places to make up for feature and performance limitations in SwiftUI. These would have to be ported over to AppKit to run on macOS. I had a go at it over the holidays, but it's not trivial - perhaps someone with more AppKit skills than I could make it work (or maintain a fork) though.
To give an idea of the amount of UIKit that would need to be swapped out:
Unfortunately making it a "real" macOS app is much harder, as the UI is currently uses UIKit in a bunch of places to make up for feature and performance limitations in SwiftUI. These would have to be ported over to AppKit to run on macOS. I had a go at it over the holidays, but it's not trivial - perhaps someone with more AppKit skills than I could make it work (or maintain a fork) though.
To give an idea of the amount of UIKit that would need to be swapped out:
matthew@shadowfax ElementX % find . -name \*.swift | xargs perl -ne 'while (/[^a-zA-Z](UI[A-Z].*?)[^a-zA-Z]/g) { print "$1\n" }' | grep -v UITest | sort | uniq -c | sort -rn
52 UIKit
31 UIImage
20 UIApplication
13 UIScrollView
12 UITextView
11 UIDevice
11 UIConstants
10 UIColor
5 UIViewController
5 UIRectCorner
5 UIKitBackgroundTask
5 UIKeyCommand
4 UIView
4 UIPasteboard
4 UIBackgroundTaskIdentifier
3 UIViewControllerRepresentable
3 UITableView
3 UIScreen
3 UINavigationController
3 UIKitBackgroundTaskService
3 UIFont
3 UIActivityViewControllerWrapper
3 UIActivityViewController
2 UIViewRepresentableContext
2 UIViewControllerRepresentableContext
2 UITextViewWrapper
2 UITableViewDelegate
2 UIResponder
2 UIHostingController
2 UICollectionView
1 UIViewType
1 UIViewRepresentable
1 UITraitCollection
1 UITextViewDelegate
1 UITableViewDiffableDataSource
1 UITableViewController
1 UITableViewCell
1 UIScrollViewDelegate
1 UIKitAttributes
1 UIHostingConfiguration
1 UIContentSizeCategory
1 UIBezierPath
1 UIApplicationDelegateAdaptor
1 UIApplicationDelegate
1 UIActivityHonestly the iPad layout is probably "good enough" - though I agree that a macOS-AppKit-backed variant would be incredible.
I've got a lot of experience with AppKit and may be down to look at doing that fork once the churn on Element X is lower...
I've got a lot of experience with AppKit and may be down to look at doing that fork once the churn on Element X is lower...
ooh awesome. I'm just starting the video but I'm really hoping sharing is improved on iOS. Like full quality video sharing from the share sheets, or seeing my matrix rooms/contacts in the top row of contact suggestions, but most importantly the ability to add 'comments' to photos/links I share with people
e.g. share a link to a GitHub repo or a photo and be able to quickly say something in the same sheet without having to switch to the app and say the thing and the back to my browser
edit: had to use YouTube in the end: https://www.youtube.com/watch?v=eUPJ9zFV5IE
e.g. share a link to a GitHub repo or a photo and be able to quickly say something in the same sheet without having to switch to the app and say the thing and the back to my browser
edit: had to use YouTube in the end: https://www.youtube.com/watch?v=eUPJ9zFV5IE
The Matrix is my last hope for a free internet.
Really? Not IRC? Matrix is so heavy in terms of the protocol. It has almost all the state stored on the server instead of the client. That directly leads to legal/societal issues and now the server has to deal with. Unlike IRC which is basically just a bunch of sockets and IPs passing data without storing state.
And that's not even getting into the computational and network problems moving and saving all that state causes as addressed in this very update about how they're trying to mitigate the architectural problems I just mentioned. But they'll only be mitigations. And the legal/social problems will still exist and since everyone (ie, 99%) of people use the Riot.im/Element.io matrix.org homeserver that means social/legal pressures can be easily applied.
I like Matrix. I even use it for video chat because of the sars-cov-2 pandemic. But it is no hope for freedom.
And that's not even getting into the computational and network problems moving and saving all that state causes as addressed in this very update about how they're trying to mitigate the architectural problems I just mentioned. But they'll only be mitigations. And the legal/social problems will still exist and since everyone (ie, 99%) of people use the Riot.im/Element.io matrix.org homeserver that means social/legal pressures can be easily applied.
I like Matrix. I even use it for video chat because of the sars-cov-2 pandemic. But it is no hope for freedom.
If you watch the video, you'll see that we're making the client-server protocol crazy lightweight (https://youtu.be/eUPJ9zFV5IE?t=566) and that we're adding the ability to remove servers entirely and go full P2P: (https://youtu.be/eUPJ9zFV5IE?t=2155). So you're working on stale data here.
(Also, only about 35% of users we're aware of are on the matrix.org server, not 99%...)
(Also, only about 35% of users we're aware of are on the matrix.org server, not 99%...)
IRC is not a protocol that as it stands can meet modern user expectations of usability and functionality. If I can't use it to communicate with people at large, it is not a lot of freedom that is gained.
Most of what you complain about societal pressures either apply to IRC (access to specific servers) or outright fail IRC by default by not providing the feature (state).
Most of what you complain about societal pressures either apply to IRC (access to specific servers) or outright fail IRC by default by not providing the feature (state).
> Unlike IRC which is basically just a bunch of sockets and IPs passing data without storing state
To be honest this is probably reason #1 why people stopped using IRC. We want to see the messages that were sent while we weren't here. Yes I know what a bouncer is, no this is not a good solution.
IRC as a protocol is simple and elegant but as a product it doesn't meet today's users expectations at all. And you can't just say users expectations are wrong and they should just align with what IRC provides, it doesn't work like that.
To be honest this is probably reason #1 why people stopped using IRC. We want to see the messages that were sent while we weren't here. Yes I know what a bouncer is, no this is not a good solution.
IRC as a protocol is simple and elegant but as a product it doesn't meet today's users expectations at all. And you can't just say users expectations are wrong and they should just align with what IRC provides, it doesn't work like that.
The server/client dichotomy doesn't have to work in the typical "log into someone else's computer" way, you can run a homeserver locally and federate messages between servers.
You can. Just like you can run an email mailserver. About about the same proportion of people do.
IRC is nice, but it is very bare. I would somewhat understand if you mentioned Jabber, but even then Matrix is a superior choice these days.
IRC isn't bare. You're just looking at it wrong. IRC is the text communication layer of the internet which is the platform. Centralizing all functions into one protocol is not a great idea.
The world has moved beyond where just text is sufficient, IRC as a protocol is no longer relevant, sad but true.
And I say that as a regular on multiple IRC networks, some through Matrix bridge.
And I say that as a regular on multiple IRC networks, some through Matrix bridge.
For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.
Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.
[1] - https://github.com/thelounge
[2] - https://thelounge.chat/
[3] - https://github.com/convos-chat/convos/
[4] - https://convos.chat/
[5] - https://www.mumble.info/
[6] - https://github.com/umurmur/umurmur/wiki/Configuration
Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.
[1] - https://github.com/thelounge
[2] - https://thelounge.chat/
[3] - https://github.com/convos-chat/convos/
[4] - https://convos.chat/
[5] - https://www.mumble.info/
[6] - https://github.com/umurmur/umurmur/wiki/Configuration
> For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.
At that point you've just reimplemented a less-standard version of matrix with extra steps though. Your protocol has become heavyweight and non-standard (you could argue it degrades gracefully to IRC, but in practice using your enhanced server from an unenhanced client will always be painful), you're holding state on the server in the same way you were worried about (and without the mitigation of E2EE)...
At that point you've just reimplemented a less-standard version of matrix with extra steps though. Your protocol has become heavyweight and non-standard (you could argue it degrades gracefully to IRC, but in practice using your enhanced server from an unenhanced client will always be painful), you're holding state on the server in the same way you were worried about (and without the mitigation of E2EE)...
> At that point you've just reimplemented a less-standard version of matrix with extra steps though.
There are IRCv3 specifications that allow this richer experience, and they are at least as standard as Matrix. Check out https://ergo.chat/ with modern clients like https://sr.ht/~emersion/goguma/ (Android), https://git.sr.ht/~emersion/gamja/ https://kiwiirc.com/ (web), or https://git.sr.ht/~taiite/senpai (TUI)
> but in practice using your enhanced server from an unenhanced client will always be painful
IRCv3 normally makes sure new specs don't make it worse for older clients. Could you give me some examples to see if we can fix that?
There are IRCv3 specifications that allow this richer experience, and they are at least as standard as Matrix. Check out https://ergo.chat/ with modern clients like https://sr.ht/~emersion/goguma/ (Android), https://git.sr.ht/~emersion/gamja/ https://kiwiirc.com/ (web), or https://git.sr.ht/~taiite/senpai (TUI)
> but in practice using your enhanced server from an unenhanced client will always be painful
IRCv3 normally makes sure new specs don't make it worse for older clients. Could you give me some examples to see if we can fix that?
> There are IRCv3 specifications that allow this richer experience, and they are at least as standard as Matrix.
"At least as standard" how? A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on. And there seem to be more visibly independent implementations of Matrix than IRCv3.
> IRCv3 normally makes sure new specs don't make it worse for older clients. Could you give me some examples to see if we can fix that?
Speaking generically rather than IRCv3-specific, things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps). And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs. (Or for a more serious example, SSO access control; you just can't do that in a nice way if the client doesn't support it). This kind of thing is what killed the Slack IRC gateway, and it comes back to the first point, because it's ultimately more of a social issue than a technical one: a substantial portion of the IRC community uses clients that don't support these things not because they can't but because they're hostile to the very idea of having embedded gifs or SSO in IRC.
"At least as standard" how? A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on. And there seem to be more visibly independent implementations of Matrix than IRCv3.
> IRCv3 normally makes sure new specs don't make it worse for older clients. Could you give me some examples to see if we can fix that?
Speaking generically rather than IRCv3-specific, things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps). And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs. (Or for a more serious example, SSO access control; you just can't do that in a nice way if the client doesn't support it). This kind of thing is what killed the Slack IRC gateway, and it comes back to the first point, because it's ultimately more of a social issue than a technical one: a substantial portion of the IRC community uses clients that don't support these things not because they can't but because they're hostile to the very idea of having embedded gifs or SSO in IRC.
> "At least as standard" how?
There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.
The IRCv3 working group is made of plenty of organizations (non-exhaustive lists at https://ircv3.net/participation / https://ircv3.net/charter) with at most two "representatives" each.
> A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.
But any IRC client will work fine on any IRC server, and they can simultaneously connect to various servers which support variants of the protocol (eg. through capability negotiation). Also note that 75% of servers support IRCv3 capability negotiation: https://www.ircstats.org/server-features/cap (and the others are often at all not developed anymore)
On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.
It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".
> And there seem to be more visibly independent implementations of Matrix than IRCv3.
Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.
In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility). And I can't think of any non-Synapse server, besides Matrix devs self-hosting.
Meanwhile, IRC servers: https://www.ircstats.org/servers (note: this counts servers and not networks or users)
> things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)
You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.
> And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.
A conversation where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.
Speaking of which, Matrix does not provide a way to provide alt-text to images and videos, which ends up excluding plenty of people as well. (To be specific, the spec technically does provide a way, but clients use it for filenames instead: https://github.com/vector-im/element-web/issues/22100#issuec... )
> SSO access control; you just can't do that in a nice way if the client doesn't support it
That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring design and implementations (https://emersion.fr/blog/2022/irc-and-oauth2/).
There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.
The IRCv3 working group is made of plenty of organizations (non-exhaustive lists at https://ircv3.net/participation / https://ircv3.net/charter) with at most two "representatives" each.
> A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.
But any IRC client will work fine on any IRC server, and they can simultaneously connect to various servers which support variants of the protocol (eg. through capability negotiation). Also note that 75% of servers support IRCv3 capability negotiation: https://www.ircstats.org/server-features/cap (and the others are often at all not developed anymore)
On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.
It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".
> And there seem to be more visibly independent implementations of Matrix than IRCv3.
Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.
In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility). And I can't think of any non-Synapse server, besides Matrix devs self-hosting.
Meanwhile, IRC servers: https://www.ircstats.org/servers (note: this counts servers and not networks or users)
> things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)
You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.
> And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.
A conversation where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.
Speaking of which, Matrix does not provide a way to provide alt-text to images and videos, which ends up excluding plenty of people as well. (To be specific, the spec technically does provide a way, but clients use it for filenames instead: https://github.com/vector-im/element-web/issues/22100#issuec... )
> SSO access control; you just can't do that in a nice way if the client doesn't support it
That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring design and implementations (https://emersion.fr/blog/2022/irc-and-oauth2/).
> There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.
There is a bunch of missing context here. Firstly, Matrix predates Element. When the team who created Matrix set up the Spec Core Team, we deliberately went for a 4:5 mix of folks from the founding project team mixed with folks from the community. Specifically: me (Matthew), Dave, Erik and Rich from the original team, and Hubert, Travis, Andrew, Alexey and mujx from the wider Matrix community. At around the same time, the original Matrix team set up Element as a way to try to fund us to work on Matrix as our dayjobs.
The catch however is that Hubert/Travis/Andrew got so enthusiastic about Matrix that they wanted to do it as their day job - and at the time, Element was the only place you could do that, and so they applied to work at Element. We reasoned that the best outcome for Matrix would be if they were able to work on Matrix fulltime, and so prioritised that over the heterogeneity of the Spect Core Team. They were explicitly asked to participate in the SCT discussions with their community rather than Element-employee hats on, though, and they continue to do so.
Finally, the actual Guardians (Directors of the Matrix Foundation) who ensure that the project remains neutral are 3:2 mix of independent v. Matrix founders. So if anyone thinks that the SCT is deviating from its neutrality, they can and should appeal to the Guardians, who then have the ability to shake up the SCT as needed.
So yes, this is more complicated than a simple 'design by committee' approach, but I'd argue that it gives the ability for the protocol to evolve more rapidly and with less bikeshedding - and meanwhile we have the checks & balances to keep things on track.
> This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.
The official room versions are defined by the SCT; nothing to do with synapse devs. It's the SCT which prevents fragmentation. Synapse and other homeservers can (and do) go wild experimenting with different room versions.
> It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".
Yes, it's very common for people to complain that their favourite feature hasn't been added to the spec yet, or that their unsolicited PR to Element got wedged because the Element team is trying to build a focused coherent app rather than a kitchen sink.
On spec stuff, the solution is to implement the feature anyway on a prefix, demonstrate its usefulness, and then the MSC is easy to unblock. On unsolicited PRs to Element, the solution is to demonstrate it on a branch, or fork, or implement it on a different client. Again, features which have been proven to work well in the wild are easy to incorporate into the official spec.
There is a bunch of missing context here. Firstly, Matrix predates Element. When the team who created Matrix set up the Spec Core Team, we deliberately went for a 4:5 mix of folks from the founding project team mixed with folks from the community. Specifically: me (Matthew), Dave, Erik and Rich from the original team, and Hubert, Travis, Andrew, Alexey and mujx from the wider Matrix community. At around the same time, the original Matrix team set up Element as a way to try to fund us to work on Matrix as our dayjobs.
The catch however is that Hubert/Travis/Andrew got so enthusiastic about Matrix that they wanted to do it as their day job - and at the time, Element was the only place you could do that, and so they applied to work at Element. We reasoned that the best outcome for Matrix would be if they were able to work on Matrix fulltime, and so prioritised that over the heterogeneity of the Spect Core Team. They were explicitly asked to participate in the SCT discussions with their community rather than Element-employee hats on, though, and they continue to do so.
Finally, the actual Guardians (Directors of the Matrix Foundation) who ensure that the project remains neutral are 3:2 mix of independent v. Matrix founders. So if anyone thinks that the SCT is deviating from its neutrality, they can and should appeal to the Guardians, who then have the ability to shake up the SCT as needed.
So yes, this is more complicated than a simple 'design by committee' approach, but I'd argue that it gives the ability for the protocol to evolve more rapidly and with less bikeshedding - and meanwhile we have the checks & balances to keep things on track.
> This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.
The official room versions are defined by the SCT; nothing to do with synapse devs. It's the SCT which prevents fragmentation. Synapse and other homeservers can (and do) go wild experimenting with different room versions.
> It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".
Yes, it's very common for people to complain that their favourite feature hasn't been added to the spec yet, or that their unsolicited PR to Element got wedged because the Element team is trying to build a focused coherent app rather than a kitchen sink.
On spec stuff, the solution is to implement the feature anyway on a prefix, demonstrate its usefulness, and then the MSC is easy to unblock. On unsolicited PRs to Element, the solution is to demonstrate it on a branch, or fork, or implement it on a different client. Again, features which have been proven to work well in the wild are easy to incorporate into the official spec.
Thank you for the links, I prefer to use Matrix(Element on mobile and gomuks in cli on workstations), I also use weechat for certain networks that don't allow bridging with matrix, I also bridge slack into same weechat.
But this doesn't change the fact that irc is obscure minority now, no matter how many shiny web interfaces we put on top of it, so embracing the actually open platform that has a chance of gaining any traction is a no-brainer.
But this doesn't change the fact that irc is obscure minority now, no matter how many shiny web interfaces we put on top of it, so embracing the actually open platform that has a chance of gaining any traction is a no-brainer.
But this doesn't change the fact that irc is obscure minority now
Agreed. I still use it when I need a quick way to chat. That and Devzat SSH chat. I can fire up NGIrcd in about 3 minutes and most of that time is dealing with LetsEncrypt. UnrealIRCD is my preferred IRCD but the configuration is more involved so I don't bother since most people moved to Discord.
Out of curiosity since I have never used Matrix, how many clients can one node/server simultaneously support approximately?
Agreed. I still use it when I need a quick way to chat. That and Devzat SSH chat. I can fire up NGIrcd in about 3 minutes and most of that time is dealing with LetsEncrypt. UnrealIRCD is my preferred IRCD but the configuration is more involved so I don't bother since most people moved to Discord.
Out of curiosity since I have never used Matrix, how many clients can one node/server simultaneously support approximately?
>Out of curiosity since I have never used Matrix, how many clients can one node/server simultaneously support approximately?
Sorry, I don't know if I'm being honest :) The one I run is used by just few people. Matrix isn't so "internal community" focused like Mastodon in its federation.
Sorry, I don't know if I'm being honest :) The one I run is used by just few people. Matrix isn't so "internal community" focused like Mastodon in its federation.
The world has also moved beyond just text 20 years ago and we were all supposed to switch to Jabber/XMPP. And yet here I am using IRC as much as ever. If I end up using Matrix it will probably be from my favorite IRC client through some kind of gateway, just like all the IM protocols that have come and gone over the decades.
Nothing wrong with that, hooray for open standards that welcome bridging and interconnectivity (I'm looking at you, Discord).
But you have to admit, irc is a tiny tiny part of IM usage popularity wise, and it's not for no reason.
But you have to admit, irc is a tiny tiny part of IM usage popularity wise, and it's not for no reason.
People still use Usenet, which doesn't mean it's superior to http+html.
Why is it not a great idea? It’s what every other platform has done for over a decade now and it’s working great. It’s absurd that I shouldn’t be able to send someone an image inline or make a call in a group chat.
And now the server is hosting images and has to police that or it gets shut down. And suddenly content moderation is #2 priority for the service, behind #1 profit, but well ahead of providing a space for communities.
You have to police illegal content even if it’s just links. That’s why torrent sites get shut down constantly.
Curating and sharing links is the same as hosting. And I’m quite happy to be on a platform which doesn’t share or host this content.
Curating and sharing links is the same as hosting. And I’m quite happy to be on a platform which doesn’t share or host this content.
Nope. No one has to or is policing the links people chat about on IRC. Why? Because the server isn't saving state and hosting it. It's all in people's clients. It cuts the gordian knot of content moderation.
You can use Matrix IRC Bridge.
In pratice there is only the Riot.im/Element.io Matrix.org homeserver to Libera.chat IRC server bridge. And that bridge regularly disconnects people for being idle because storing and transferring state is so heavy.
Not only that, but if you're disconnected and reconnected again, you lose your ident if your nickname contains uppercase characters or underscores: https://github.com/matrix-org/matrix-appservice-irc/issues/1...
What stops you from running your own bridge?
The reason for this limitation is actually on the IRC side - we can only have so many users connected via Matrix, so we need to time out stale ones.
I asked around and it seems like you're right about it not being a resource issue (network or computational). The issue is that the bridge is unstable and having tens of thousands of matrix.org users join/parting every now and then disrupts the IRC channels.
It's also mentioned in Libera's FAQ:
> At our request, the EMS-hosted Libera.Chat bridge regularly prunes idle connections to minimize disruptions to IRC channels during bridge restarts.
-- https://libera.chat/guides/faq#can-i-connect-with-matrix
> At our request, the EMS-hosted Libera.Chat bridge regularly prunes idle connections to minimize disruptions to IRC channels during bridge restarts.
-- https://libera.chat/guides/faq#can-i-connect-with-matrix
Has anyone taken a look at https://keet.io/?
'The' Matrix, or 'Matrix'?
I've been slowly getting wow'ed by the current developments in Nostr, which could be a great, new open protocol for social media. The native implementation of lightning network payments, and the ability to follow paid relays without needing to be bound to them is pretty cool.
I've been slowly getting wow'ed by the current developments in Nostr, which could be a great, new open protocol for social media. The native implementation of lightning network payments, and the ability to follow paid relays without needing to be bound to them is pretty cool.
Does anyone know how this will work for us folks hosting ourselves? Do we set up a new instance of a sliding sync server, with it's own DB and all that, or do we wait for it to all get integrated into the existing Docker deploy somehow? I'm really excited to hop on the new ElementX client ASAP, which will apparently not work with anything but sliding sync.
If you’re really eager to try it out, then apparently you will need to set up the sliding sync proxy in front of your homeserver.
What are the implications of these changes for someone else wanting to make an interoperable Matrix server or client from scratch?
Will it be easier than before?
(I've written several IRC clients, and a simple one could be done in an afternoon with only a sockets/TLS library. But when I looked at Matrix briefly, implementation seemed very big-moat. And now it's a rapidly moving target.)
Will it be easier than before?
(I've written several IRC clients, and a simple one could be done in an afternoon with only a sockets/TLS library. But when I looked at Matrix briefly, implementation seemed very big-moat. And now it's a rapidly moving target.)
Matrix clients should be super easy to write - e.g. https://news.ycombinator.com/item?id=20948530
Servers are definitely harder - it's probably similar complexity to writing a git implementation (given it's basically doing the same operation: synchronising DAGs of commits between replicas of a chat room).
In terms of it being a rapidly moving target: from memory we've never broken backwards compatibility on Matrix since day 1 back in 2014. "Matrix 2.0" is not a breaking change; it's just adding some new APIs to change performance to be O(1) rather than O(N) (and switching to OIDC for auth and native VoIP for multiparty).
So, overall, I'd say it makes things easier: both Matrix client & server authors will no longer have to mess around implementing custom auth (which was a huge burden to get right), but be able to use existing mature OIDC implementations. Meanwhile, the new sync API should be as easy as the old one (although we haven't really done a like for like comparison yet, given we've been obsessing about driving the new sync API as efficiently as possible)
Servers are definitely harder - it's probably similar complexity to writing a git implementation (given it's basically doing the same operation: synchronising DAGs of commits between replicas of a chat room).
In terms of it being a rapidly moving target: from memory we've never broken backwards compatibility on Matrix since day 1 back in 2014. "Matrix 2.0" is not a breaking change; it's just adding some new APIs to change performance to be O(1) rather than O(N) (and switching to OIDC for auth and native VoIP for multiparty).
So, overall, I'd say it makes things easier: both Matrix client & server authors will no longer have to mess around implementing custom auth (which was a huge burden to get right), but be able to use existing mature OIDC implementations. Meanwhile, the new sync API should be as easy as the old one (although we haven't really done a like for like comparison yet, given we've been obsessing about driving the new sync API as efficiently as possible)
> Matrix clients should be super easy to write - e.g. https://news.ycombinator.com/item?id=20948530
The script in your follow-up github link is still missing escapes of tokens and room id (which can both be arbitrary strings according to the specs) btw. And you should add 500/502/503 error handling, these happen fairly often on non-tiny accounts in my experience, even outside matrix.org
> from memory we've never broken backwards compatibility on Matrix
* https://spec.matrix.org/v1.5/changelog/ has a handful of "Breaking changes" sections since 2021
* https://matrix.org/docs/spec/client_server/r0.6.0.html#chang... , https://matrix.org/docs/spec/client_server/r0.5.0.html#chang... , etc. have a few more before 2021
* Removing reply fallbacks (recommended by MSC3676 and already implemented by at least some clients) causes other clients to miss notifications
The script in your follow-up github link is still missing escapes of tokens and room id (which can both be arbitrary strings according to the specs) btw. And you should add 500/502/503 error handling, these happen fairly often on non-tiny accounts in my experience, even outside matrix.org
> from memory we've never broken backwards compatibility on Matrix
* https://spec.matrix.org/v1.5/changelog/ has a handful of "Breaking changes" sections since 2021
* https://matrix.org/docs/spec/client_server/r0.6.0.html#chang... , https://matrix.org/docs/spec/client_server/r0.5.0.html#chang... , etc. have a few more before 2021
* Removing reply fallbacks (recommended by MSC3676 and already implemented by at least some clients) causes other clients to miss notifications
> "Matrix 2.0" is not a breaking change
Was there really no better name for the talk?
Semver does not apply to everything, and definitely not to end products aimed at consumers.
Except that Matrix is a protocol, and the end products using it may like to know that v2.0 (which says "I'm breaking backward compatibility") is actually not breaking backward compatibility.
I must acknowledge I was very spooked by the 2.0 in there
I don't see the end-to-end encryption there. Nor any of the other tablestakes features.
Well, if you want end-to-end encryption, then obviously that's going to be hard to write from scratch(!) - especially if you want it to be secure. However, we make it trivial to get up and running by piping your client through a proxy like Pantalaimon (https://github.com/matrix-org/pantalaimon/) which takes your normal traffic and makes it E2EE.
Not sure which "any of the other tablestakes features" you have in mind... obviously if you want loads of features, then you're going to have to write a whole bunch of code to implement them in your client, or build on an existing SDK like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc. Not sure that's a disadvantage of Matrix though(!)
Not sure which "any of the other tablestakes features" you have in mind... obviously if you want loads of features, then you're going to have to write a whole bunch of code to implement them in your client, or build on an existing SDK like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc. Not sure that's a disadvantage of Matrix though(!)
I recall the selling point of Matrix being security. (Otherwise, we could just use IRC.)
The conventional IETF-ish Internet ideal of open standards is to have a specification that is implementable.
When the selling point is security, insecure implementations don't help us.
Suggesting an off-the-shelf proxy kludge doesn't clearly answer how implementable it is.
Sounds like you're saying that the protocol (with necessary security) is hard to implement. Do the new changes affect that one way or the other?
The conventional IETF-ish Internet ideal of open standards is to have a specification that is implementable.
When the selling point is security, insecure implementations don't help us.
Suggesting an off-the-shelf proxy kludge doesn't clearly answer how implementable it is.
Sounds like you're saying that the protocol (with necessary security) is hard to implement. Do the new changes affect that one way or the other?
> When the selling point is security, insecure implementations don't help us.
I'm not sure using a proxy is my preferred solution either, but if you're worried about insecure implementations doesn't it make a ton of sense to separate the E2EE implementation from the rest of the client implementation?
My ideal when using an experimental Matrix client if I don't know the developers involved would be for their experimental code to be quarantined away from the encryption code. That way I don't have to worry so much about whether their implementation is insecure, I know they're just using something off-the-shelf.
Whether the proxy in specific is the best way to do that, :shrug:, but my instinct is that pushing messages through some kind of separate encryption/decryption handler that can be verified on its own and reused by multiple clients isn't a bad idea. That approach seems like good security practice to me. Am I missing something?
I'm not sure using a proxy is my preferred solution either, but if you're worried about insecure implementations doesn't it make a ton of sense to separate the E2EE implementation from the rest of the client implementation?
My ideal when using an experimental Matrix client if I don't know the developers involved would be for their experimental code to be quarantined away from the encryption code. That way I don't have to worry so much about whether their implementation is insecure, I know they're just using something off-the-shelf.
Whether the proxy in specific is the best way to do that, :shrug:, but my instinct is that pushing messages through some kind of separate encryption/decryption handler that can be verified on its own and reused by multiple clients isn't a bad idea. That approach seems like good security practice to me. Am I missing something?
Modern XMPP+OMEMO has a stronger security story and isn't controlled by a single corporation with a CEO who can't help but get involved in every HN thread about his product, and there are multiple working clients for every platform, which is something Matrix can barely claim
Of course "Arathorn" would say it's easy to implement a client for the protocol he controls unilaterally, it's in his interest to get you locked in!
There is one cross platform client for matrix and it drives the features: element
I say this from a place of current experience, as I run a server and use element and fluffy chat, each of which has its own issues. If it's so easy, where are the others? Why is there only one third party home server available that is only partially implemented? XMPP offers at least three to choose from. Now /that/ is a real protocol
There is zero benefit for choosing matrix over XMPP
Of course "Arathorn" would say it's easy to implement a client for the protocol he controls unilaterally, it's in his interest to get you locked in!
There is one cross platform client for matrix and it drives the features: element
I say this from a place of current experience, as I run a server and use element and fluffy chat, each of which has its own issues. If it's so easy, where are the others? Why is there only one third party home server available that is only partially implemented? XMPP offers at least three to choose from. Now /that/ is a real protocol
There is zero benefit for choosing matrix over XMPP
[deleted]
I would love to recommend Matrix to friends, but the last time I looked, migration of chat history from other protocols was still in development. Has anything changed here, particularly wrt WhatsApp?
It's supported, e.g. mautrix-telegram uses it: https://github.com/mautrix/telegram/blob/master/ROADMAP.md
Cant really talk about WhatsApp. The term you should be searching for in the bridge documentation is "backfill".
On Telegram it works fine for me.
On Telegram it works fine for me.
IMO WhatsApp bridge requires you to have a WhatsApp account logged into the bot who uses it as WhatsApp web.
It saves you the trouble of opening two apps. Nothing more.
We should have telegram style bridge that let's you talk to WhatsApp accounts without having an account in WhatsApp.
Maybe EU DMA will do it? I don't know
It saves you the trouble of opening two apps. Nothing more.
We should have telegram style bridge that let's you talk to WhatsApp accounts without having an account in WhatsApp.
Maybe EU DMA will do it? I don't know
> It saves you the trouble of opening two apps. Nothing more.
I use the Element One subscription, with bridges to Signal and WhatsApp.
It enables a bit more than "not having to open two apps" (although that in itself is nice). It means that I have one, good, client on any platform I want and it has all the messaging. I don't have to double up the client on every platform I want to read/write messages on.
Plus, I get a proper backup of all my messages without having to worry about how that happens on WhatsApp and Signal (the Signal situation is a bit complicated here).
I use the Element One subscription, with bridges to Signal and WhatsApp.
It enables a bit more than "not having to open two apps" (although that in itself is nice). It means that I have one, good, client on any platform I want and it has all the messaging. I don't have to double up the client on every platform I want to read/write messages on.
Plus, I get a proper backup of all my messages without having to worry about how that happens on WhatsApp and Signal (the Signal situation is a bit complicated here).
> IMO WhatsApp bridge requires you to have a WhatsApp account logged into the bot who uses it as WhatsApp web.
That seems like a strange statement to preface with "IMO".
That seems like a strange statement to preface with "IMO".
why not? i've not personally done a bridge yet and all the docs i've read say that but i had someone inform me last time "whatsapp bridge does not require a whatsapp number now" but i've not been able to find records for that so yeah, in my opinion, that is the current practice but i am not sure
Because it seems like a factual statement that can be verified to be either right or wrong, not something that can be an opinion. Maybe "IIUC" would have made more sense than "IMO".
@Arathorn, proud operator of Synapse (for 2+ years) chiming in! Another superb conference talk and thank you for all you do.
We're running an ancient build. Is your Synapse installation walk-through [1] still the latest/greatest guidance in getting started, for those looking to refresh their environment?
[1] https://www.youtube.com/watch?v=dDddKmdLEdg
We're running an ancient build. Is your Synapse installation walk-through [1] still the latest/greatest guidance in getting started, for those looking to refresh their environment?
[1] https://www.youtube.com/watch?v=dDddKmdLEdg
thanks :) yup, the old Synapse walk-through should still be accurate - I need to record a new one!
The demos in this are pretty hot. Awesome work Matrix folks!
Also, https://thirdroom.io/ is very interesting!
https://github.com/matrix-org/thirdroom
Also, https://thirdroom.io/ is very interesting!
https://github.com/matrix-org/thirdroom
While pushing for the spec to be useful is fine they've forgot the important things: usability.
Even now, after nearly 12 months the reference client manages to lock android up (multiple devices, 11-13) to the point where every other app hangs and the only fix is a reboot.
There are ecosystem failings too but none of those are as bad as having exactly 0 usable clients on a platform that has such a huge market share.
I want to know if you intend to fix it or just ignore it? (For Aaron)
Also as a bonus answer, how 45 million ends up with nothing to show for it.
Even now, after nearly 12 months the reference client manages to lock android up (multiple devices, 11-13) to the point where every other app hangs and the only fix is a reboot.
There are ecosystem failings too but none of those are as bad as having exactly 0 usable clients on a platform that has such a huge market share.
I want to know if you intend to fix it or just ignore it? (For Aaron)
Also as a bonus answer, how 45 million ends up with nothing to show for it.
Are there any guides or examples of chat rooms for open source projects using Matrix?
We would like GitHub integration, strong spam/moderation features, and avoid the hassle of self-hosting. gitter.im used to provide those, but they were lost in the Matrix switch.
We would like GitHub integration, strong spam/moderation features, and avoid the hassle of self-hosting. gitter.im used to provide those, but they were lost in the Matrix switch.
Matrix's moderation should be at least as good as Gitter. The GitHub integration is okay (it lets you create/comment/resolve issues using your GitHub identity from Matrix, and also can expose GitHub issues as Matrix rooms using https://github.com/matrix-org/matrix-hookshot). It's not quite as tightly integrated as GitHub was to Gitter though, but we're working on putting it in the Right Panel.
Some example Matrix communities which seem to work well include Mozilla (chat.mozilla.org), GNOME (https://matrix.to/#/#community:gnome.org) and KDE (https://webchat.kde.org/). Smaller ones include folks like Helix editor: https://matrix.to/#/#helix-community:matrix.org. I don't think anyone's written a guide for getting up and running though, which in retrospect is a crying shame; we'll get it on the todo list.
(p.s. thanks for Hex Fiend! :D)
Some example Matrix communities which seem to work well include Mozilla (chat.mozilla.org), GNOME (https://matrix.to/#/#community:gnome.org) and KDE (https://webchat.kde.org/). Smaller ones include folks like Helix editor: https://matrix.to/#/#helix-community:matrix.org. I don't think anyone's written a guide for getting up and running though, which in retrospect is a crying shame; we'll get it on the todo list.
(p.s. thanks for Hex Fiend! :D)
>Matrix's moderation should be at least as good as Gitter
Well, yes and no. The moderation features might be the same, but:
1. It's a lot easier to make matrix accounts, especially if you run your own server.
2. The user interface for blocking an entire server is basically missing? The only thing I can find has you run a bot to do it?
So if someone with their own homeserver wants to troll you, you end up playing wack-a-mole unless you self-host a bot. At least that's the best I can find so far.
Well, yes and no. The moderation features might be the same, but:
1. It's a lot easier to make matrix accounts, especially if you run your own server.
2. The user interface for blocking an entire server is basically missing? The only thing I can find has you run a bot to do it?
So if someone with their own homeserver wants to troll you, you end up playing wack-a-mole unless you self-host a bot. At least that's the best I can find so far.
Gnome, KDE, and Mozilla seem to use Matrix (with bridges where necessary). Those are quite big players in the open source space.
I don't know how well the public Github bots will work for your use case. The moderation tools are also relatively crude in my experience; at the protocol level reports/ACLs/reporting is quite easy to use, but there's no easy Matrix moderator frontend that I know of. There's a bot (mjolnir) but not a separate UI.
You can pay people to host your Matrix server or you can use the public home servers to set up your community/spaces. Self hosting usually isn't necessary.
I don't know how well the public Github bots will work for your use case. The moderation tools are also relatively crude in my experience; at the protocol level reports/ACLs/reporting is quite easy to use, but there's no easy Matrix moderator frontend that I know of. There's a bot (mjolnir) but not a separate UI.
You can pay people to host your Matrix server or you can use the public home servers to set up your community/spaces. Self hosting usually isn't necessary.
OSS projects that use matrix for official comms (of the top of my head) - Fedora, Ansible, sonixd, binrw, gotosocial, helix and ofc matrix & associated project.
We use Matrix for our open source project: https://wiki.mathesar.org/en/community/matrix. We self-host a Synapse homeserver, but there's no reason why you can't set up a community on one of the big existing servers (e.g. matrix.org). Their Spaces feature allows you to package groups of channels together.
I set up Maubot for GitHub integration: https://github.com/maubot/github. There are moderation features, but we haven't had to use them.
I set up Maubot for GitHub integration: https://github.com/maubot/github. There are moderation features, but we haven't had to use them.
I mean, define "GitHub integration". It's relatively straightforward to put a bot together that just emits webhook notifications - otherwise Maubot seems to be the route of choice here.
[deleted]
Any word on EU DMA and other messaging interoperability? ....
.
Is there some github repo or some other place where orgs are discussing this?
Is there some github repo or some other place where orgs are discussing this?
There's https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-t... and https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-m... and associated work around the IETF MIMI group, where we're proposing Matrix as a solution to DMA interop.
NB: I can't seem to watch or download the videos
here's a YouTube alternative; the files on the ftp.* host seem to be 0 bytes: https://www.youtube.com/watch?v=eUPJ9zFV5IE
Fab, thank you!
Video not available yet?
Unfortunately, no one can be told what the Matrix is. You have to see it for yourself.
How Matrix is better then SIP?
The Matrix team spent 15 years building SIP stacks before we gave up and created Matrix, so I can answer this with some confidence:
Superficially, Matrix looks a bit like SIP: for 1:1 calls, you send an m.call.invite (like a SIP INVITE) to someone; they answer with an m.call.answer (like a SIP 200 OK); eventually someone hangs up with an m.call.hangup (like a SIP BYE). However, the differences are:
* As a transport, everything goes over normal Matrix signalling (by default HTTPS+JSON) rather than SIP's mix of UDP and TLS sockets. As a result, no need for SIP's three-way handshakes inherited from its UDP transport
* As a result, you inherit Matrix's end-to-end-encryption and decentralisation for free (so no special Routes, Vias, Record-Routes, branch parameters etc from SIP - it uses the Matrix client-server and server-server APIs over HTTPS instead)
* Everything is trickle ICE by default for rapid call setup, no need to wait until you have all the ICE candidates to proceed with the call
* No offerful/offerless invites: everything is offerful.
* Matrix piggybacks on WebRTC for its media protocol, so you don't have the fragmentation of different media transports that SIP has inherited
* Matrix (as of https://github.com/matrix-org/matrix-spec-proposals/blob/mat...) now supports multiparty native VoIP calls in the same conversation: effectively letting you signal full-mesh, SFU and MCU style multiway video/voip using the same mechanism as you'd use for a 1:1 call. This is probably the biggest difference in the end: with Matrix's VoIP you can jump straight in and have interoperable Zoom/Teams/Jitsi style conferences (as shown in the OP at https://youtu.be/eUPJ9zFV5IE?t=1513) - Matrix isn't just for boring old PSTN/PBX-style 1:1 calls, but for the conferences folks actually expect to use today.
You can play with it at https://call.element.io, and if you really want to compare with SIP, go to the developer tools in options and turn on callflow mode, which will draw little mermaid sequence diagrams of the call signalling for the calls, so you can see precisely what's going on :)
Superficially, Matrix looks a bit like SIP: for 1:1 calls, you send an m.call.invite (like a SIP INVITE) to someone; they answer with an m.call.answer (like a SIP 200 OK); eventually someone hangs up with an m.call.hangup (like a SIP BYE). However, the differences are:
* As a transport, everything goes over normal Matrix signalling (by default HTTPS+JSON) rather than SIP's mix of UDP and TLS sockets. As a result, no need for SIP's three-way handshakes inherited from its UDP transport
* As a result, you inherit Matrix's end-to-end-encryption and decentralisation for free (so no special Routes, Vias, Record-Routes, branch parameters etc from SIP - it uses the Matrix client-server and server-server APIs over HTTPS instead)
* Everything is trickle ICE by default for rapid call setup, no need to wait until you have all the ICE candidates to proceed with the call
* No offerful/offerless invites: everything is offerful.
* Matrix piggybacks on WebRTC for its media protocol, so you don't have the fragmentation of different media transports that SIP has inherited
* Matrix (as of https://github.com/matrix-org/matrix-spec-proposals/blob/mat...) now supports multiparty native VoIP calls in the same conversation: effectively letting you signal full-mesh, SFU and MCU style multiway video/voip using the same mechanism as you'd use for a 1:1 call. This is probably the biggest difference in the end: with Matrix's VoIP you can jump straight in and have interoperable Zoom/Teams/Jitsi style conferences (as shown in the OP at https://youtu.be/eUPJ9zFV5IE?t=1513) - Matrix isn't just for boring old PSTN/PBX-style 1:1 calls, but for the conferences folks actually expect to use today.
You can play with it at https://call.element.io, and if you really want to compare with SIP, go to the developer tools in options and turn on callflow mode, which will draw little mermaid sequence diagrams of the call signalling for the calls, so you can see precisely what's going on :)
I'd be curious to hear what would be something that SIP is actually better than Matrix at, any ideas? :)
SIP has been here since 1999, telecommunications also adopted it, lots of stable software, smooth cooperation, lots of suppliers.
Some thought that by introducing a new protocol they could generate better business/profit. I see no other advantage in Matrix.
There's nothing important in Matrix that can't be done in SIP, and there's nothing in Matrix that's much more deserving of a new protocol. There are many standard extensions for SIP, and if you're still missing something, it's easy to add.
Disclaimer: I am a SIP fan and I hate reinwenting the wheel
Some thought that by introducing a new protocol they could generate better business/profit. I see no other advantage in Matrix.
There's nothing important in Matrix that can't be done in SIP, and there's nothing in Matrix that's much more deserving of a new protocol. There are many standard extensions for SIP, and if you're still missing something, it's easy to add.
Disclaimer: I am a SIP fan and I hate reinwenting the wheel
Matrix: good specs and protocol , but product wise , it offer nothing new compared to RocketChat , Slack , Mattermost . High noise low signal.
Zulip is the actual game changer in innovation of the conversation flow and makes the team actually more productive. Topic focused conversation flow make things actually productive and it made us a lot more productive.
And Zulip now supports public mode , look at official rust community and zulip's chat.zulip.org . It drives collaboration.
Zulip is the actual game changer in innovation of the conversation flow and makes the team actually more productive. Topic focused conversation flow make things actually productive and it made us a lot more productive.
And Zulip now supports public mode , look at official rust community and zulip's chat.zulip.org . It drives collaboration.
I've been using RocketChat for a while and I like it, but there definitely room for improvement. So I just spent the last ten minutes looking up Zulip. I didn't find anything to suggest that there's much difference between this and other open source messaging projects. Google searches just turn up the usual blogspam.
What have I missed? Could you share a review or something that goes into the difference?
What have I missed? Could you share a review or something that goes into the difference?
- It is like combination of forums and Chat , every messages needs a topic
- Topic can be organized easily and smart
- Full markdown + Topic + Back referencing topics so you can use it creatively , a a chatroom + knowledgeable system.
- Well architect , well documented , all architecture decisions are documented , code is very readable and modifiable (i modified it to make it work like a realtime project management system and we ditched odoo , jira ) .
Here is what zulip with topics look like :
https://imgur.com/a/D0JINo1
Here is how we modified and patched it to become a realtime project management system.
https://imgur.com/a/9hM0gwy
https://imgur.com/a/LB2teYl
https://imgur.com/YOWDNg7
- Topic can be organized easily and smart
- Full markdown + Topic + Back referencing topics so you can use it creatively , a a chatroom + knowledgeable system.
- Well architect , well documented , all architecture decisions are documented , code is very readable and modifiable (i modified it to make it work like a realtime project management system and we ditched odoo , jira ) .
Here is what zulip with topics look like :
https://imgur.com/a/D0JINo1
Here is how we modified and patched it to become a realtime project management system.
https://imgur.com/a/9hM0gwy
https://imgur.com/a/LB2teYl
https://imgur.com/YOWDNg7
Ok that looks interesting, thanks for taking the time to share.
I actually think that interface would be contrary to my use case which is a chat system for mostly non-technical staff. The closer to what they're already familiar with the better and Rocketchat works great for that. I think Zulip would be confusing.
I'll file Zulip away in case I'm doing a more tech focused project in future.
I actually think that interface would be contrary to my use case which is a chat system for mostly non-technical staff. The closer to what they're already familiar with the better and Rocketchat works great for that. I think Zulip would be confusing.
I'll file Zulip away in case I'm doing a more tech focused project in future.
It's more tech focused, for no tech, matrix is fine
It's not for me.
I tried the official server.
It's nothing I can recommend.
Lots of porn and some open source channels and lots of coin crap.
I wanted then to use it to run my own for romance chat purposes, why reinvent the wheel. Well there's the official python server and the Go version isn't feature complete.
All I got out of the element client were a few nude pics and message streams that were completely uninteresting. Also there were so many pedophiles on there that I refused to be associated with them and deleted everything. I reported and blocked so many but it's no use.
No matrix for me.
I wanted then to use it to run my own for romance chat purposes, why reinvent the wheel. Well there's the official python server and the Go version isn't feature complete.
All I got out of the element client were a few nude pics and message streams that were completely uninteresting. Also there were so many pedophiles on there that I refused to be associated with them and deleted everything. I reported and blocked so many but it's no use.
No matrix for me.
It works wonderfully, it became a really nice hub of communication, information sharing with dedicated rooms for different stuff (CI/CD, link sharing, planing, etc.) and the service has no downtime I can remember in the past year.
Highly recommended and this funds indirectly the development of Matrix.
[0]: https://element.io/pricing