I tried hard to use . After wasting a week on it, I just had to give up. The protocol is just too bad, and the federation design is broken. It's impossible for me to run a server due to this. The Matrix protocol *by design* is the largest DDoS amplification attack vector I have ever seen. Until they fix that, I cannot use it. And it doesn't seem to be a priority to fix it, it's just "Would be nice if we would fix it some day".

To elaborate on this, here's an algorithm how to DDoS someone and break the Matrix network at the same time:

* Get a domain
* Get a wildcard certificate
* Spawn a stripped down instance with $ that can only talk to
* Send a join to
* Redirect $ to your target you want to DDoS
* Kill the instance, repeat with another $randomname

Now 2000 - 5000 servers will constantly hammer your target with TLS handshakes.

If you repeat that a million times, all Matrix servers are basically busy sending a million requests to your target. Repeatedly.

You sent out 1 mio HTTP requests, and your target will now constantly receive 2000 - 5000 times that. That's a pretty big amplification attack.

@js Thanks for the assessment. I'll stick to XMPP then.


it is easier to break the Matrix network: peers consider remote input to be trusted in almost all cases. this opens up the entire network to attacks similar to the depth counter overflow attack demonstrated last year.

@kaniini If anything, looking into this deeper was a good exercise in recognizing that XMPP is built by a bunch of backend guys, while Matrix is built by a bunch of frontend guys.

XMPP servers work reliably with little resources. But there's no client that is user friendly.

Matrix has beautiful clients. But the backend is just not usable at all.

Solution would be to throw away XMPP clients and Matrix backends, and switch the Matrix clients to XMPP. And then improve things from there.

@kaniini It just shows you can have utter crap and it will get popular just because the UI is nice.


not precisely; XMPP MUC is still highly inefficient. having something similar to ActivityPub's sharedInbox would solve this problem though.

@kaniini Agreed it's inefficient. MUC is XMPP's weak spot. It's still magnitudes more efficient than Matrix, though, and actually is usable in practice :).

@js @kaniini you have alternatives like mucsub on ejabberd or muc light in mongooseim . But I have no experience with them to affirm they really solve issues

@js @kaniini I never looked into MIX (the replacement for MUC), but maybe that's something it was trying to address. Somehow. IIRC it's meant to be based on XMPP's pubsub.

@kaniini I’m not familiar with how ActivityPub works. My idea would be to just have the server sign a message and then other servers accept that message from anywhere as long as it’s properly signed, so that the originating server does not have to send it to everyone.

@js sharedInbox can work in that way. sharedInbox is just an endpoint which can accept messages for multiple local recipients.

@kaniini What I’m unconvinced of is the use of HTTP for an instant messaging protocol, though. The only reason to do that would be web clients. But we have WebSockets for that now.

@js Pleroma's streamingInbox is largely meant to help with that on the AP side of things :)

To which I must ask: may be there's hope for AP as an IM protocol medium? Is there any work on this going on?


@drequivalent @js Pleroma chat will federate over AP + streamingInbox.

And ofc it will be an open spec so other social engines could implement it too or even make a dedicated one, right?

Now we're talking.
What about e2ee? Will it support something like OMEMO in XMPP?

And also conferences. That will be great to have too.

@kaniini @drequivalent Matrix did that and it’s a horrible experience. Please don’t.

@kaniini I hope Pleroma's AP-based chat is designed in such a way that building an s2s XMPP bridge will be easy. I mean, 'all sessions are rooms' sounds like only MUC would be feasible, but still.
@drequivalent @js
@kaniini @drequivalent @js oh boi i cannot wait for lack of good clients and shitty missing features.

@hj don't you have it already with Matrix? I've yet to see one Matrix client (or server for that matter) that is actually good.

@js @kaniini

@drequivalent @js @kaniini i mean we have XMPP with literally one good client which unfortunately is Android client, we have Matrix which has like 1 decent client for several platforms but not many alternatives, and now we're about to have pleroma-chat with zero good clients and probably nonexistent api.

@drequivalent @hj @kaniini Riot is by far the best open source client for any chat protocol I’ve seen. The current state is really sad :(

@js @drequivalent @kaniini if only Riot's codebase was... good. It's a mess of over-engineering, really delicious lasagna code too, so contributing to it is kinda challenging. Also Matrix's servers are pain to host too, unlike the very same prosody.

The current state of full-open-source decentralized IMs is shit and adding more different shit to it wouldn't help. Instead of spawning more and more alternatives we should just focus on improving and contributing existing stuff. Alternatives are nice but for some reason alternatives for IM just come and go all the time. Not even big companies that much differ from the rule (google's everchanging IMs, microsoft's deprecation of MSN and Live)

@hj @drequivalent @kaniini See my initial toot - it was exactly about how there is no usable server because the protocol is broken.

I haven’t looked at Riot’s code. But if it is anything like the protocol, I would not be surprised.

Agreed that there is currently no working, usable federated chat solution.

@js Matrix is basically what happens when HN-type webdevs try to reinvent XMPP. Some things are great, others are questionable, overall it's just broken.

@hj @kaniini

@drequivalent @js @hj @kaniini is it possible for pleroma chat to adopt the UI of Zulip? It might be more intuitive


@drequivalent @js @kaniini

One issue with "improving a single one" is that a lot of people have different opinions and goals :/

@kaniini I still think there’s no reason to use HTTP for s2s at all.

@js @kaniini noooo matrix clients are terrible, i used them for a while and hoped that they'd update as they promised, bc they were slow as hell and their architecture wass just a mess. but they were late for several months with their updates when i left matrix, not sure if something changed since then...

@js @kaniini and as for what i mean by "a mess", a good example is when crypto code (can't really call it a library) can't be used separately from ui code. last time i checked it had no docs and required react and a browser (localstorage, etc).

@leip4Ier That we are praising Matrix clients compared to XMPP clients actually is intended to say more about XMPP clients than about Matrix.

- Conversations is great and reliable on Android. It does lack VVoIP.
- Dino is new, not available as an easy-to-install binary for every platform. No VVoIP.
- ChatSecure on iOS is... buggy and unreliable.
- Monal on iOS has *previously* been... buggy and unreliable. I am yet to try it in 2019.
- Gajim on *nix and Windows is good, when it works. (On Macs, it's passable.) A lot of important functionality (image preview) is in plugins. It's not great when you have to tell people to install plugins just to get good default experience.
- Adium on macOS, like Pidgin, has not been kept up to date. Nobody ever worked on history sync APIs for plugins, so there's no MAM in libpurple, Adium or Pidgin. This is actively painful in case of disconnects. Fetching IRC (or other MUC) history is actually pretty useful, even more than in 1:1 chats.
- ConverseJS is very, very nice on web. No VVoIP, though. And for people expecting a Slack clone, fullscreen MUC UI is still lacking in features.

Other clients are not even trying to be 'modern' according to user expectations (which is, let's be honest: Slack-likes for groupchats, Whatsapp/Messenger/Telegram/Snapchat for 1:1 chats).

"End-users" would be easier to "convert" with shiny-and-glittery things like an easy to use, curated, high-quality sticker database. (See Telegram; super slick and fun.)

Maybe a "standard" i.e. centralized :( identity server for looking up people by phone number and email would help. Matrix is doing this optionally.

I also find it amusing that Riot for Matrix is implementing VVoIP by using Jitsi which uses XMPP and XMPP MUC as the backend system for WebRTC signaling.

@kaniini @js

@ivan oh. i see... never used anything besides pidgin and psi+, never joined any MUCs, i honestly thought it's better than what you described.

then... i dunno, #wire isn't bad, but it isn't decentralized. still looks more like a proprietary im like telegram/signal/etc, but afaik it's truly open-source (development model is, iirc, still not free).

huh, telegram's stickers are far from "high quality"/"curated", and that's what makes them good, i exported some packs before leaving.

@kaniini @js

@ivan and matrix tried to do that, too. and not only they don't allow independent artists create their own stickers, i even saw people asking to not send stickers bc their devices just hang upon receiving them.

as for standard identifier, i still think it's a bad idea, and in matrix case it isn't implemented in a nice way. iirc, it's closed source there?

yeah, i thought about jitsi, it's kinda strange. matrix once had some hack for group voip, but it's now discouraged.

@kaniini @js

@ivan clicking the phone button in a big chatroom led to some strange consequences half a year ago, though they should've just removed that button for rooms with >2 participants.

now thinking, gnome client for matrix (don't remember the name) has interesting ideas: they split up their code in two projects, one client for 1:1 chats, one for multi-user rooms. that's quite a nice thing to borrow. but i don't think matrix is gonna get much better...

@kaniini @js

@leip4Ier it’s really good if you use Conversations and don’t care about VVoIP, but I have close friends that do.

I have other friends that also care about Slack-like functionality being closer to, well, Slack. Can’t describe what because I don’t use slack, but I think it has to do with collaboration on documents.

@js @kaniini

@chebra @kaniini Yes. Never used it though. The idea seems to be similar to ActivityPub, but built on XMPP instead of HTTP.

@js @kaniini
It's actually like Facebook built on top of XMPP, coincidentally creating a pretty good XMPP client and android app. Not sure about the similarities with ActivityPub. It has it's quirks, but it could fulfill your needs for a Riot-like frontend to a XMPP backend


Lol, I noticed that when it hundreds of servers flooded my haproxy which caused everything to just die

@selea relayd handled it with ease. The Synapse it forwarded it to? Not so much.


The thing is, that I actually use a wildcard certificate for my matrix server ( I do ssl termination in haproxy )

@selea But you only run Synapse on one subdomain, right? The thing is that the attack is based on having short lived instances that after being an instance for a very short time point to an address to DDoS.

Sign in to participate in the conversation

Fast, secure and up-to-date instance, welcoming everyone around the world. Join us! 🌍
Up since 04/04/2017. ✅

Why should you sign up on

This instance is not focused on any theme or subject, feel free to talk about whatever you want. Although the main language is english, we accept every single language and country.

We're connected to the whole ActivityPub fediverse and we do not block any foreign instance nor user.

We do have rules, but the goal is to have responsible users.

The instance uses a powerful server to ensure speed and stability, and it has good uptime. We follow state-of-the-art security practices.

Also, we have over 300 custom emojis to unleash your meming potential!

Looking for a Kpop themed instance? Try