mjolnir VS matrix-doc

Ah, for a moment, I thought this was about the [Mjölnir project](https://github.com/matrix-org/mjolnir/) in Matrix-land.

I'm running a small (at the beginning it was completely public, now I'm keeping an eye on registrations) homeserver with synapse for a few years - I really like Matrix on a conceptual level and I'm happy that it exists even through it's not perfect it works pretty well mostly. I don't want to be too harsh because it's the best decentralized alternative for chat at the moment and it's open-source and there is a lot of progress but damn' it was a pain in the ass to run that server... we solved our problems mostly with throwing resources and memory on the problem... it's a nice tour de force if you want to learn about debugging distributed systems but it's nothing to install somewhere and just keep running.

synapse is quite a mess and there are a lot of hidden footguns if you just run a server - this is just the tip of iceberg to keep the postgres database somewhat sane: https://levans.fr/shrink-synapse-database.html - lot's of other issues in the issue-tracker where you can just scratch your head.

bridges are all subtly broken - the xmpp bridge is horrible and broke in so much interesting ways that I'm not going to touch it ever again - telegram works okay most of the time, irc-bridge also have some warts - but it's easy to criticize from my chair and probably unfair to talk so negative about it here but it's often buggy and broken for edge-cases - it works most of the time pretty okay but it's quite a mess and difficult to debug things.

moderation/spam/etc.pp is all hackable but it's all mostly quickly hacked up nodejs code that at least for us exploded in all kinds of interesting ways. https://github.com/matrix-org/mjolnir writing 3tb of logs in a few weeks and heating memory like crazy for instance. It's all complicated and there is no simple ui for anything.

So it's powerful but requires quite a bit of dedication and patience to get right. It's a full blown distributed system and often state is all over the place and once you make a mistake it's difficult to get right.

But there are so much promising projects that I'm confident that these issues will be resolved and it will only get better but in my experience it will break badly on all kinds of edge-cases - the mentioned xmpp-bridge created usernames that can't be deleted via the http api for instance. someone bridged 1000 channels via our telegram-bridge and there is no code to remove those channels - you have to code something up in python for yourself. irc bridge kicks you after 30 days idle because they can't handle the connections - freenode (before the takeover) said it's not them - maybe single threaded nodejs is not such a good idea for that.

Could I do it any better and delivering? Probably not. But except some adventure and if you want to deploy it for an org carefully test any assumptions you take for granted. It's cool but it's also kind of quick'n'dirty in a lot of ways. Still better than anything else I'd use it over any megacorp messenger anytime but maybe don't switch your family yet.

Moderation tools are slowly improving, but definitely still don't fit all use cases, and it's very unfortunate they don't come natively with synapse. I'm the lead admin of a Matrix ' Space', and our main room now has over 6,000 users (80%+ are inactive or barely active). We use mjolnir(https://github.com/matrix-org/mjolnir) to ban and redact users/servers/messages across all of our rooms, which has been a godsend since I used to have to redact all the racist/gore myself message-by-message. It's still reactive instead of proactive, but I'm hoping these tools will mature in time.

Group voice and video calls are not E2EE, and use Jitsi, but this is expected to change with Native Group VoIP Signalling.

DMs in Matrix are always E2EE, and MSC3401: Native Group VoIP Signalling means there should be E2EE in group calls.

From my perspective, the really exciting thing about this that it works equally well in mobile web browsers as well as desktop web - clicking on a link on Mobile Safari should Do The Right Thing without having to install anything.

Moreover, because it's built on Matrix, MSC3401 (https://github.com/matrix-org/matrix-doc/blob/matthew/group-...) means that we'll finally have decentralised cascading video/voice conferences once the SFU (selective forwarding unit) component is added into the mix. So, for instance, users on the same homeserver will get their video feeds relayed locally with minimal latency... and then users on another remote homeserver will also get mixed locally with minimal latency, trunking the two together. If the link dies or one homeserver dies, the conference will keep going - i.e. precisely the same semantics as normal Matrix.

What metadata does Matrix protect? Encrypted state events still aren't a thing for example https://github.com/matrix-org/matrix-doc/pull/3414 This means that server admins know what groups a given account is a member of, private or not, and they also have a general idea of what the topic of said groups are, even if they're encrypted. This would be a problem for groups about sensitive personal medical issues, like a private HIV survivors or Alcoholics Anonymous group.

The protocol itself is flexible and can be changed through spec change proposals on their Github. They're currently working on implementing threads, and they recently implemented spaces, which functionally combine the concept of Discord servers and server folders. They can also be nested.

At the moment this only works with Jitsi. It will be implementet soon with MSC3401

Something we're trying to do about this on the Matrix side is MSC2716 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc271...) - the ability to import archives of existing content into Matrix, and thus 'lock it open' and decentralise it for posterity: as long as one of the servers participating in that room stays alive (and the room is set up with infinite data retention, obviously) then the conversation will live on forever. (That MSC is also well worth a look for those interested in how Matrix works under the hood; MSC2716 was a surprisingly tricky problem to solve but it's basically finished now!).

Our first step will be to import all of Gitter's archives into Matrix - but we're then planning to add MSC2716 to all the existing Matrix bridges so that folks can use it to liberate chat history from Discord and Slack if desired, and avoid it getting paywalled/siloed/lost/held-hostage forever. We're also expecting to do USENET, mailing lists, forums, public IRC channels which have explicitly opted into logging... and generally archive as much possible in an open decentralised fashion, and ensure that gatekeepers can't lock up and blackhole info going forwards. After all, information longs to be free :)

by 'broken links' i guess you mean https://github.com/matrix-org/matrix-doc/issues/3628? it's a bug on the new spec website; we're working on it.