Conduit: Simple, fast and reliable chat server powered by Matrix(conduit.rs)
conduit.rs
Conduit: Simple, fast and reliable chat server powered by Matrix
https://conduit.rs/
192 comments
> The author also works on Veloren
That game is fucking cool. A couple years ago me and some friends compiled it for kicks and giggles to see what it was all about. To our surprise, the game ran silky smooth on my GTX 1050 Ti. We get into a lobby. We play for a half hour.
We're just exploring (the map is barebones but has cool landmarks) when I realize that you can scroll to zoom out from your character. In a psychadelic twist, you can just keep zooming out past normal ARPG levels and into a minimap-scale world, then above the clouds, all without dropping a frame.
I don't know how well-maintained the project is today, but it's got the bones for a badass RPG. One of these days I'll hop back on...
That game is fucking cool. A couple years ago me and some friends compiled it for kicks and giggles to see what it was all about. To our surprise, the game ran silky smooth on my GTX 1050 Ti. We get into a lobby. We play for a half hour.
We're just exploring (the map is barebones but has cool landmarks) when I realize that you can scroll to zoom out from your character. In a psychadelic twist, you can just keep zooming out past normal ARPG levels and into a minimap-scale world, then above the clouds, all without dropping a frame.
I don't know how well-maintained the project is today, but it's got the bones for a badass RPG. One of these days I'll hop back on...
The game is very actively developed and there are lots of devlogs
https://veloren.net/devblogs
If the last time you played was a few years ago, they've pushed out a huge amount of features since then. Very impressive for a fully open source game.
https://veloren.net/devblogs
If the last time you played was a few years ago, they've pushed out a huge amount of features since then. Very impressive for a fully open source game.
From Veloren's home page:
"Veloren is a multiplayer voxel RPG written in Rust. It is inspired by games such as Cube World, Legend of Zelda: Breath of the Wild, Dwarf Fortress and Minecraft."
I love how pointing out that it's written in Rust is more important that describing what the game is about or inspired by. Classic open source project unsure of who's the intended audience.
"Veloren is a multiplayer voxel RPG written in Rust. It is inspired by games such as Cube World, Legend of Zelda: Breath of the Wild, Dwarf Fortress and Minecraft."
I love how pointing out that it's written in Rust is more important that describing what the game is about or inspired by. Classic open source project unsure of who's the intended audience.
Seems like they know that the audience for an open source game is going to be FOSS nerds first, gamers second. Leading with Rust makes a lot of sense in the list of descriptions.
Founder & core dev here.
Our target audience is just as much potential contributors as it is actual players. Mentioning Rust is very deliberate: it pulls in a lot of motivated developers, both those trying to learn the language and those with expert knowledge looking for a creative, relaxed way to put their skills into practice.
Our target audience is just as much potential contributors as it is actual players. Mentioning Rust is very deliberate: it pulls in a lot of motivated developers, both those trying to learn the language and those with expert knowledge looking for a creative, relaxed way to put their skills into practice.
[deleted]
Why does there have to be an audience, or why can't it be other people interested in Rust?
The expectation is probably more for contributors to read that, not players.
It's still going strong! We just released 0.15. It's still in pre-alpha, but the map is much less sparse nowadays and there's a lot more to do!
> I don't know how well-maintained the project is today
Updates every Thursday! If you ever get on the main server, look for "varsderk" and I'll help you bootstrap fast. :)
Updates every Thursday! If you ever get on the main server, look for "varsderk" and I'll help you bootstrap fast. :)
I've been using Conduit for quite a while now and have found it to be very good.
For ages though it has been missing support for spaces, but support has just landed in the development builds and it is great. I've already updated my service and it has worked as expected.
Yeah seems like a good alternative to run the dentrite (go) server. That seems to be in development forever. At this point, the python server is taking too much resources, nice to see an alternative to go the server.
I wish there was a similar client that has full feature support but that's the problem with matrix, too many features, signal, discord, slack, zoom and teams all meshed into one thing. Would be nice if they had a secure chat only sub-protocol.
I've been running it for 10 months now. Very smooth experience (both installation and usage).
I'm the only user on my server and I've not joined any very active room, but so far its impact on my small VPS performance has been negligible.
I'm the only user on my server and I've not joined any very active room, but so far its impact on my small VPS performance has been negligible.
Hello, I'm Timo and I started the Conduit project a few years ago. Feel free to ask some questions.
Hi Timo!
I've been using Conduit for 10 months now and I love it. Thank you so much for it!
I've two questions:
- Is there any concern to have with regards to its future when you finish university? You seem to be by far the most active contributor and I'm worried the project is still dependent on how much time you can afford to put into it;
- What is the best way for a Rust / Linux developer to do a first impactful contribution to Conduit? With 155 open issues on GitLab at the moment and no problem really standing out for me as a user, I don't know where to start :p
Thanks!
BTW I hope you land a great job; I'd happily recommend you where I work, but we don't have any office near Dortmund unfortunately… Feel free to reach out to me if Dortmund / remote is not a requirement.
I've been using Conduit for 10 months now and I love it. Thank you so much for it!
I've two questions:
- Is there any concern to have with regards to its future when you finish university? You seem to be by far the most active contributor and I'm worried the project is still dependent on how much time you can afford to put into it;
- What is the best way for a Rust / Linux developer to do a first impactful contribution to Conduit? With 155 open issues on GitLab at the moment and no problem really standing out for me as a user, I don't know where to start :p
Thanks!
BTW I hope you land a great job; I'd happily recommend you where I work, but we don't have any office near Dortmund unfortunately… Feel free to reach out to me if Dortmund / remote is not a requirement.
Thank you for the kind words!
1: I can't say how much time I will have for Conduit, but I think the project is in a good shape and I think it can reach a stable release without me working full time on it, but of course it will take longer.
2: I think a good way to start is to hang around in the Conduit Matrix room and see if any issues pop up. Often these are relatively simple things like "these logs should have more details" and are a good way to get started.
I will also use this opportunity to link my LinkedIn profile: https://www.linkedin.com/in/timokoesters/
1: I can't say how much time I will have for Conduit, but I think the project is in a good shape and I think it can reach a stable release without me working full time on it, but of course it will take longer.
2: I think a good way to start is to hang around in the Conduit Matrix room and see if any issues pop up. Often these are relatively simple things like "these logs should have more details" and are a good way to get started.
I will also use this opportunity to link my LinkedIn profile: https://www.linkedin.com/in/timokoesters/
Thank you for your answer.
1: That's a relief :)
2: I've just joined `#conduit:fachschaften.org`; we'll see if I can help somehow.
1: That's a relief :)
2: I've just joined `#conduit:fachschaften.org`; we'll see if I can help somehow.
Thanks for checking in!
Any thoughts on matrix-p2p aka pinecone which is now being developed against dendrite? Any thoughts on "p2p-ifying" Conduit in the foreseeable future?
https://github.com/matrix-org/pinecone
https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...
Any thoughts on matrix-p2p aka pinecone which is now being developed against dendrite? Any thoughts on "p2p-ifying" Conduit in the foreseeable future?
https://github.com/matrix-org/pinecone
https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...
P2P sounds great and I'd love to implement it when it is ready. I think Conduit is pretty well suited for this. But it will still take quite some time until Matrix is ready for p2p clients, it needs some significant protocol changes: https://arewep2pyet.com/
What would you say is your biggest frustration with Matrix's design as a protocol? I have some of my own opinions writing bots and such but I'm curious about the perspective of a homeserver implementatiom maintainer.
I think the model of having all events form a giant graph is overengineered. They tried to cope with this by introducing things like "fast room joins", but I think they are flawed and treat the symptom rather than the cause of the problem. Servers should only replicate the very core part of a room and fetch remaining information on demand. But I'm working together with the Matrix team to improve this in the future.
I think most other things in the spec are necessary complexity. It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on, but they allow Matrix to have a lot of great features.
What problems did you encounter writing bots for Matrix?
I think most other things in the spec are necessary complexity. It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on, but they allow Matrix to have a lot of great features.
What problems did you encounter writing bots for Matrix?
The impression I got from using Ruma's bot SDK library was that bot clients needed to keep around a lot of state involved in syncing the room to handle new messages properly. Which largely lines up with what you said, although maybe it's possible I could have gotten away with a more lightweight solution since I wasn't making a stanalone client?
> It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on
Another impression I got was this was kind of an excessive amount of duplication (and other duplications) that could have been avoided had a bit more forethought been put into the protocol design, especially with how these features interact with the e2ee.
> It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on
Another impression I got was this was kind of an excessive amount of duplication (and other duplications) that could have been avoided had a bit more forethought been put into the protocol design, especially with how these features interact with the e2ee.
Hi Timo, is there a document somewhere that describes how Conduit compares feature-wise to Synapse or to the Matrix spec? It’s not clear to me if the goal to develop a fully-featured matrix server, or if there is some subset of scale or functionality that you’re aiming for; could you comment on that?
Hi, the goal is to create a fully-featured server that works seamlessly with all Matrix clients. The one notable exception is that we will not implement support for "outdated" room versions, which means that there are some rooms that are unjoinable because they are too old, those should be upgraded to a more recent room version.
I'm also prioritizing features needed for smaller instances, instead of things like user management or horizontal scaling.
I'm also prioritizing features needed for smaller instances, instead of things like user management or horizontal scaling.
Do you use Conduit daily yourself? I'm wondering if it's stable for daily use.
Yes, I use my Conduit instance for all my development work and also host a big Discord bridge on it (for https://veloren.net, which was mentioned in another comment).
Very nice!
Sounds like AppService/bridge support is on par with Synapse at this point (and maybe has been for quite a while?) - any gaps to be aware of in that department?
Sounds like AppService/bridge support is on par with Synapse at this point (and maybe has been for quite a while?) - any gaps to be aware of in that department?
Most bridges should just work, some require messing around a bit, also see https://news.ycombinator.com/item?id=36939480, I haven't debugged this yet.
You can find some bridge documentation here: https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.m...
You can find some bridge documentation here: https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.m...
I've used Conduit for about a year now with bridges and it works flawlessly. It doesn't have all features but a recent release added Spaces and end-to-bridge encryption (not as big of a deal when selfhosting server + bridges, but great nonetheless), so I'm not even sure what is still missing.
Timo,
Thank you and kudos for all of your hard work on this. I will definitely be checking your project out. :)
-sydbarrett74
Thank you and kudos for all of your hard work on this. I will definitely be checking your project out. :)
-sydbarrett74
Is there a migration path for Synapse users?
No, currently you have to start a completely new server. At some point after reaching a stable Conduit release we will hopefully be able to create migration paths.
One thing I didn't like about Matrix: I had a single server with 3 or 4 other users. In a few months, the database ballooned to, like, 80GB. User-uploaded content, including text, was in the ballpark of 2 or 3GB. Is there any way to clear out the cache of data received from old servers, say, anything more than 2 weeks old, and re-retrieve it if needed?
Yeah, there are admin APIs that can clear old images, local and remote ones. For your specific scenario you probably want this one:
https://matrix-org.github.io/synapse/v1.85/admin_api/media_a...
My server is not federated but fairly active, and we treat it as ephemeral. We've configured it so anything older than a week or two gets reclaimed automatically, text and media.
https://matrix-org.github.io/synapse/v1.85/admin_api/media_a...
My server is not federated but fairly active, and we treat it as ephemeral. We've configured it so anything older than a week or two gets reclaimed automatically, text and media.
Are you using synapse?
Yes, it's room/concersation states taking up all the space, and you can compress them.
https://levans.fr/shrink-synapse-database.html
https://github.com/matrix-org/rust-synapse-compress-state
https://levans.fr/shrink-synapse-database.html
https://github.com/matrix-org/rust-synapse-compress-state
That it generates that much cruft for something so simple is disappointing. How long does the compression bandaid work for?
From the first link:
>I shrunk my homeserver database from 100GB to a little under 8GB, during a long maintenance cleanup.
I run the compressor on a cron job. I've been running for 5 years with ~ a dozen people on my server, all federated, in multiple large rooms, didn't run into space issues until this year. On Linode $10 and then Hetzner 4 CPU.
One thing to watch out for: disable registration. Otherwise spambots will register accounts, join the largest matrix.org rooms to spam, and then you'll have to store all that crap for all those rooms.
>I shrunk my homeserver database from 100GB to a little under 8GB, during a long maintenance cleanup.
I run the compressor on a cron job. I've been running for 5 years with ~ a dozen people on my server, all federated, in multiple large rooms, didn't run into space issues until this year. On Linode $10 and then Hetzner 4 CPU.
One thing to watch out for: disable registration. Otherwise spambots will register accounts, join the largest matrix.org rooms to spam, and then you'll have to store all that crap for all those rooms.
I feel registration is something which should come disabled by default and need to be explicitly enabled.
It may be. I setup my server half a decade ago and don't remember exactly how I configured it initially. I may have enabled it not realizing the implications.
At least on Conduit and Dendrite that is the case iirc, but it's easy to forget to disable it once you register an account.
This is one of those things that make me appreciate XMPP. There’s no expectation to duplicate the entire history of chatrooms. Many MUCs default to the last 20 messages, which is usually enough to let you catch & jump in on the conversation. Costs of running my server have been quite cheap.
Is there a way to migrate from Synapse to this? I don't know if I can justify destroying 6 years of conversation history.
Not yet. There're plans to build migration tool for Synapse to Dendrite, but support for Conduit would need to be built in as well.
Either way, it's unknown how long it'll take.
The tracking issue for Synapse -> Dendrite migration is all I've found. https://github.com/matrix-org/dendrite/issues/1705
Either way, it's unknown how long it'll take.
The tracking issue for Synapse -> Dendrite migration is all I've found. https://github.com/matrix-org/dendrite/issues/1705
Related:
Conduit Beta – Matrix chat server - https://news.ycombinator.com/item?id=28385840 - Sept 2021 (69 comments)
Conduit Beta – Matrix chat server - https://news.ycombinator.com/item?id=28385840 - Sept 2021 (69 comments)
Can someone please explain, why use Matrix while there's XMPP ?
My first thought was: „my question would be the reverse“.
I have no idea why I’d use XMPP, so I will tell you what I like about Matrix.
- modern chat solution with features people have come to expect from Slack and Discord
- many bridges that have kept me from having to use more than one chat client for multiple protocols (think pidgin)
- lots of great communities are on matrix
- pretty good voice chat
- open source
- selfhosted
Those are my main reasons why I like Matrix. My question to you would be: what do you like about XMPP?
- modern chat solution with features people have come to expect from Slack and Discord
- many bridges that have kept me from having to use more than one chat client for multiple protocols (think pidgin)
- lots of great communities are on matrix
- pretty good voice chat
- open source
- selfhosted
Those are my main reasons why I like Matrix. My question to you would be: what do you like about XMPP?
XMPP is well-defined open source selfhosted easily extendable federated standard for exchanging data containers (messages) in a sequential manner. I have zero experience with Matrix, but have experience developing Jabber clients (both mobile and desktop), developing XMPP server, services and VoIP gateways back in mid 2000th. I can say that XMPP with it's all-covering XEPs can satisfy needs of anyone today. Why would people need something else like Matrix ? I'm trying to understand what motivated Matrix development. Can Matrix provide anything that is completely missing in XMPP beside bad PR ?
XMPP gained bad publicity as overcomplicated XML based protocol which was abandoned by Google in favour of their proprietary solution somethere in 2011. Till then it had been worshipped as one of the best open standard ever developed.
XMPP gained bad publicity as overcomplicated XML based protocol which was abandoned by Google in favour of their proprietary solution somethere in 2011. Till then it had been worshipped as one of the best open standard ever developed.
Matrix has well maintained clients and the overall experience is smooth especially for non technical people.
Source: I use XMPP and Matrix daily.
Source: I use XMPP and Matrix daily.
What XMPP client(s) are you using that are not well maintained? And why?
Dino and Gajim both crash frequently on Wayland (Sway in particular) due to GTK issues that I'm not expecting to be fixed any time soon. Gajim also gets very slow the longer it's open, can't recall if Dino was the same. Dino also has the usual GNOME-y issues of being over-simplified and lacking in customization and features. When I changed from Dino to Gajim I was shocked at all the stuff I could suddenly do, was weird to think both were XMPP clients.
Something with Gajim's features but using Qt would be pretty great potentially. GTK stuff also often has this horrible thing where it fades the window when unfocused, which gets really awful and unresponsive when things get laggy, also ruins screenshots. Never figured out how to turn it off. Part of the theme apparently, but GNOME also doesn't want you customizing/changing your theme. I'm just using Adwaita-dark usually.
Matrix clients aren't great either, but overall Nheko gives me less trouble and pain than Gajim, using both daily. irssi (IRC client) is kind of my gold standard for stability/performance/features with weechat being mostly okay too.
Something with Gajim's features but using Qt would be pretty great potentially. GTK stuff also often has this horrible thing where it fades the window when unfocused, which gets really awful and unresponsive when things get laggy, also ruins screenshots. Never figured out how to turn it off. Part of the theme apparently, but GNOME also doesn't want you customizing/changing your theme. I'm just using Adwaita-dark usually.
Matrix clients aren't great either, but overall Nheko gives me less trouble and pain than Gajim, using both daily. irssi (IRC client) is kind of my gold standard for stability/performance/features with weechat being mostly okay too.
If you're an irssi/weechat person, I use poezio as my primary client (and profanity is another console client, but I've never tried it). Obviously console clients lack some features (calls, avatars [usable ones, anyway]) but it does the job for me. I do use a Conversations fork on my mobile for communicating with family while I'm out and about, as it's nice to have calls and such then.
Pidgin?
Dino.im crashes too frequently for my tastes. It also doesn't have an official Windows version. Gajim looks outdated and the update procedure broke several times (I know the authors are working hard to modernize it though).
iOS story is sad. Family used Snikket (thanks for your work on it) but it still dropped notifications even after following with issues and Prosody modules needed. (Monal seems to be okayish now).
Even Conversations.im seems stuck. I know everyone has their favorite missing feature but for me no reactions is the biggest.
iOS story is sad. Family used Snikket (thanks for your work on it) but it still dropped notifications even after following with issues and Prosody modules needed. (Monal seems to be okayish now).
Even Conversations.im seems stuck. I know everyone has their favorite missing feature but for me no reactions is the biggest.
I used to use Pidgin and as for the why: I had used Pidgin for many years to AIM, MSN, etc.
Yeah, Pidgin has fallen behind significantly with regards to modern XMPP compliance. The developers are still working on Pidgin actively, but the focus is on a big rewrite of the foundations right now (3.0) so they can more easily support modern IM features.
I wish them luck, but considering their lack of manpower, by the time 3.0 comes out for "modern IM features", we'll probably have telepathic computers.
I was there when they had the famous video-voice branch.
Heck, I just checked: https://developer.pidgin.im/wiki/vvAPI?version=1
It was 15 (!) years ago :-)
I was there when they had the famous video-voice branch.
Heck, I just checked: https://developer.pidgin.im/wiki/vvAPI?version=1
It was 15 (!) years ago :-)
https://matrix.org/docs/legacy/faq/ there are some answers to "why not xmpp"
> „my question would be the reverse“. I have no idea why I’d use XMPP
> My question to you would be: what do you like about XMPP?
Same things & more:
- modern chat solution with features people have com to expect from WhatsApp
- many bridges that have kept me from having to use more than one chat client for multiple protocols (think pidgin)
- many great messengers have discovered XMPP as a great base for their system
- lots of great communities are on XMPP
- realistic participant counts in public chat rooms - no counting dead (former) members
- pretty good video & voice chat
- open source
- selfhosting possible
- fewer concerns about data protection and privacy
- more resource efficient (less memory required, lower CPU utilization)
And:
- The use is possible and allowed everywhere where e-mail is in use.
> My question to you would be: what do you like about XMPP?
Same things & more:
- modern chat solution with features people have com to expect from WhatsApp
- many bridges that have kept me from having to use more than one chat client for multiple protocols (think pidgin)
- many great messengers have discovered XMPP as a great base for their system
- lots of great communities are on XMPP
- realistic participant counts in public chat rooms - no counting dead (former) members
- pretty good video & voice chat
- open source
- selfhosting possible
- fewer concerns about data protection and privacy
- more resource efficient (less memory required, lower CPU utilization)
And:
- The use is possible and allowed everywhere where e-mail is in use.
What are your favorite clients? My issue with XMPP is that many clients lack modern conveniences, and it's not easy to get people on board for that reason.
Which modern conveniences do you find are lacking, out of curiosity?
- modern, clean and pretty UI
- simple encryption support. should be able to set it up with a couple clicks and don't have to worry about it
- seamless synchronization between devices
- quick push notifications that don't require me to have something cluttering up my notification bar forever
these are just some of the points I could think about at the top of my head. the majority of clients have one or a couple of them, but there's no client to my knowledge which has all of them.
I have yet to find one that doesn't have awkward push notifications. like come on, do you really think I want an ugly notification turned on at all times watching for messages?
edit: formatting
- simple encryption support. should be able to set it up with a couple clicks and don't have to worry about it
- seamless synchronization between devices
- quick push notifications that don't require me to have something cluttering up my notification bar forever
these are just some of the points I could think about at the top of my head. the majority of clients have one or a couple of them, but there's no client to my knowledge which has all of them.
I have yet to find one that doesn't have awkward push notifications. like come on, do you really think I want an ugly notification turned on at all times watching for messages?
edit: formatting
> what do you like about XMPP?
- plenty of fast native clients
- server resource usage
- simplicity of the protocol, especially the encryption
- plenty of fast native clients
- server resource usage
- simplicity of the protocol, especially the encryption
> plenty of fast native clients
And God help you making all of them talk to each other properly...
And God help you making all of them talk to each other properly...
I have used conversations (and derivatives), gajim, dino, converse.js, and movim to have omemo encrypted xmpp conversations; and I talk to people on Siskin and have used profanity in the past. Seems to work properly, unless I'm missing something.
Before XEP-0459, every client implement their own subset of standard and seldom talks with clients that implement a differnt subset.
Now try to make a voice and/or video call.
Does any Matrix client support voice/video calls other than Element (including Hydrogen as it shares Element Web's codebase)?
Fluffychat supports it too. Check out https://matrix.org/ecosystem/clients/, you can click the clients for a feature list.
> - simplicity of the protocol, especially the encryption
only simple for developers though - due to the lack of Cross Signing it is very difficult to keep communication secure.
only simple for developers though - due to the lack of Cross Signing it is very difficult to keep communication secure.
What is cross siging in the messaging context?
implicitly verifying all (including future) of somebody's devices although running through the verification process only once.
Without it, e.g. if you log into a new session, you have to verify with all your contacts before you can safely use that session for communication
Without it, e.g. if you log into a new session, you have to verify with all your contacts before you can safely use that session for communication
What is a good way to discover great communities on Matrix?
My 2c might not crush the scale, but FWIW I'd expect XMPP clients to be easier to work with if I had existing PGP keyrings that I wanted to re-use, favoring consistant identities and protocols over more stringent avoidance of key re-use. Could be a key on a smartcard, or the key your employer kept a revocation certificate for.
Conversations has great support for OpenKeychain on Android, and I'd love to see that come to competing protocol Deltachat but the devs are focusing on cross-platform behaviors atm. Android-specific fork Deltalabs might be willing to be upstream for it if anyone knows where to start with that.
Conversations has great support for OpenKeychain on Android, and I'd love to see that come to competing protocol Deltachat but the devs are focusing on cross-platform behaviors atm. Android-specific fork Deltalabs might be willing to be upstream for it if anyone knows where to start with that.
xmpp did most of that first before it fell off :(
Matrix is like chatting via GIT (distributed databases) and tends to be a team messenger like Mattermost or Zulip - XMPP is structurally like email (but with options like online status, currently typing, last online, ...) and is often used by large messenger services (e.g. WhatsApp uses its own variant of XMPP).
XMPP is the only system that can and may(!) be used wherever email is in use.
XMPP is just as "modern" as Matrix, but has a _different _ data storage/distribution idea.
Comparison: https://www.freie-messenger.de/en/systemvergleich/xmpp-matri...
XMPP is the only system that can and may(!) be used wherever email is in use.
XMPP is just as "modern" as Matrix, but has a _different _ data storage/distribution idea.
Comparison: https://www.freie-messenger.de/en/systemvergleich/xmpp-matri...
Thanks!
Because summaries like this still stand up as of today:
https://news.ycombinator.com/item?id=8998290
> XMPP is great for what it was designed for. It doesn't work well with mobile, high packet loss & high latency connections. XMPP is talkative and bandwidth intensive - bad for limited data/battery applications. It also wasn't designed for today's 1 person multiple devices reality. Most XMPP servers let you log in multiple times but messages don't sync between clients and sometimes get delivered to the client the user isnt currently in front of.
> Also, sending files over XMPP has pretty much always sucked - there are a bunch of incompatible ways to do it and it's always been hit and miss depending on which client your chat partner was using, network topography, etc.
Also, overload of XEPs doesn't help the ecosystem. Too many optional extensions hinders interop. People expect more features in modern chat experiences than what XMPP was designed for, and that's what XEPs have tried to fix as a bandaid, with mixed results.
On top of that, the technology choices are par of the course for the time it was designed, and nowadays there are arguably better things. Devs are naturally driven to choose tech that makes their work nicer, if they enjoy it, so that means more stuff gets done for the newer platform, in this case. As an example, coincidentally, another HN post today was touching on one of those points - the need for a very advanced XML parser, as a typical one apparently wouldn't be enough:
https://news.ycombinator.com/item?id=36930196
https://news.ycombinator.com/item?id=8998290
> XMPP is great for what it was designed for. It doesn't work well with mobile, high packet loss & high latency connections. XMPP is talkative and bandwidth intensive - bad for limited data/battery applications. It also wasn't designed for today's 1 person multiple devices reality. Most XMPP servers let you log in multiple times but messages don't sync between clients and sometimes get delivered to the client the user isnt currently in front of.
> Also, sending files over XMPP has pretty much always sucked - there are a bunch of incompatible ways to do it and it's always been hit and miss depending on which client your chat partner was using, network topography, etc.
Also, overload of XEPs doesn't help the ecosystem. Too many optional extensions hinders interop. People expect more features in modern chat experiences than what XMPP was designed for, and that's what XEPs have tried to fix as a bandaid, with mixed results.
On top of that, the technology choices are par of the course for the time it was designed, and nowadays there are arguably better things. Devs are naturally driven to choose tech that makes their work nicer, if they enjoy it, so that means more stuff gets done for the newer platform, in this case. As an example, coincidentally, another HN post today was touching on one of those points - the need for a very advanced XML parser, as a typical one apparently wouldn't be enough:
https://news.ycombinator.com/item?id=36930196
> It doesn't work well with mobile, high packet loss & high latency connections.
This is an absolutely false, baseless statement, mostly amounting to FUD. Messages work well on mobile, and they sync between devices just fine.
> Also, overload of XEPs doesn't help the ecosystem.
On the contrary, XEPs create the ecosystem. As I often say, Matrix is not a protocol, it's a product with an API created by a single organization.
This is an absolutely false, baseless statement, mostly amounting to FUD. Messages work well on mobile, and they sync between devices just fine.
> Also, overload of XEPs doesn't help the ecosystem.
On the contrary, XEPs create the ecosystem. As I often say, Matrix is not a protocol, it's a product with an API created by a single organization.
I worked briefly on a mobile XMPP chat solution a few years ago, and considering this was when 3G was the best you could get and the application had to deal with some pretty bad connections, I don't remember XMPP having any intrinsic limitations like that.
There's the least common denominator XMPP, with a lot of key functions under optional XEPs. Thus the user experience is very uneven across clients and servers.
Matrix has a more defined set of important features, so you could expect that conforming clients all implement them uniformly, without surprises.
Matrix has a more defined set of important features, so you could expect that conforming clients all implement them uniformly, without surprises.
This argument seems so weird to me because the matrix ecosystem definitely does have complete and non-complete clients. Just like the XMPP ecosystem. And as for servers... Dendrite and Conduit are not 100% compatible with Synapse.
I imagine there must be some good clients for XMPP. Hell, I use one good client (Conversations on Android) on a daily basis. Also have used Gajim quite a bit. It is alright afaict.
I imagine there must be some good clients for XMPP. Hell, I use one good client (Conversations on Android) on a daily basis. Also have used Gajim quite a bit. It is alright afaict.
What does complete even mean regarding XMPP?
It's not even possible there, because you have conflicting proposals while on Matrix you have a coherent specification
It's not even possible there, because you have conflicting proposals while on Matrix you have a coherent specification
Compliance with the annual compliance suites would be one definition. This compliance level is discoverable in the xmpp.org software listing, for example: https://xmpp.org/software/conversations/
Funny, I recently got pretty frustrated looking for a decent Matrix client. Not even Element claimed to support the full list of features on the Matrix website. And Element has super bizarre behavior like not allowing to paste into the message composer. And good luck getting help when a client doesn't work.
That said, I can't claim XMPP clients are any better.
That said, I can't claim XMPP clients are any better.
Element is basically 3 different clients - web, ios and android are different codebases. Paste to composer should work on all of them tho! Meanwhile on mobile there is a new client called Element X which is a single codebase built on matrix-rust-sdk: https://element.io/blog/element-x-experience-the-future-of-e....
Classic Element should support every specced feature in Matrix tho, and tonnes of MSCs, so unsure what features you’d be missing. Meanwhile Element X is less featureful, but way more performant and stable (we’re aiming for better-than-telegram UX and perf).
Classic Element should support every specced feature in Matrix tho, and tonnes of MSCs, so unsure what features you’d be missing. Meanwhile Element X is less featureful, but way more performant and stable (we’re aiming for better-than-telegram UX and perf).
Thanks for the reply. I saw your demo of Element X a while back and it looked awesome. I'm excited for it to show up for desktop use.
Of course you are already familiar with https://matrix.org/ecosystem/clients/element/. I know it is pretty ticky to point out that "Multi Account" is not supported, but it happened to be a feature I was particularly looking for in my search. My IRC client, for instance, lets me be logged into multiple servers with different accounts at the same time. Yes, I know that a single account on one server can communicate across all federated servers. The same is true for email, yet my email client allows me to use multiple accounts. I'm heartened to see that you have included the feature on your checklist. I hope that means somebody is thinking about it.
I know that Element should allow me to paste into the composer. I was told exactly that in the matrix room when I asked. "Works for me" is as frustrating a response as ever. I've seen the issue reported a number of times by different people with pretty decent detail, but I haven't seen a solution. Just "works for me" responses.
I'm still a Matrix user. I just accept that I don't have everything smoothed out the way I'd like. My post above was just a response to the claim that XMPP clients don't have uniform features. Well, as you know, neither do Matrix clients. But you weren't the one making that argument.
Don't take my posts as negative criticism, even if there is some criticism there. Keep up the great work. Keep getting better.
Of course you are already familiar with https://matrix.org/ecosystem/clients/element/. I know it is pretty ticky to point out that "Multi Account" is not supported, but it happened to be a feature I was particularly looking for in my search. My IRC client, for instance, lets me be logged into multiple servers with different accounts at the same time. Yes, I know that a single account on one server can communicate across all federated servers. The same is true for email, yet my email client allows me to use multiple accounts. I'm heartened to see that you have included the feature on your checklist. I hope that means somebody is thinking about it.
I know that Element should allow me to paste into the composer. I was told exactly that in the matrix room when I asked. "Works for me" is as frustrating a response as ever. I've seen the issue reported a number of times by different people with pretty decent detail, but I haven't seen a solution. Just "works for me" responses.
I'm still a Matrix user. I just accept that I don't have everything smoothed out the way I'd like. My post above was just a response to the claim that XMPP clients don't have uniform features. Well, as you know, neither do Matrix clients. But you weren't the one making that argument.
Don't take my posts as negative criticism, even if there is some criticism there. Keep up the great work. Keep getting better.
FluffyChat does have multi-account support, but it's also a feature I'm missing on Element.
> we’re aiming for better-than-telegram UX and perf)
Oh thank god - my (admittedly not-brand-new) phone doesn't have quite enough RAM to keep Element fed and happy. 300 meg doesn't sound like much till all apps are limited to the ~2GB left over after the OS takes it's cut.
Element supports stickers though, and I haven't found any other Android clients that support stickers while also being lighter.
Kudos though - Matrix has come a long, long way since I first played around with riot.im!
Oh thank god - my (admittedly not-brand-new) phone doesn't have quite enough RAM to keep Element fed and happy. 300 meg doesn't sound like much till all apps are limited to the ~2GB left over after the OS takes it's cut.
Element supports stickers though, and I haven't found any other Android clients that support stickers while also being lighter.
Kudos though - Matrix has come a long, long way since I first played around with riot.im!
Do you plan to do something like Element X but for desktop?
> Element has super bizarre behavior like not allowing to paste into the message composer
It requires the clipboard API. Puzzling decision, given that native pasting worked before, but here we are.
It requires the clipboard API. Puzzling decision, given that native pasting worked before, but here we are.
I paste into Element all the time, on web, desktop, and Android
In practice, it only works better if you stick to element so it is pretty much the same. The difference being that they ship a full featured web version so anyone with an OS that support modern web should be able to support it.
Matrix is more like a state synchronization service than a way to send messages. If I join a room on another Matrix server, my server will begin maintaining a copy of that other sever for me to use how I like. If I shut my server down for a day, it will sync back up when it comes back.
I’m not sure if XMPP works like that, but I always thought it was more like email: send a message, maybe retry a bit, but that’s about it. Not sure how transient things like presence, read receipts, and typing notifications work either, across servers.
I’m not sure if XMPP works like that, but I always thought it was more like email: send a message, maybe retry a bit, but that’s about it. Not sure how transient things like presence, read receipts, and typing notifications work either, across servers.
Isn't xmpp old style instant messaging? As in, if you miss a message because you had poor connection or the application wasn't running then it's gone?
Matrix does not work this way.
Matrix does not work this way.
XMPP supports delayed delivery. It works although I have had minor issues with it, especially if OMEMO is enabled.
https://xmpp.org/extensions/xep-0203.html
https://xmpp.org/extensions/xep-0203.html
I think it's mostly through server side archives that chat history is kept in sync between devices nowadays
https://xmpp.org/extensions/xep-0313.html
https://xmpp.org/extensions/xep-0313.html
> Isn't xmpp old style instant messaging?
No.
XMPP is just as "modern" as Matrix, but has a _different _ data storage/distribution idea.
see: https://news.ycombinator.com/item?id=36939676
No.
XMPP is just as "modern" as Matrix, but has a _different _ data storage/distribution idea.
see: https://news.ycombinator.com/item?id=36939676
That was true 20 years ago. For the past 10+ years XMPP has had Stream Resumption that allows you to resume a few stanzas you missed recently (typically with a poor connection), and Message Archive Management that stores everything on the server that you can then retrieve on the client.
XMPP has had little place on the public stage, but that doesn't mean it stopped evolving.
XMPP has had little place on the public stage, but that doesn't mean it stopped evolving.
> and Message Archive Management that stores everything on the server that you can then retrieve on the client.
if and for how long will be decided by the person who is running the server the chat room was created on
if and for how long will be decided by the person who is running the server the chat room was created on
Preference, I guess. It appeals to the masses who are growing up on discord and slack.
I also prefer XMPP.
I also prefer XMPP.
Network effect? I use matrix today. What does xmpp have that I should switch for?
XMPP by its extensible nature can be a social network (Movim), a community organizer (Libervia), or can be used for basic presence, etc. & these can sit atop your XMPP server (Prosody, ejabberd, etc.). Matrix, without extensibility, is kinda relegated to chat (text, voice, video) only. The push-based servers make clients efficient, and both Prosody & ejabberd can be UnifiedPush server with a basically a boolean flip in the config—interestingly can be a push server for Element & other Matrix clients instead of relying on Google.
Like the other commenter said, Matrix is very extensible, as you can just send custom events as you wish. There's also lots of emerging non-IM platforms built on top of Matrix, like collaborative whiteboards, virtual rooms, embeddable comments, etc.
With the new protocol-level performance MSCs coming around the corner, Matrix is becoming ever more appealing for all sorts of applications.
With the new protocol-level performance MSCs coming around the corner, Matrix is becoming ever more appealing for all sorts of applications.
Matrix is very extensible. You can start sending your own yc.toastal.test.first event type and put any json as value
You can run a functional server for multiple people on a very low-power device.
JMP.chat
Speaking as a user of both element generally and Cheogram/JMP.chat.
I still use both.
Speaking as a user of both element generally and Cheogram/JMP.chat.
I still use both.
For me it's about federation. I have my own server and chat with my family there. And I also have friends with accounts elsewhere and I can message them as well.
And I'm looking forward to integrations (Slack, Signal, ...) being more user-friendly, and easier to install, configure and maintain, so I can message others, too.
And I'm looking forward to integrations (Slack, Signal, ...) being more user-friendly, and easier to install, configure and maintain, so I can message others, too.
XMPP is federated and has some integrations (among them, SMS/MMS and phone call support).
Conduit is a very cool project, but unfortunately it seems difficult to follow the status and progress short of reading all commits and issues.
I'm excited for the recent progress on the built-in Sliding Sync feature because it's much easier to deploy.
I'm excited for the recent progress on the built-in Sliding Sync feature because it's much easier to deploy.
On the topic of Matrix, does anyone know what causes messages to sometimes decrypt the last message until a new last message is sent (and fails to decrypt), or a single message to fail to decrypt while surrounding ones work successfully?
My understanding is still imperfect, but I'll try to provide some info:
Not all messages are encrypted with the same key, so if all of your clients are not connected at the same time, and the same is true for the sender, they can't exchange their keys. When that happens, each client can only decrypt the subset of the messages for which it has the keys. Also note that clients only exchange their keys with other verified clients.
If you look at the “session_id” attribute of the JSON source of the messages, you'll see that for a given session (ie. when the sender is logged in a client), all the messages are decrypted (which means you have the key for that session) or none of them are (which means you haven't received the key for that session yet).
Not all messages are encrypted with the same key, so if all of your clients are not connected at the same time, and the same is true for the sender, they can't exchange their keys. When that happens, each client can only decrypt the subset of the messages for which it has the keys. Also note that clients only exchange their keys with other verified clients.
If you look at the “session_id” attribute of the JSON source of the messages, you'll see that for a given session (ie. when the sender is logged in a client), all the messages are decrypted (which means you have the key for that session) or none of them are (which means you haven't received the key for that session yet).
I might have missed something, but the page is very simplistic and assumes you know what Matrix is and how to use this; a lot of time is spent on the installation through different means, but none how to use the server itself, either by use of a client?
The first link on the page is to matrix.org. matrix.org links to clients: https://matrix.org/ecosystem/clients/
You probably would want element.
I think conduit's page is doing the right thing. It doesn't really assume you know what matrix is, but rather assumes you're smart enough to click on a link if you don't know.
You probably would want element.
I think conduit's page is doing the right thing. It doesn't really assume you know what matrix is, but rather assumes you're smart enough to click on a link if you don't know.
I agree with the grandparent -- while trying to determine what this was, I looked at other links to try and find the answer and went down the wrong path.
> Users from every Matrix homeserver can chat with users from all other Matrix servers.
This statement lead me to assumed the "matrix specification" discussed was about server-to-server communication... I'm not interested in digging into the underpinnings of this server-to-server communication (right now) just like I'm not terribly interested in how blockchains keep in sync across nodes... But I am interested in how this whole stack works, and I was lost with this page as the starting point.
So I think it's safe to add an extra sentence to explain the relationship while still keeping the page simplistic and focused.
> Users from every Matrix homeserver can chat with users from all other Matrix servers.
This statement lead me to assumed the "matrix specification" discussed was about server-to-server communication... I'm not interested in digging into the underpinnings of this server-to-server communication (right now) just like I'm not terribly interested in how blockchains keep in sync across nodes... But I am interested in how this whole stack works, and I was lost with this page as the starting point.
So I think it's safe to add an extra sentence to explain the relationship while still keeping the page simplistic and focused.
Hard disagree. One of the worst landing pages I've ever seen. What exactly is it? Just a backend? Client? Don't waste my whole screen with the logo and a wannabe catchy phrase. Just tell me the gist
The landing page is pretty good if you are familiar with Matrix.org, and I'm assuming that it's aimed at Matrix developers. Personally I appreciated the brevity, simple declaration of the problem it's trying to solve, and a quick link to the real call to action (the Git repo).
EDIT: realizing that the landing page may have been updated with new content itself since your original post.
EDIT: realizing that the landing page may have been updated with new content itself since your original post.
Was the link changed?
What is Matrix?
Matrix is an open network for secure and decentralized communication. Users from every Matrix homeserver can chat with users from all other Matrix servers. You can even use bridges to communicate with users outside of Matrix, like a community on Discord.
And I see no installation information.
What is Matrix?
Matrix is an open network for secure and decentralized communication. Users from every Matrix homeserver can chat with users from all other Matrix servers. You can even use bridges to communicate with users outside of Matrix, like a community on Discord.
And I see no installation information.
I don't know about the previous link, but conduit.rs has a Link called "Documentation" at the top of the page.
Installation is downloading a binary, setting up autostart and writing/copying a 10 line configuration.toml.
Installation is downloading a binary, setting up autostart and writing/copying a 10 line configuration.toml.
You're not understanding. The parent commenter said that the link was showing lots of installation options, but the link does not show that. I know there are installation instructions elsewhere, but I was just responding to what the parent was claiming about this link.
Oh right. Thank you, that went over my head.
> ...assumes you know what Matrix is ...
Matrix is a chat protocol. It works like chatting over GIT (distributed databases) and is more like a team messenger like Mattermost or Zulip. Conduit is a server software and not for end users.
More information about Matrix: https://www.freie-messenger.de/en/matrix
Matrix is a chat protocol. It works like chatting over GIT (distributed databases) and is more like a team messenger like Mattermost or Zulip. Conduit is a server software and not for end users.
More information about Matrix: https://www.freie-messenger.de/en/matrix
> and is more like a team messenger like Mattermost or Zulip.
if at all, Element is this.
Matrix doesn't really care about what type of users the clients target
if at all, Element is this.
Matrix doesn't really care about what type of users the clients target
And that is my point. While I use Matrix, it is confusing by itself as you need the client, which was hosted as riot.im, now element, etc. For a newcomer this page is just as confusing whle it could be a great entry as it being so lightweight compared to the actual Matrix server. Some additional notes will help a lot.
I also lost contact with a Matrix user during the riot.im -> element.io switch, so I empathize. But I think the flexibility and interoperability of Matrix is worth the additional complexity. Allowing different clients can be a major boon to accessibility, as blind or sight impaired users can use their own specialized client. Not to mention adapting to device form factor. Traditional workstation, tablet, phone all have different needs.
How does this relate to Synapse? Dendrite tests against https://github.com/matrix-org/sytest and has issues for “are we synapse yet” — I can’t see any discussion of this for Conduit (not even a discussion on why they don’t want to be like Synapse).
Conduit is a 3rd party implementation of the matrix server spec in Rust. Synapse and Dendrite are both first party where Dendrite was originally intended to replace Synapse.
The selling features are lightweight and simple to setup, implying that Synapse is not. It is more importantly a validation of the matrix server specs and over the years they have done quite a bit to get ambiguities clarified.
The selling features are lightweight and simple to setup, implying that Synapse is not. It is more importantly a validation of the matrix server specs and over the years they have done quite a bit to get ambiguities clarified.
Originally intended? So dendrite is not slated to replace synapse anymore? I know the 'eventually' has become a bit of a running joke but I thought this was still the plan.
It's a shame there's no upgrade path though. With retention of history.
It's a shame there's no upgrade path though. With retention of history.
It seems like there're so many important deployments of Synapse that they need to keep it going. And I've read that the performance is way better than a few years ago.
At some point Dendrite was slated to support micro services on different machines to be able to scale up, but now they only support monolith deployments. It's aimed at "small" deployments and is used in their P2P efforts.
At some point Dendrite was slated to support micro services on different machines to be able to scale up, but now they only support monolith deployments. It's aimed at "small" deployments and is used in their P2P efforts.
Looks like SyTest is primarily oriented towards use with Synapse, and the dendrite folks are wrapping it up for their own CI integration. Perhaps Conduit could reuse some of their work, although IIRC Conduit is using GitLab and Dendrite is using GitHub Actions.
Separately, it seems that Conduit is not orienting itself as a drop in replacement for Synapse. At least at the current moment. There are a number of notable feature gaps that I recall being mentioned last time I was in the Matrix room.
Separately, it seems that Conduit is not orienting itself as a drop in replacement for Synapse. At least at the current moment. There are a number of notable feature gaps that I recall being mentioned last time I was in the Matrix room.
Sytest is designed to test any Matrix server. The only reason it’s called Sytest is because that Matrix was briefly originally called Synapse (before we came up with the much better name Matrix, and chose to keep Synapse around for the first implementation).
I use Conduit with Element clients and from time to time I will have problems decrypting messages. Sometimed they'll stay unencrypted for a week. I only talk to people in a room on the official matrix.org server. They're all registered there. Does anyone else get that issue ever?
My (imperfect) understanding is that this is because of how end-to-end encryption works: you not only need to receive the messages (which are stored on the server, so you don't have to worry about them as you can retrieve them when you want), but also the keys to decrypt these messages (which are only stored on the clients, so whether or not they are available depends on you).
Possibly, one of your clients has the keys needed to decrypt one of the messages, but you're using another client which doesn't. Things go back to normal when both are connected at the same time and can share the keys, or when the client of the sender is connected and still has the keys.
If you don't keep your clients connected all the time, you can use a secure backup on the server, so the clients can retrieve the encrypted keys from the server and decrypt them locally.
Not having the keys happens more often if one the parties uses short-lived sessions (like logging exclusively in a private browser window, for example).
This article helped me with understanding a little: https://gerstner.it/2021/02/matrix-and-e2e-encryption-or-how...
Possibly, one of your clients has the keys needed to decrypt one of the messages, but you're using another client which doesn't. Things go back to normal when both are connected at the same time and can share the keys, or when the client of the sender is connected and still has the keys.
If you don't keep your clients connected all the time, you can use a secure backup on the server, so the clients can retrieve the encrypted keys from the server and decrypt them locally.
Not having the keys happens more often if one the parties uses short-lived sessions (like logging exclusively in a private browser window, for example).
This article helped me with understanding a little: https://gerstner.it/2021/02/matrix-and-e2e-encryption-or-how...
What would be the minimum Digital Ocean droplet that could run this server for maybe 10 people?
I didn't know Digital Ocean before, but it seems like they are more focused on CPU than on disk space. This is bad, since you will need to store some data on the server, if you send any images at all.
We have a matrix-server running for 4 people since maybe 2019 and it's at 60gb disk usage right now.
So in that regard, 10 memers will need at least a 100gb so 24$ a month, but you can get a lot cheaper than that, using some other server hosters, which are more focused on giving you a lot of space instead.
Specs: The server we use has 4 cores (barely uses 1) and 8 gigs of RAM, 2.5 of which are currently used and 120gb of disk space, that will probably suffice for another 2-3 years.
Specs: The server we use has 4 cores (barely uses 1) and 8 gigs of RAM, 2.5 of which are currently used and 120gb of disk space, that will probably suffice for another 2-3 years.
You can always mount in an S3 bucket and use that instead of the local drive.
Hi, I been running Conduit in a "Allways free" droplet at Oracle Cloud.
Its been working without problems for a single user setup (no VoIP though).
I hope you get an idea of the minimum resources needed.
Its been working without problems for a single user setup (no VoIP though).
I hope you get an idea of the minimum resources needed.
Matrix does not need much resources per user or room
But if any user joins a large room with thousands of people, the server will need to keep up with all those state events.
So 100s of users wouldn't be much of an issue if they're mostly in the same room.
So 100s of users wouldn't be much of an issue if they're mostly in the same room.
I have tried Conduit in a small test installation, I liked what I saw, and I keep following its developments.
However, I also spent a lot of time configuring my Synapse server with tons of bridges, so even though I totally get the need for more "lightweight servers" (especially in order to break the Synapse de facto monopoly on Matrix implementations), I'm unlikely to use it as a primary driver unless some killer feature (like native Fediverse integration, at least via Fedi authentication) is implemented.
However, I also spent a lot of time configuring my Synapse server with tons of bridges, so even though I totally get the need for more "lightweight servers" (especially in order to break the Synapse de facto monopoly on Matrix implementations), I'm unlikely to use it as a primary driver unless some killer feature (like native Fediverse integration, at least via Fedi authentication) is implemented.
Synapse is kind of a pain, I think I'll give this a shot.
Has anyone implemented Conduit with other backend services via the Matrix API?
https://spec.matrix.org/latest/
Any reason why it's not a good idea to integration the API with server side (aka E2E or distributed drawbacks?)
https://spec.matrix.org/latest/
Any reason why it's not a good idea to integration the API with server side (aka E2E or distributed drawbacks?)
It's still broken for bridges when compared to synapse. Bots rarely register, and sometimes you have to manually log into the account etc.
On the other hand, their dev matrix channel is very active. Props to that. Still...beta software.
On the other hand, their dev matrix channel is very active. Props to that. Still...beta software.
Does this work over LAN?
I have never managed to self-host a Matrix server for my home because they all demand a domain name like matrix.something.com. I can't use a local address like 192.168.1.100.
I have never managed to self-host a Matrix server for my home because they all demand a domain name like matrix.something.com. I can't use a local address like 192.168.1.100.
I have a local only synapse instance with some bridges. You can use a local domain (server hostname.localdomain) and it works. Caveat is that using element with your browser does not work. Element desktop app and phone app works fine though.
Supposedly it needs some name (any name) for the userID so I don't think so. You can add a domain that points to your internal IPs though.
Are there any accessible deep-dives on Matrix speaking to how trustworthy / effective the privacy claims are, reliability of the code, etc?
How does it compare to a simple IRC server?
how does it compare to Zulip?
Zulip isn't a Matrix server. Zulip doesn't federate.
If you want a private, non-federated chat server -- for your organization, basically -- Zulip is awesome.
If you want federated chat, Zulip doesn't do that.
If you want a private, non-federated chat server -- for your organization, basically -- Zulip is awesome.
If you want federated chat, Zulip doesn't do that.
Since every matrix server requires you create its own user id, I never understood the benefit of being federated.
HN needs a federation megathread. It gets widely debated every other week lol. Anytime Mastodon, Email, Matrix, or XMPP get brought up, the old culture war gets revived.
You don’t need to sign up to multiple servers, if you can use the ID you already have to talk with everyone on other servers. Just like with E-Mail or XMPP.
..."if you can" use the single ID attached to only one server which, if unavailable, takes your identity with it.
Even with /.well-known/matrix or SRV entries?
it works the same way email does.
you can use a mozilla.com user id to talk to someone with a matrix.org user id, or a kde.org user id
all servers are equal participants in rooms, so a room doesn't live on a specific server aside from servers being able to create friendly names pointing to them, but nothing stops #foo:kde.org from pointing to the exact same room as #bar:mozilla.org -- both servers are participating equally and have their own shortcut name to the room
you can use a mozilla.com user id to talk to someone with a matrix.org user id, or a kde.org user id
all servers are equal participants in rooms, so a room doesn't live on a specific server aside from servers being able to create friendly names pointing to them, but nothing stops #foo:kde.org from pointing to the exact same room as #bar:mozilla.org -- both servers are participating equally and have their own shortcut name to the room
I can federate message across hosts, fine, but I can't move my username to another host, so it doesn't work like email, because with email the namespace is defined at the DNS level, and I just forward requests to whatever email host I want to use.
Being able to leave one server and join another while maintaining an identity (say, a public key for instance) is on Matrix's to do list, they haven't decided how to do it yet afaik.
Being able to leave one server and join another while maintaining an identity (say, a public key for instance) is on Matrix's to do list, they haven't decided how to do it yet afaik.
https://github.com/matrix-org/matrix-spec-proposals/blob/keg... is how we’re doing it, and it’s being implemented currently in Dendrite.
With webfinger, you should be able to do exactly that. Migration of accounts is not in E-Mail, but while email has mx servers, Matrix (and most nu-fed stuff, not sure about XMPP) should have webfinger support for that.
edit: Okay, not actually webfinger. But [0] has instructions for the `/well-known/matrix/server` way. It only talks about subdomains, but it should work across domains. Possibly also with the SRV header.
[0]: https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
edit: Okay, not actually webfinger. But [0] has instructions for the `/well-known/matrix/server` way. It only talks about subdomains, but it should work across domains. Possibly also with the SRV header.
[0]: https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
> it works the same way email does.
No.
Matrix is like chatting via GIT (distributed databases) and tends to be a great team messenger like Mattermost or Zulip - XMPP is structurally like email ...
-> see: https://news.ycombinator.com/item?id=36939676
No.
Matrix is like chatting via GIT (distributed databases) and tends to be a great team messenger like Mattermost or Zulip - XMPP is structurally like email ...
-> see: https://news.ycombinator.com/item?id=36939676
You are talking about two different things. Parent was explaining what federation was. Both XMPP and Matrix are federated, just like e-mail.
And I'd say that Matrix is closer to e-mail and XMPP than you seem to assume. Once the database is synchronized, it works pretty much the same way. Only if a missing message is detected in the graph, then a server makes another request for the messages it missed (backfill).
Moreover, Matrix and Git are quite different, since you want to be pedantic. Both the synchronization protocol, and conflict resolution are handled differently (Git does very little, Matrix is more like a CRDT in that respect).
And I'd say that Matrix is closer to e-mail and XMPP than you seem to assume. Once the database is synchronized, it works pretty much the same way. Only if a missing message is detected in the graph, then a server makes another request for the messages it missed (backfill).
Moreover, Matrix and Git are quite different, since you want to be pedantic. Both the synchronization protocol, and conflict resolution are handled differently (Git does very little, Matrix is more like a CRDT in that respect).
Apparently there's an idea for a feature to enable users to transfer their account and data from one federation node to another. Pretty sure it's in the "just an idea" phase, so don't hold your breath.
Would be nice to transfer identity to a new domain but leave the server the same, like we typically do with email.
Not understanding your claim...
How can I "transfer identity" to a new domain in email?
I can't move [email protected] to @outlook.com, nor can I move [email protected] to [email protected] .
How can I "transfer identity" to a new domain in email?
I can't move [email protected] to @outlook.com, nor can I move [email protected] to [email protected] .
Well, with email you can a) forward from one address to another b) set up an auto-reply (I've moved), c) copy your message history via imap/maildir/mbox-files. Ditto for address book(s).
Does Zulip have video calls and screen sharing? I took their “feature tour” just now and it seems 100% chat focused.
https://zulip.com/
Matrix (Synapse / Dendrite / Conduit / Element) all support audio and video as well as text.
https://zulip.com/
Matrix (Synapse / Dendrite / Conduit / Element) all support audio and video as well as text.
It has Zoom and Jitsi integration, which lets you create instant meeting on these platform. Anyways the killer feature of zulip that I find is its usage of threads, much more usable than slack threads which gets super overwhelming for me.
When I tried Matrix I found a lot of super right wing tech people using it. The main reason I could ascertain most of them were using Matrix was because they had been banned by other chat platforms for their opinions
Matrix is a protocol not a service.
This will always be an "issue" of decentralized services, just look at the Lemmy devs over on Lemmygrad, super far left. Anyone can host a server running a protocol, lets not throw the baby out with the bath water just because people are saying something objectionable in one server. If you don't like these people join/make an instance that doesn't interact with them.
This will always be an "issue" of decentralized services, just look at the Lemmy devs over on Lemmygrad, super far left. Anyone can host a server running a protocol, lets not throw the baby out with the bath water just because people are saying something objectionable in one server. If you don't like these people join/make an instance that doesn't interact with them.
I use it regularly. There probably are those communities you are talking about, but I haven’t personally seen them, so my advice would be to ignore them and join those that more align with what you’d like to see.
I’ve found many nice and welcoming communities on matrix.
I’ve found many nice and welcoming communities on matrix.
I've heard a lot of super right wing tech people also use email, cell phones, Twitter, and TikTok. I heard some of them drive Fords, too.
Like Mozilla and GNOME. And the left wing CCC. They were all banned everywhere.
Yeah you can find some ... Strange characters... off in the fediverse.
I have never at any point encountered "super right wing" people on any main Matrix server. I've seen a lot of the opposite, to the point where it seemed administration was unfairly strict on people they considered part of them, while letting the other side run rampant. I somehow doubt this.
The only time I've encountered anything of this description is when I was looking into why a server had been defederated, and then found out it was mostly neo nazis and weirdos obsessed with anime children. I had to actively seek them out to discover this.
The only time I've encountered anything of this description is when I was looking into why a server had been defederated, and then found out it was mostly neo nazis and weirdos obsessed with anime children. I had to actively seek them out to discover this.
How does this compare with Conduit? [1]
[1] https://demo.realworld.io
[1] https://demo.realworld.io
That said, it’s been really good for me. Reliable chat between my and a few friends, plus some big-ish rooms that I participate in.
The author also works on Veloren[1]—another fun Rust project!
[1]: https://veloren.net