First impressions of Matrix: frequent lag spikes at upwards of 10+ seconds and now the server is just straight up dead

Please just use IRC, people ;_;

@sir matrix is great if you dont federate with anyone!

@sir this was my exact conclusion when I tried out Matrix. That, and the intense bugginess and bad UI of, even after 1.0-beta

@sir dunno how my server manages to stay afloat despite federating with large rooms. Have you tried to run it with PostgreSQL ?

@sir is heavily loaded and can lag a lot because it also runs integrations and whatnot.

Matrix being slow as heck has also been my first impression.

Since I run my own Matrix server, it doesn't feel like lagging to death / timeout ^^

@sir IRC is kind of broken as designed; the server pretty much expects to be talking directly to the user, so there are fundamental things missing, like knowing which past request an error message is a response to, or knowing whether a message you see or sent has been truncated because it was too long (or even what the length limit is)

@kragen @sir "feature i don't want is missing" is not quite the same as "broken by design", but it is very annoying.

@kragen @lain @ciaby scaling problems are not generally protocol problems

@sir @lain @ciaby on the contrary: scaling problems are very often protocol problems, and even more often are much easier to solve by protocol changes than by implementation changes. HTTP scaled better than telnet, gopher, or FTP for protocol reasons; NNTP scaled better along some dimensions than HTTP for protocol reasons; HTTP/2 scales better than HTTP/1 for protocol reasons; TCP/IP scales better than NCP for protocol reasons; and I think, though I'm not sure, that the IRC protocol beats AP

@kragen @sir @lain @ciaby

the IRC protocol beats AP

I have a counter-argument: IRCv3.

@kaniini @sir @lain @ciaby Sorry, due to Mastodon's 512-byte line length limit, I truncated my comment manually; I only meant that the IRC protocol is probably more scalable (admits more scalable implementations) than ActivityPub. And actually the message size limit is one reason for this.

@kragen @sir @lain @ciaby

AP is just as scalable as IRC once the streamingInbox extension goes live. we have just been busy working on stabilization and haven't gotten to that yet.
@kragen @sir @lain @ciaby I am right: the main scalability bottleneck right now is all of this completely and utterly unnecessary cargo-culted crypto advice. streamingInbox replaces all of that with pre-authenticated channels.

@kaniini @sir @lain @ciaby Well, I was thinking also about AP's individual messages being a bit heavierweight than IRC's, and about it not having a native channel mechanism to limit the number of copies of a given message that any given server has to make. But at least it doesn't have netsplits, right?

@kragen @sir @lain @ciaby

the cryptocrap is what makes AP messages heavy. Pleroma does as little of the cryptocrap as possible.

@kaniini @sir @lain @ciaby The example messages in have 160 bytes or more of apparently mandatory per-message overhead, which is about 4× the size of an average IRC message. At the point where we hit bandwidth limits this means a 5× scalability penalty. But presumably we have to improve other bottlenecks a lot before that becomes the problem

@kragen @sir @lain @ciaby

this doesn't matter though, because bandwidth capacity has exponentially increased since IRC came about in 1988

for what we get with that 5x penalty it's completely worth it.

@kaniini @sir @lain @ciaby But I was saying that the IRC protocol seemed likely to be more scalable than AP, not that AP's improvements over IRC and other messaging protocols weren't worth those putative scalability penalties. And as you probably saw in the other thread, IRC has substantial scalability problems of its own.

@kragen @sir @lain @ciaby

IRC is not more scalable though, because you have to start working around design flaws in the protocol that AP already fixes. it's basically a wash either way.
Show more
@kragen @sir @lain @ciaby

(and it does have a DAG mechanism, for deduplication, that's what sharedInbox is about. streamingInbox builds pre-authed channels on top of this DAG.)
@kaniini is there any branch wher streaminginbox has been implemented? @sir @kragen @lain @ciaby
@succfemboi @sir @kragen @lain @ciaby

not yet, but soon. we are still working out the wire protocol for it.

@kragen @kaniini @lain @ciaby
>Sorry, due to Mastodon's 512-byte line length limit, I truncated my comment manually


@kaniini @sir @lain @ciaby you must be this viral to ride this ride:


@sir @kragen @lain @ciaby
From what I've heard Matrix's terrible lack of scalability is baked into the protocol design, together with a DDoS amplification vector.

@Wolf480pl @sir @kragen @ciaby okay, but matrix is really a weird design. AP is essentially the same as email.

@lain @sir @kragen @ciaby
Until you start expanding contexts, as the specifications wants you to do. Though I guess litepub won't have such issues.

@lain @sir @kragen @ciaby
I'm guessing it doesn't take craziness, just naivety.

@kragen @sir @ciaby we'll see. But we know the current bottlenecks and they are not so hard to work around

@lain presumably someone has done load testing? I'd like to have some kind of vague order of magnitude idea of when things start to break: on a 1000MIPS machine with 1GiB, is it when statuses are flowing in at 1 Hz, 10 Hz, 100 Hz, 1 kHz, 10 kHz, 100 kHz, 1 MHz? Is it when there are 10 clients, 100 clients, 1000 clients, 10k clients, 100k clients? Does it matter how many other servers you're directly federating with, and where does that break, roughly?

@kragen @lain
>presumably someone has done load testing?


@lain @sir Well, what I mean is that it makes it impossible to fix the deficiencies of existing IRC software in a backward-compatible way on either the client or the server; my problem is not that features are missing but that you can't add them

@kragen the limit is well defined and you just seem to have encountered a bad client if it doesn't split it up/tell you it's too long.

@sir your client silently corrupting your data before sending it to the server is a solution in limited circumstances, but even so, it doesn't solve the problem, just makes it less frequent; and the institutionalized behavior when you violate the well-defined limit is to undetectably corrupt your data further, which is not reasonable behavior

@kragen this is still a client problem, not a protocol problem. Like I said, the limit is well defined, if your client doesn't deal with it the way you like you should ask them to change it.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!