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 $randomname.yourdomain.org that can only talk to matrix.org.
* Send a join to #matrix:matrix.org
* Redirect $randomname.yourdomain.org 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.
@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.
@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 :).
@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.
@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.
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.
@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...
@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.
@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.
@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...
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.