5 ms·

I loved using IRC up to around 2016 or so. The main annoyance was that it fails to deal with mobile networks. Newer instant messengers allow you to see conversa

I loved using IRC up to around 2016 or so. The main annoyance was that it fails to deal with mobile networks. Newer instant messengers allow you to see conversations you missed, something that also makes it hard to go back. I've yet to try Matrix, as Discord is all right for the time being. How does it handle these issues? EDIT: Also, how does Matrix handle large communities? I'm interested not just in the user side but the moderator side of things.

yjftsjthsd-h 4y ago
Don't you just use a bouncer?
- cykros 4y ago
  Or irssi/weechat inside of a screen/tmux session on a host with ssh to attach/detach at will?
- userbinator 4y ago
  Indeed. In the decentralised spirit of IRC, if you want a client to maintain a persistent connection and/or log while you're away, you need to run one yourself.
  - shadowofneptune 4y ago
    I had never heard of one, so I never used one. I also would have thought of leaving my computer on all day just for IRC as ridiculous. I imagine I can't be alone with that, the simplicity of IRC has its costs. Does Matrix have support for it then, or not?
    - jakecopp 4y ago
      Matrix supports mobile great - you don't need to run a client all the time. It's well worth trying Element or FluffyChat on iOS/Android.
    - Arnavion 4y ago
      The Matrix homeserver that you have an account on acts like an IRC bouncer by default. The homeserver maintains your presence in the rooms you joined, and receives and persists events from those rooms, regardless of whether you currently have a client connected to that homeserver or not. When your client connects to the homeserver again, it can ask the homeserver for new events since the last event it has.
  - Arnavion 4y ago
    You don't have to run one yourself. Some networks like Rizon provide bouncers themselves. Otherwise there are a few third-party-hosted bouncers like chat.sr.ht. But yes, self-hosting is always an option. That said, having set up self-hosted ZNC (the de facto IRC bouncer) last week, it's a damn PITA if you want the same experience as what you get with newer messaging stacks. First, the default operation of ZNC is to replay the last lines from the client buffer regardless of whether your client already has them or not. To work around that, you have to install the non-built-in "playback" module. The OS I run ZNC on (Debian 11) doesn't package that, so it needs to be compiled from source with znc-buildmod, which means installing a C++ compiler. This also makes auto-updates harder because the module has to be recompiled out-of-band every time the ZNC package is updated by the package manager. Second, the playback module uses a ZNC-specific capability which your client may not have support for, in which case you'd need a script to work with it. Third, the playback module only operates in terms of server time. Your client asks the bouncer to replay all messages since timestamp T, where T is presumably the timestamp of the last message you received from the bouncer before the disconnect. But because of precision errors, this ends up replaying the message you received at time T, the one you already have, so your client ends up getting that message duplicated. If you were to artificially add some milliseconds to T to work around that, you could miss out on any other messages that did occur in that time, so that's not a good solution. (Message loss is worse than duplicate messages, especially when the point of setting up a bouncer is to not have message loss.) IRCv3 doesn't fix it either. The IRCv3 version of the CAP allows the server (bouncer) to implement either server time or "message IDs" or both. Message IDs would indeed solve this problem, but since server time is an option you can expect bouncers to only implement server time and not message IDs. Indeed, from a brief glance at the ZNC playback module code it seems ZNC itself makes it hard to add message ID support to that module, and even the new soju bouncer only supports server time.
    - welterde 4y ago
      Another alternative to the classic bouncers is using quassel or weechat-relay. Both have the core running on a server and both use a custom protocol to the clients, which allows you to have multiple different clients (desktop, mobile) connected with synchronized history. Of course this limits the choice of available client software by a lot, but it's an option to keep in mind.
lrvick 4y ago
Matrix syncs a buffer of messages and scales to large rooms of hundreds of people without issues in my experience. Importantly it manages to do this while supporting end to end encryption giving you high privacy in DMs, and high anonymity Signal etc can not match due to phone and phone number requirements. Also Matrix bridges well to other networks. I have several slacks bridged to mine so I only need to use Matrix. Think of a messenger and there are one or more bridges for it. Supporting matrix also means supporting open software and networks, unlike proprietary walled gardens like Discord that can at any time leak or monetize your chatlogs.
- shadowofneptune 4y ago
  Thank you. I moderate a moderate sized forum on Discord and it's nice to know there's at least one alternative if it goes to hell.

yjftsjthsd-h 4y ago

Don't you just use a bouncer?

cykros 4y ago
Or irssi/weechat inside of a screen/tmux session on a host with ssh to attach/detach at will?
userbinator 4y ago
Indeed. In the decentralised spirit of IRC, if you want a client to maintain a persistent connection and/or log while you're away, you need to run one yourself.
- shadowofneptune 4y ago
  I had never heard of one, so I never used one. I also would have thought of leaving my computer on all day just for IRC as ridiculous. I imagine I can't be alone with that, the simplicity of IRC has its costs. Does Matrix have support for it then, or not?
  - jakecopp 4y ago
    Matrix supports mobile great - you don't need to run a client all the time. It's well worth trying Element or FluffyChat on iOS/Android.
  - Arnavion 4y ago
    The Matrix homeserver that you have an account on acts like an IRC bouncer by default. The homeserver maintains your presence in the rooms you joined, and receives and persists events from those rooms, regardless of whether you currently have a client connected to that homeserver or not. When your client connects to the homeserver again, it can ask the homeserver for new events since the last event it has.
- Arnavion 4y ago
  You don't have to run one yourself. Some networks like Rizon provide bouncers themselves. Otherwise there are a few third-party-hosted bouncers like chat.sr.ht. But yes, self-hosting is always an option. That said, having set up self-hosted ZNC (the de facto IRC bouncer) last week, it's a damn PITA if you want the same experience as what you get with newer messaging stacks. First, the default operation of ZNC is to replay the last lines from the client buffer regardless of whether your client already has them or not. To work around that, you have to install the non-built-in "playback" module. The OS I run ZNC on (Debian 11) doesn't package that, so it needs to be compiled from source with znc-buildmod, which means installing a C++ compiler. This also makes auto-updates harder because the module has to be recompiled out-of-band every time the ZNC package is updated by the package manager. Second, the playback module uses a ZNC-specific capability which your client may not have support for, in which case you'd need a script to work with it. Third, the playback module only operates in terms of server time. Your client asks the bouncer to replay all messages since timestamp T, where T is presumably the timestamp of the last message you received from the bouncer before the disconnect. But because of precision errors, this ends up replaying the message you received at time T, the one you already have, so your client ends up getting that message duplicated. If you were to artificially add some milliseconds to T to work around that, you could miss out on any other messages that did occur in that time, so that's not a good solution. (Message loss is worse than duplicate messages, especially when the point of setting up a bouncer is to not have message loss.) IRCv3 doesn't fix it either. The IRCv3 version of the CAP allows the server (bouncer) to implement either server time or "message IDs" or both. Message IDs would indeed solve this problem, but since server time is an option you can expect bouncers to only implement server time and not message IDs. Indeed, from a brief glance at the ZNC playback module code it seems ZNC itself makes it hard to add message ID support to that module, and even the new soju bouncer only supports server time.
  - welterde 4y ago
    Another alternative to the classic bouncers is using quassel or weechat-relay. Both have the core running on a server and both use a custom protocol to the clients, which allows you to have multiple different clients (desktop, mobile) connected with synchronized history. Of course this limits the choice of available client software by a lot, but it's an option to keep in mind.

lrvick 4y ago

Matrix syncs a buffer of messages and scales to large rooms of hundreds of people without issues in my experience. Importantly it manages to do this while supporting end to end encryption giving you high privacy in DMs, and high anonymity Signal etc can not match due to phone and phone number requirements. Also Matrix bridges well to other networks. I have several slacks bridged to mine so I only need to use Matrix. Think of a messenger and there are one or more bridges for it. Supporting matrix also means supporting open software and networks, unlike proprietary walled gardens like Discord that can at any time leak or monetize your chatlogs.

shadowofneptune 4y ago
Thank you. I moderate a moderate sized forum on Discord and it's nice to know there's at least one alternative if it goes to hell.