[Arathorn]

For the record, there are no bad feelings on the Matrix side towards IRCv3 at all. The protocols are very different, and the design & architecture decisions in IRCv3 look fundamentally different to Matrix. In the end, Matrix is trying to be an openly federated object database with pubsub semantics - a standards-based decentralised encrypted Firebase, if you will. I really don't think that collides with IRCv3's aspirations, and we're looking forward to updating https://github.com/matrix-org/matrix-appservice-irc with IRCv3 features as they land. We're also looking forward to IRCv3 stuff to add to https://github.com/matrix-org/matrix-ircd, which is a Rust server which exposes an IRC listener for the entirety of Matrix. The open communications space has enough threat from silos like Slack and WhatsApp without in-fighting, and I'd hope the communities can get along and support each other rather than the opposite.

In terms of the line protocol - we all agree that HTTP+JSON is an inefficient baseline for Matrix. It's just a matter of time for someone to propose a proper binary transport (although HTTP2+gzipped JSON really isn't that bad, and works fine on dialup speeds). Luckily this thread has prompted a few people to offer to contribute one though, so perhaps we'll see some progress there at last :)

[kuschku]

Recently I had a user ask for better support for large channels, in the IRC client I contribute to sometimes.

What is large, you might ask? 18'000 users in a channel.

And still it should feel and be as easily usable as a channel with 10 users, even via dialup.

That's the point where every byte that isn't used optimally becomes a problem. And where HTTP2 eith gzip or even brotli just isn't enough.

Where Java's IO is too slow, and you need to use the new native noncopying IO subsystem.

But I'll also be happy if, someday, we'll have a truly universal protocol for this.