[vlmutolo]

I have very little experience with Zulip, so take this with a grain of salt. Just like Matrix, Zulip is open source and can be self-hosted. They both target instant-messaging use cases.

Zulip has a far more advanced threading model than Matrix. Currently, Matrix only has basic replies in the spec. In practice, everything in a Matrix room is in a single thread. It definitely makes it hard to follow conversations that are long-lived or in busy rooms or both.

Matrix is federated and Zulip isn't. You can run your own Matrix server and communicate with all the other Matrix servers that already exist. Rooms live on multiple servers and are resilient to the failure of any participating servers as long as one remains.

Matrix is far more general than Zulip. It acts as a store for arbitrary, eventually-consistent, ordered JSON data. Most of the time this is used to create an instant messaging service, but it can be used for much more.

Zulip subjectively has a nicer default client than Matrix (Element). Zulip's is special-built to handle its unique threading model.

It's also worth noting that Matrix is adding support for arbitrary threading [0]. I'm really looking forward to this. It should allow us to build a Zulip clone fully in Matrix with all of the benefits that come with the Matrix ecosystem.

[0]: https://github.com/matrix-org/matrix-doc/blob/kegan/msc/thre...

[tabbott]

I wish the Matrix/Element folks the very best of luck, because they're pretty aligned with Zulip values-wise.

That said, I don't think you should expect a Zulip-style threading user experience in Element anytime soon. Regardless of how the Matrix protocol for federation between servers is extended, providing the "Zulip user experience" would likely require a major overhaul of both their client/server protocol for Element and their client user experience. (Also, the proposal you link is for HN-style threading, not Zulip-style topics).

I don't understand Element's internals, but my basis for this claim is a huge portion of all technical and design work we do on Zulip wouldn't be necessary or would be much simpler if Zulip didn't have topics (E.g. the architectural decision criticized in https://news.ycombinator.com/item?id=27150492 is a good example). See https://news.ycombinator.com/item?id=27150196 for a few more examples. I imagine Element will only invest in all of that work that if they believe it's important to their business.

As an outside observer, Element's business focus seems to be on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not Slack, so while I'd love to see Matrix/Element borrow Zulip's topics model, you probably shouldn't hold your breath.

[vlmutolo]

Thanks for pointing out that the upcoming Matrix threading model I linked to isn't the same as what Zulip has. I wasn't thinking about Zulip's model correctly.

After doing some research, I think you're right that the proposal won't immediately enable Zulip-style threading. Though, it seems like a small change on top of the linked MSC (Matrix Spec Change) proposal would enable Zulip-style threading.

If Matrix had an event type that created a "topic", that's all you would need. The linked MSC is very general and allows events to reference arbitrary parent and child events, and allows updating those parent and child relationships. If the parent is some kind of "m.topic" declaration event, maybe that would be enough.

It's also entirely possible that Zulip style threading doesn't even require that new event and I'm just not familiar enough with Matrix to see how.

---

Your points about how advanced the Zulip client is, though, are very true. It will take a ton of work for Element or some other Matrix client to catch up. You guys really built something impressive there.

I look forward to seeing what Zulip comes out with in terms of federation. It's a tough problem.

[tabbott]

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.

[MattJ100]

As someone who worked on an XMPP web client that set up a whole session in a single HTTP request and response, I can say it's definitely possible to do this.

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.

[mekster]

> You can run your own Matrix server and communicate with all the other Matrix servers that already exist.

What's the benefit of this? Seems like a very niche feature.

> Most of the time this is used to create an instant messaging service, but it can be used for much more.

What other use could there be?

I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.

[kitkat_new]

> What's the benefit of this? Seems like a very niche feature.

Cross organizational communication, e.g. across ministries (like France realized it with 60 Matrix servers), across different offices of companies, across multiple companies, across universities (which was e.g. important for TU Dresden).

In principle it is the same with Email.

> What other use could there be?

> I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.

Matrix is a protocol, not a software. Specifically it is a communication protocol. So anyone can create software that needs communication which benefits from properties that Matrix provides, can use it independently of the software you are using to chat.

[vlmutolo]

If you can only talk to other people on your own server, then the application is limited to just team chat.

Matrix clients have the potential to be much more. You can use the same account for various team chats and still use it like a messaging app for your friends and arbitrary personal groups.

Maybe most importantly, federation provides resilience against bad server operators. If Signal had allowed federation, it wouldn't have been a big deal to ditch its servers when they introduced a sketchy cryptocurrency onto the platform. Because they don't allow it, everyone was locked in.