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...
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.
"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.
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.
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 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.
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.
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?
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.
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.
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).
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?
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.
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?
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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?
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.
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.
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.
> 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:
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.
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.
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.
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).
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.
> 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!
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.
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 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.
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.
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).
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?
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.
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.
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.
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.
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.
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.
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 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 ...
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).
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.
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).
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
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 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.
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