I disagree that there’s a good bridging story for any of these chat systems:
- You end up with banhammers being dropped from the other side of the network if a bridging user triggers some abuse threshold. Matrix dropped their public bridges due to the moderation load for this reason.
- They just diminish the user experience for the native system(s) being used. Squeezing all IRC traffic onto one Zulip channel/topic isn’t how Zulip is intended to be used. Reorganising topics and curating it for future asynchronous readers is a key draw of the Zulip design, and you can’t do that with bridges.
- Deep bridging requires explicit support from both protocols to mimic users, or else you end up with a wrapper user, which brings its own problems with user spoofing and other security issues.
So feel free to run a server of your own, of course, but I’m not volunteering any of the Cambridge hosting resources for this that currently run watch/ocaml.org as I believe there’s a material risk we’ll attract unwanted security holes if we do so. I think the OCaml Zulip server will do just fine without this, though; I’m enjoying using Zulip for my research group so far.