| On the federation front, if your goal is to connect different chat services running different chat protocols, that's been possible for years with tools like Matterbridge (https://github.com/42wim/matterbridge). Zulip also has direct bridge integrations with IRC and a handful of other protocols, e.g. https://zulip.com/integrations/doc/irc. These integrations are a bit ugly and certainly not the ideal design, but they work and help a lot of communities that are 90% on Zulip but still want an IRC presence for whatever reason. (A fun historical note: Zulip's had a really nice puppet-powered bridge with Zephyr since 2012, because that was how we got enough usage during its early development to design the product and its data model with real users). Longer term, we're planning to build a native Zulip federation feature. For us the technical strategy has been to first make a Zulip world-class user experience, and do native federation later. Our strategy is motivated by XMPP, which like Matrix is extremely general (E.g. I talked to people who used XMPP as message bus for their backend infrastructure 10 years ago). XMPP is dying as a chat protocol because nobody can build a modern world-class chat application using it as the client/server protocol. E.g. multiple people who'd worked as engineers on now-dead chat products complained that because their mobile apps talked XMPP to their server, it was impossible for them to make the apps start quickly in medium-size organizations, because of all the round-trips required. In contrast, Zulip's client/server protocol both on web and mobile returns all metadata in a single HTTP request: https://zulip.com/api/register-queue, and then after that, another to fetch whatever messages you're going to look at. |
XMPP also has optimisations so you can resume a session across network disconnects etc. so that session initialization is typically limited to app start.
A more fundamental issue for many of these apps is that XMPP group chats were very presence-focused, and quite chatty (you need to join and sync every channel every new session). People have worked around that in various ways in the past. These days we have the newer 'MIX' standard for group chats which is not per session and far cheaper for many/large groups.
XMPP has evolved, and continues to evolve. But I fear that people inventing their own chat protocols is a problem that can never be fully solved.