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 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.

@kaniini @sir @lain @ciaby Scalability is only one axis of design quality. It's totally possible for one design to be more scalable than another despite being worse in other ways. Happens constantly, in fact. IRC servers routinely serve 10,000 concurrent clients (and, say, 1000 concurrent active users, and about 10 k messages per second) on sub-gigabyte hardware. ØMQ and AMQP implementations can beat those message rates by an order of magnitude; Kafka by 2.

@kragen @sir @lain @ciaby

and MQTT beats all of them. and, streamingInbox is conceptually the same scenario as MQTT.

but scalability and design are not really opposed axis, as bad design can impact scalability in ways that reduce overall efficiency.

@kaniini @sir @lain @ciaby Yeah, that's part of what I was trying to say — scalability is one aspect of software design, including protocol design.

@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.

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!