Quassel IRC VS Synapse

> But all of the modern services like Teams, Slack and Discord, have seamlessness between client devices as their first priority.

Can't speak for the others, but Teams is really hit-or-miss. Missed notifications, missed messages, out of order messages. Then it appears to be fixed for three months only to happen again. It mostly seems to happen on Android.

In general, you're right, multi-device appeared to have been solved for IM - at least MSN messenger and Skype had it - right around the time when the smart phone came around, but then we had the same problem again in the mobile world, because somehow those messengers couldn't successfully move to phones: WhatsApp and the likes was bound to one device again. They added web access later, but that was more of a hack than true multi-device support.

The big problem the phone messaging apps solved was that their protocols didn't require a persistent connection. Theoretically, all the other protocols, MSN, ICQ, Skype, IRC could have been extended to support this too, but it's always faster to just build something new and be first to market.

If you want to use IRC today and have that modern multi-device experience, IMO the most decent solution is Quassel[1] (and Quasseldroid for Android). It's like a bouncer, but uses a custom protocol between the bouncer (quassel-core) and the GUI (quassel-client), so that it can perfectly sync state across all devices, and with flaky connections on mobile. It obviously required you to run the core on some server so it's accessible from everywhere, so nothing for "normies" as TFA calls them, but to me it's what makes IRC usable in the modern world. I wouldn't want to use irssi in a screen via ssh in termux on my phone.

The next best thing, if you're a Web 2.0 aficionado is probably The Lounge[2].

[1] https://quassel-irc.org/

[2] https://thelounge.chat/

Quassel IRC: A modern, cross-platform, distributed IRC client. Tech Stack: C++, Qt.

You can use a bouncer to do this. ZNC is the most popular. Quasse is a different take on the bouncer, where you have a special client that logs into your Quassel server, and the server logs into IRC. Has certain advantages, like more seamless scrollback and so forth. A variant take on this is irccloud, which is probably the "best" if you just want something turnkey that works with minimal fuss. It has good push notifications, a good web client, and excellent mobile clients

I use purple-discord (libpurple/Pidgin plugin) + BItlBee (IRC chat gateway, libpurple variant) + Quassel (distribued IRC client, like a bouncer) on a home server, and use Quasseldroid to connect on mobile. I would eventually like to simplify this setup.

Personally, I use a self-hosted "Core" (server) of Quassel I compiled from source and host remotely. Attach to the Core "locally" on a ZeroTier LAN network through a persistent physically independent WireGuard/reverse proxy/edge node microserver using various open source apps (preferably compiled from source). On Android I use QuasselDroid and of course compiled from source .

I've been a massive user of IRC since the mid 90s... have written lots of bots, scripts etc plus set up plenty of stuff to deal with being able to disconnect your client without missing out on anything (currently use https://quassel-irc.org/ with the daemon on a VPS). I was even l33t enough to "read bitchx.doc" back in the day...

Quassel - Quassel IRC is a modern, cross-platform, distributed IRC client.

Seems really similar to Quassel (https://github.com/quassel/quassel/), though I don't believe that has a webclient...

What are you thinking of here? Synapse has supported purging room history since 2016: https://github.com/matrix-org/synapse/pull/911, and configurable data retention since 2019: https://github.com/matrix-org/synapse/pull/5815.

Meanwhile, Matrix has never needed the full room history to be synchronised - when a server joins a room, it typically only grabs the last 20 messages. (It does needs to grab all the key-value state about the room, although these days that happens gradually in the background).

If you're wondering why Matrix implementations are often greedy on disk space, it's because they typically cache the key-value state aggressively (storing a snapshot of it for the room on a regular basis). However, that's just an implementation quirk; folks could absolutely come up with fancier datastructures to store it more efficiently; it's just not got to the top of anyone's todo list yet - things like performance and UX are considered much more important than disk usage right now.

some context re the Matrix isses, long history apparently: https://github.com/matrix-org/synapse/issues/14481#issuecomm...

Why not Matrix? Here's one reason: it has incredibly hard-to-debug edge cases, and plenty of bugs. One of my favourites is the one where people are kicked out of your room at random, which was reported a year ago[0]. It wasn't fixed, however, because the head of the Matrix foundation (Matthew) presumably didn't like the issue being posted on Twitter.

This is honestly really disappointing behaviour from a platform owner.

[0]: https://github.com/matrix-org/synapse/issues/14481

> That doesn't make this situation any less bad to the rest of the community.

How is the community suffering here? Let's say Element adds a bunch of baller stuff to their versions over the next few months and then closes the source. Can't the community just fork the last AGPL version? You might say, "well then no one can take the AGPL fork and make their own closed-source business", but do you want them to? Even if you do, they still can with the existing Apache-licensed version, just like Element is doing right now.

You're arguing that Element will lose a lot of contributions, but TFA points out that despite being super open, the vast majority of contributions are still made by Element employees (which seems to be true [0]). It's not the case that Element is looking to monetize the (small) contributions of others, it is the case that others are looking to monetize the (huge) contributions of Element.

And besides, aren't the MSCs the core of Matrix? It's already super possible to build your own compliant client and server.

The situation is that Element needs money to keep developing the ecosystem. It would be cool if there were a big network of donors and contributions, but there isn't. You're essentially saying, "that's fine, go out of business then, and the community will keep developing the ecosystem", but that's not happening now, and it can still happen anyway with the Apache-licensed versions, which again people can still contribute to.

[0]: https://github.com/matrix-org/synapse/graphs/contributors