Zulip 4.0: Threaded open source team chat
blog.zulip.com
blog.zulip.com
In comparison, Zulip:
- provides HTML export functionality https://github.com/zulip/zulip-archive#zulip-html-archive (example https://leanprover-community.github.io/archive )
- URLs are nice and encode meaning (e.g. https://memex.zulipchat.com/#narrow/stream/279601-hpi/topic/...) ... compare with Slack/Discord meaningless character sequences
- I'm excited about https://github.com/zulip/zulip/issues/4817 , which would allow viewing workspaces in 'guest' mode, without registering at all
Zulip is fast, light, and is a much more natural way to chat. The "river" of messages that you can zoom in and out of is just fantastic.
It's also dog-slow, I have to wait for it all the time. Editing a message is an exercise in futility.
This is on an 8-core machine with a gigabit connection in 2021.
Honestly, I've no idea how we can accept bad performance in Teams and Slack. I can grep hundreds of megabytes of text in seconds on a raspberry pi. You have to actively try to make your software shitty to not be able to do that on a modern desktop.
If what's app was not crap you could search by date, but I had to scroll.
Even so, I think WhatsApp's scroll is pretty fast especially compared to Teams. Teams only seems to be able to store 1 page worth of content in memory at any one time which makes scrolling for anything even an hour back excruciating.
I agree it is hard to find things again, but that's mostly because Slack's search is pretty bad, not because of any inherent properties. It's no easier to find old emails or old IRC messages or even wiki pages.
But the worst... The worst offender on our team thinks all of their replies must be seen by everyone. So they use the "Also send to #mainthread..." for every message they send. It's almost as if training on async chat is required for some as there's a total disregard for etiquette from some.
The problem is Slack, not your coworker. Slack's threads are conversation killers. Your coworker doesn't want to get siloed into a discussion in a thread with only the people who saw the first message, but Slack encourages that.
Sorry you're mad. Zulip does solve this problem one way.
I'm not mad. And there is an etiquette. I'm not blaming Slack - if you use it with some constructs in mind for how to keep conversations succinct and in their own places for others to easily find and use later - it works out better for all involved. There is value in using a tool in an efficient and repeatable manner that benefits all. This isn't a matter of being right or wrong. There are values in a user base being consistent in how they use a, mostly, unstructured tool - especially in the case of this example.
Unfortunately abusing a feature that's meant for other use cases and is not there to always be used ("Also send to #...") can be used incorrectly, and in this case it is. Everyone who needs to be in the thread is already there. It's just broadcasting to everyone who doesn't need to be the statement they've made.
I don't actually believe Zulip solves this problem, but it does look interesting for a number of other reasons.
I sometimes have problems to find the new message I know I just got a few seconds ago due to how "non read messages marker" and "threads" (or however they call it) interact.
I never understood why people where so hyped about slack while there most times where better alternatives.
And let's not even get started about slacks audio/video chat function which is by far the worst I had used in recent times. Even the unliked MS Teams is miles better for voice or video chat. (Just to be clear I never used MS Teams for anything but voice/video chat.)
Agreed!
To clarify the terminology, "guests" in Zulip (and other team chat products, e.g. Slack) generally refers to users with an account but with limited access. https://zulip.com/help/roles-and-permissions has more detail on that.
We've been tentatively planning to use the term "web-public streams" for streams that an open community has configured to be accessible without creating a Zulip account. The project is quite far along; the latest PR is here:
https://github.com/zulip/zulip/pull/16728
(The PR looks stale, but that's only because we paused integrating it to focus on finishing 4.0; I would be sad if we don't have it at least in beta this summer.)
Slack is particularly bad as you need to make a new account for each instance (i.e. project). And you need to log in to each instance separately on each device where you have Slack.
The need to have separate accounts per instance is such a hassle. I spent twenty minutes yesterday trying to find which account I used to sign in to a dev-related Slack on a new laptop that had yet to login.
I do hate the way that Discord forces me to use the same account and same profile on all the discord servers I connect to through the client. I could connect to different ones with different accounts on different web browsers, but that’s a royal pain.
I guess I care more about the different communities I connect to through Discord, and I want to have more unique profiles for each of them, whereas just the one profile works for all the slacks that I am connected to.
How? Each time I join a slack, e.g. haproxy, i need to make a new slack account tied to my email address for that slack instance. How do you make a single slack account to be used everywhere?
But after using it a while I now really dislike Slack et al, both in professional teams and for open source communities.
Zulip can give you the best of both worlds. It's a regular chat. But the threading model also encourages long-form, more forum or email like discussions.
Threads are easily discoverable and it's trivial to catch up on all the relevant discussions that you missed, while skipping everything that doesn't concern you.
You can still have some regular chat channels for typical ephemeral discussion that no-one is expected to read. It's really a great tool.
The only downside is the very subpar UX when compared to Discord or even Slack.
As for UX, I think Zulip has a strong advantage w/r/t the threading model, which you seem to be saying as well.
* Using the night theme, which some folks strongly prefer to day theme.
* Zooming to 110%, which makes Zulip's font size similar to Slack and its clones.
With any luck, this summer we'll migrate our default font size to match other modern webapps, ideally with a "Dense mode" that preserves the current size for folks who want to fit more content on their screen.
I've thought about changing the default theme to the day theme, but it seems a little sad to remove our current defaut (of automatically detecting the browser configuration via `prefers-color-scheme`).
I checked the website now to see if I'd like the night mode better, and I can't find any screenshots with it!
If people tend to vastly prefer zulips UI with the settings you mention, your product adoption will probably be much higher if your website screenshots show the dark mode with 110% zoom.
While it'd be nice to improve the defaults, I know that can be disruptive - the quickest quickfix would be to mention those settings in the installation instructions.
Failing the change mentioned above, it would at least be nice to include some screenshots on the help article about turning on night mode (ideally with some good alt text so google images picks it up).
Disclaimer that I only looked at the top two DDG results for "Zulip night mode"
Branding and visual design matters. Far more than most folks think.
There are a ton of unpleasant / user hostile features of Slack’s visual design. It is full of stuff blinking, flashing, popping in and out of view, etc. Trying to chat feels like having a conversation in the middle of a casino.
So please don’t do this.
Slack nailed it - and adoption numbers are proving that out over and over.
I got complaints even on teams font size being too small! Don't underestimate these issues.
Nothing blinks or flashes as far as I'm aware. Just the UI changing when other people interact with the server. Like emoji reactions pop in if someone adds one. Or left side bar highlighting things if there's new messages in them, etc.
Things pretty much any other chat-like application does.
I agree with that, and I hope my comment above didn't mean to sound dismissive of concerns about visual design!
Visual work to mean these workarounds are not required is one of our main priorities for the next few months, and I mentioned the above mainly because many folks have found them helpful when using the Zulip that exists today.
(As a sidenote, we have an open position for a designer).
FWIW I find the browser configuration check to be flakey in other contexts. Especially with non-technical people, who may never know to toggle dark mode.
I'm not sure there is a strong/good argument against it, though. e.g. word processors are "more complex" than text files for sure, but people have learned the benefits of those.
I think the education / user-onboarding flow could be improved perhaps.
Seriously, it's hard to express this experience until you've tried it. If you look at their feature lists, you can't appreciate the craft and love and thought put into Zulip that makes it stand out from other chat systems.
And you may live in the chat systems with your distributed teams all day.
I'd like to know what the others are.
except without requiring years to master
> I received over 20,000 messages in chat.zulip.org during my paternity leave. I really enjoyed reading everything and replying to the hundreds of topics where I had something to contribute or someone to thank. Systematically reading months of history would have been impossible with any other tool!
I don't think most people need to read everything they receive, but in my role as the project leader of a large open source community, essentially every conversation in chat.zulip.org is potentially relevant for me, so skimming every conversation is useful.
The critical thing here, both in my daily work and coming back from time away, is that Zulip makes skimming really cheap (`n` to jump to next topic, then read a moment and then hit `End` if it seems likely that the thread is resolved to check the conclusion, and then repeat). So a 150-message thread debugging something takes like 30 seconds -- read the first post (maybe a bug report), note who was helping investigate, jump to send and see that the topic ends with a PR link or other resolution.
At the same time, Zulip's organization means I could find the dozen of threads that might be a short thread presenting a question or problem that I'm our main expert on. In these cases, I can read the thread carefully, and send a reply resurrecting the thread (2 months later) with answer that was missing, some added context/background, or a link to a PR I made to put the answer in our documentation (my preferred solution to unanswered questions).
This has the effect of unblocking a bunch of useful work that had been waiting for me to return, and also giving me good context on everything I missed.
It's also pretty fun to see all the great that folks did while I was away :)
Essentially everyone has miniature versions of the catch-up problem:
* Fulltime employees coming back from a normal 1-2 week vacation. * Anyone working closely with collaborators in other time zones (I wake up every morning to a couple hundred new messages in chat.zulip.org sent by our international community members). * Any leader who spends a lot of time in meetings and wants to focus on the meeting and then batch-process communications afterwards. * Any engineer who wants to be able to spend a whole or half day focusing on a really difficult problem and catch up on conversations afterwards. * Anyone who's a part-time participant in an open community, whether they just check it once a day, one a week, or once a month. A user in this situation really wants to skim everything that happened and find what's interesting to them, not read the last few hours' traffic, which is what the Slack/Discord/Teams model forces you to do.
The same technique core works for all of these cases: pick your favorite streams and read them with `n` as I described above, then perhaps browse the list of topics in several more and click into just the topics that interest you and then mark the rest (if any) as read.
All IRC-inspired chat tools are a really rough experience for part-time participants -- they just don't have a way to let you prioritize reading interesting conversations. We discuss this issue at length and its consequences for inclusivity of the communities that use them in https://zulip.com/for/open-source/. (It's framed around inclusivity in open source, but the Slack channel model also can exclude leaders who spend most of their time in meetings)
(As a sidenote, being able to do this is why Zulip pushes users to have every conversation in a topic, rather than "threading" being a side feature used for 10% messages like some other tools do.)
We get basically perfect usage of the conversation system at work (an engineering org), and so I've always thought that the MS implementation was the best. It has almost all of the organisation positives of Zulip threading without forcing you to name every single thread, and with none of the onboarding pain. We also have 'New Conversation' as a button as suggested by a sibling comment, so maybe that's the key.
I find it interesting that we both had fairly self-centred views on how much the conversation system was used. Don't forget that MS have the actual data!
Discord's reply function is basically exactly what I want- It takes up no extra space, the message being replied to is not removed from its original context, and the reply shows a preview and lets you easily jump back to the original context.
It stopped the broken conversations, but it didn't make anyone use MS Teams any more than necessary. (Our group has been using Slack for longer than Teams has been around, and since Teams is still inferior in nearly every way we haven't switched; due to the near silence from every other org in the company, they're probably doing the same).
[1] https://stitchdx.com/blog/microsoft-teams-new-conversation-b...
We moved to teams from zooms ephemeral chats, and I have to say it's nicer in teams with all of the integrations and file storage.
tabbot: if you happen to see this, please please consider some kind of easy-mode which:
- by default always shows the text input no matter if you clicked on a stream or topic
- doesn't put the cursor in the "topic" input but the actual message input
- allows sending a message by pressing enter
- scrolls the window down when sending a message
- scrolls the window all the way down when clicking on a stream
- has a slightly bigger font size
- maybe also some simplification of the UI. You don't need the name of the stream above every message (see https://i.imgur.com/oeBY5yk.png )
To me the proof that the paradigm is good and it's a 'just' a UI problem is MS Teams. Teams has basically the same thread system - every message in a Teams channel is in a 'conversation'. When a whole org adopts Teams sometimes it takes some people a little time to learn not to create a conversation for every reply (my partner's company is non-technical and had this for a couple of people) but once you're going the system is clear to a new joiner. At my company (an engineering org) the thread system is universally used, works extremely well, and I've never encountered anyone who wasn't clear how it worked.
The big difference is that in Teams you don't have to name your 'conversation'. You can optionally give it a title if you want, but it's not necessary and that "what do I call it" step was always a bit of a mental speedbump in Zulip for my team.
We are actively working on several ideas in this space. (One of the most important that was released in 4.0 is the redesign of the Reply button to make starting a reply feel like it does in other chat tools).
I expect we'll be able to get into a really nice place with a combination of new settings with some mixture of "Easy mode" defaults, design changes, and onboarding adjustments. (We will do this while carefully preserving model/paradigm, in case anyone's worried). Feel free to stop by chat.zulip.org if you want to discuss specifics.
FWIW, we regularly hear from large organizations, including some with thousands of nontechnical users, about their having great luck migrating to Zulip. Usually they tell us they did a 30-minute training and then things went smoothly from there, or they didn't and it took a couple weeks for some users to get the hang of it.
In the scheme of things, doing a training is a pretty minimal investment to be able to use a better product for hundreds of hours a year. But of course Zulip would grow a lot faster if nobody worried whether their nontechnical users will thrive on it, so this area is a priority for us.
Your proposals would get rid of its main feature and go completely against one of its core ideas.
I just don't get how it's difficult to reply or quote someone's message when it's such a basic chat feature.
Instead they invent weird code like "shrug" thinking it's funny during business chat.
Also I often get logged out of mobile app and notifications stop reaching which makes it very unreliable as a business tool.
They need to fix where it matters.
On logging out of mobile apps, often that's from an IT security policy to have sessions last only a fixed number of days from the last login.
We added a feature to automatically extend the session length based on the last login of a user--so inactive users get their sessions expired for security, and active users don't.
If you're a long time user of Mattermost you might need your IT admin to switch on the setting: https://mattermost.com/blog/session-expiry-experience/
It was set to be on by default in Mattermost v5.24.
Regarding replying, we've been working with our community on adding different options for threading: https://mattermost.com/blog/dev-sneak-peek-collapsed-reply-t...
From the blog post you can join the discussion on the topic if you like as well. We're very open to your feedback,
Just curious, have you enabled the GitLab-Mattermost plugin? https://github.com/mattermost/mattermost-plugin-gitlab#confi...
If it wasn't easy to find, that's on us, and we need to do a better job in making things more discoverable.
Zulip 3.0: Threaded Open Source Team Chat - https://news.ycombinator.com/item?id=23860338 - July 2020 (133 comments)
Zulip 2.1: open-source team chat - https://news.ycombinator.com/item?id=21779717 - Dec 2019 (1 comment)
Zulip 2.0: Open source team chat - https://news.ycombinator.com/item?id=19284321 - March 2019 (96 comments)
Zulip Server 1.9: HipChat import and much more - https://news.ycombinator.com/item?id=18400988 - Nov 2018 (123 comments)
Zulip – Open-source, threading-based Slack alternative - https://news.ycombinator.com/item?id=17622987 - July 2018 (99 comments)
Slack channels are a waste of time - https://news.ycombinator.com/item?id=17622707 - July 2018 (49 comments)
Zulip 1.8: Free software Slack alternative with email-style threading - https://news.ycombinator.com/item?id=16863675 - April 2018 (148 comments)
Zulip Server 1.6 released - https://news.ycombinator.com/item?id=14506426 - June 2017 (14 comments)
Dropbox has open-sourced Zulip - https://news.ycombinator.com/item?id=10279961 - Sept 2015 (313 comments)
Dropbox Acquires Zulip, A Stealthy Workplace Chat Solution Still In Private Beta - https://news.ycombinator.com/item?id=7419408 - March 2014 (14 comments)
The project seems healthy, and is growing at a good pace and adding more features and people aren't burning out, seems to be doing a lot of things right as far as F/OSS project management goes. Tim is also a joy to interact with.
Zulip is the only chat I've used that is better than e-mail for some purposes. It's got great export functionality and it's the only tool I've used that has better threading than e-mail. Every message has a thread, and therefore a subject, and you can dynamically re-thread sub-conversations.
Am I the only person who’d prefer their, potentially corporate, chat not be tracked by Facebook.
Facebook owns Giphy [0]
[0] https://techcrunch.com/2020/05/15/facebook-to-acquire-giphy-...
(edit to add info and link)
Zulip is such a joy to use after other solutions. Threads are something that's hard to bend your team around at first (mainly non tech users), but they seem so obivous afterwards and it's hard to use another team chat without them.
One of the few things I wish it had was better admin and audit tools, because in my industry that is mandatory and while you can do it by poking the database yourself a reliable, featured tool would be great. As-is I use Zulip for internal chat and another solution for external (with customers).
In general, in its control panels and settings and options Zulip maybe feels a bit too "power user, then we restrict" than the other way around, eg when having an external user on my network it's a bit overwelming that their settings screen includes the entire org settings (but they can't change them). Pushing to your team is one thing, but when pushing something to customers or 3rd party any unwanted complexity is a major pain point.
Frankly in general Zulip doesn't LOOK like something you want to show to the people you ask money from (your customers), just like your car dealer doesn't want you looking at the inside of the car's engine. I know it's a difficult complaint to tackle because it's not about functionnality but purely perception.
Hope the team does well and looking forward to the future
The product feedback on external guests is very helpful! You're encouraged to stop by chat.zulip.org and start threads in #feedback about each item if you'd like to help design how we address it, but in any case I'll discuss them with the community.
(For readers missing context, Zulip provides read-only access to many organization-level settings to normal users as a form of documentation on the organization's policies and what options exist that one might ask an administrators to adjust).
I hold out high hopes that eventually Zulip will gain enough mental marketshare that folks will switch, since Zulip offers free hosting for open source projects, unlike ~~Slack~~ Salesforce with their bazilliontrillion dollars that they can't afford to spend to "sponsor" workspaces
The article from monadical describes it best: "...[Zulip] creates an organized repository of knowledge as a side effect"
Thank you to the Zulip team!
https://monadical.com/posts/how-to-make-remote-work-part-two...
I've been self-hosting since the 3.1 or 3.2 release for a group of friends and the threading model works great, especially when you log in after a break (whether that's 8 hours to go to sleep or 2 weeks after a vacation).
When I was looking at setting up a chat server for me and my non-technical/mixed group of friends (so they couldn't use IRC and set up bouncers), I considered matrix, zulip, rocketchat, IRC, mattermost, and slack.
When I had issues (I use the docker install), the team was very responsive on their zulip server (chat.zulip.org).
For those of you already using Zulip, I prefer this dark theme over the standard (bright) blue one: https://github.com/zulip/zulip/issues/11845#issuecomment-544...
Thank you Tim and the Zulip team for the great software.
Unlike a lot of Django code bases it heavily uses function-based views. It also uses relatively few third-party django apps.
Glad they at least got to opensource it instead of just killing it.
My understanding is that Zulip was called Chime internally.
Management pushed teams to use the tool, and it was tried but the interface was not polished.
Slack was already out and despite how it is seen today, slack far more appealing.
Slack’s interface, single sign-on and mobile app availability made it hard for Chime to compete.
I don't think this is accurate. At least, I'm aware of a chat project called Chime at Dropbox circa 2015 that was not based on Zulip and at least at the time did not materially involve anyone from the original Zulip team.
(I suppose some of those things could have changed since I last heard anything on the topic).
It seems additionally strange that after buying Zulip in March 2014 a wholly separate chat application would be in use. But stranger things happen.
It is ugly, sometimes will post to a different thread than you expect (not incorrectly, just the UI is very unclear where you are posting to), and has an infuriating tick that if you click off the the input box, it deletes everything you typed.
Otherwise, it gets the job done with minimum fuss.
We know this is a real UX problem, and we're working on it.
Before Zulip 4.0, there was a "Saved as draft" notice that appeared on closing the compose box, but empirically, that was invisible to some users, who had the terrible experience of fearing their message was lost.
The 4.0 release replaces the notification with a darker and better located notification, which will likely help some users. But we'll only know for sure whether it's still invisible to some users with time.
In any case, we're planning several more changes to improve the drafts user experience that didn't make it into this release.
https://github.com/zulip/zulip/issues/17396 is one current issue on the topic.
Thanks, you just made my day!
It saves the message into your drafts
The threading model might not be the best choice for all use-cases, but for a open-source project related community its superb (IMHO).
The onboarding cost is real, it takes ~5 min for someone to learn the tool which is far above the expectations of most users that expect it to just be "a chat".
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...
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.
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.
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.
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.
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.
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.
As a regular zulip user it's a shock to me every time I have to use the element client. I have the feeling the latter is very slack-like in tis look and feel. I could be wrong on this, luckily I haven't had to use Slack for 3 years. Unfortunately with people used to Slack, it will be a shock to them to use zulip.
I am working on an application that needs chat and user-to-user messaging and it needs to happen in the app. Options like Slack, Discord, Mattermost aren't suitable.
This really isn't something I want to write from scratch. .NET Core based App FWIW.
We have seen some users integrate Mattermost into an existing application. I'm not sure if these resources may be helpful? - docs.mattermost.com/integrations/embedding.html - https://forum.mattermost.org/t/recipe-embedding-mattermost-i...
If you have any questions or feedback, would love to hear as well.
https://miro.medium.com/max/7168/1*iwfLW4rnn6U-mlUQpmBAfg.pn...
If Zulip had a similar theme, I really believe they’d covert way more non-tech individuals.
Longer post on discord light theme https://blog.discord.com/light-theme-redeemed-c541b7ab13e9
- having an actual non web tech based app would be great because web apps always behave slightly different than real native apps..
(It's really hundreds of small things that are just weird - always feels like you use a app in a portal..)
There's too many projects (even on the front page right now "Scala 3.0.0") for which I have no idea what they are, and I completely skim over.
We'd love to improve, are there one or two things top of mind for us to change?
1. The reply button is too far away and small. It probably doesn't hurt to add text next to the icons like shown in the video in 4 to increase the click area.
https://i.imgur.com/DozvaBu.png
2. The replying message doesn't look intuitive, as, a bar to the left of a message looks like a quote instead of a live message I just typed.
https://i.imgur.com/lqefGBs.png
3. The quoted reply message's layout doesn't look right.
I really want a bit more roomy implementation than put everything condensed in 1 line. You can see a roomy implementation in 4's video.
https://i.imgur.com/voCziha.png
4. Quoting of messages
In another chat app (Chatwork), I can quote a message explicitly and I can also select a part of another message to quote only that, which is very useful when just responding to a part of another message especially when that message was long.
https://i.imgur.com/8dnqMZE.mp4
5. Not seen in the above video but if someone else quotes me, the whole message's background gets highlighted, so I can easily notice.
6. Mobile app needs to be able to access multiple servers but I'm sure you already have this request from many.
7. You said in another post that people get logged out automatically for security reasons but I think that puts a lot of inconvenience as I can only explain to those infrequent users it's some kind of bug because they wouldn't agree it's a "feature" when they lose further push notifications by not doing anything wrong themselves. This is the biggest reason I cannot recommend Mattermost when it can be seen as unreliable.
8. This is probably never going to be changed but I don't like that everyone has to join a global room when they join a team. I'd rather want people to only join specific channels. Kind of puts a wrong pressure to have everyone who don't even talk to usually in a same room and a possibility to type something wrong to everyone isn't a plus either. I can make many teams but that loses visibility to all the channels I belong to in a single view.
9. Ability to disable automatic formatting globally. It's always annoying when people just type symbols only to end up the message looking funny and I want to disable automatic formatting. In fact, I don't remember when I ever needed to format my message in a chat when I'm not composing a wiki page.
Simply typing "text[new line]---[new line]text" would yield this.
https://i.imgur.com/wcv8s7J.png
I still think it's the best self hosted chat solution but lack of much visible improvements for years (I know you're keep making constant updates on the server component) is making me lose much faith on where it's going.
Let me share a few resources that may help here:
- We're working toward delivering [collapsed reply threads](https://mattermost.com/blog/dev-sneak-peek-collapsed-reply-t...) in beta in the coming months. This feature offers improved visibility for reply messages and better UX for threading. Feel free to dive into the design files (https://www.figma.com/file/JmNM3WmTKHTKU5Cf7uNwOj/MM-18107-T...) to explore more, or come test out the work-in-progress on our community-daily build environment https://community-daily.mattermost.com/core/channels/folded-...) to share feedback about the progress.
- You've shared some really interesting ideas around quoting parts of messages. While it's possible to use the markdown `>` character to insert a quote, I think we can certainly improve here to make quoting more easily accessible. Would you be open to share your ideas on the feature idea forum: https://mattermost.uservoice.com/forums/306457-general
- We are working toward a v2 of our mobile app that will support connecting to multiple Mattermost servers and have improved team and channel navigation. We expect to open it up for beta testers later this year. You can check out the designs here https://www.figma.com/file/a9w2q3JnVvBwo2IScP8j3K/Phase-1-De.... Let me know if you have any feedback or thoughts!
- We allow System Administrators to customize session lengths to keep users logged in for longer if desired. We also offer an option for Administrators to enable automatically extending sessions with activity so users will stay logged in indefinitely as long as they have activity in Mattermost at any time within the specified session duration. You can learn more at: https://mattermost.com/blog/session-expiry-experience/
- We have some improvements for text formatting planned this year to make markdown formatting more user friendly. You can check out the designs here: https://www.figma.com/file/4fiyoFl9xZSeGXHZFqf5dw/MM-21168-A....
Again, hugely appreciate your thoughtful and detailed feedback as we iterate and improve.
I'd welcome you to join our contributor's workspace to continue the conversation there with our developers and product team via https://community.mattermost.com/core/channels/tickets
Topics are lightweight and can be split, merged and moved around as needed.
Interesting, I've never heard that rumor before.
> a single write in a 5000 member public group would result in 5000 writes to the user table.
This hasn't been true since we implemented soft deactivation in 2017. You can read about the feature in our documentation here; I think it's a pretty cool design:
https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
The optimization takes advantage of the fact that public groups with 10Ks of members tend to have a lot of totally inactive users, and so if you have a good way to know that only 600 of them have logged in during the last 2 weeks, your server can run like it only has 600 users.
It is true that Zulip writes a tiny UserMessage table row with (user_id, message_id, flags) for every active recipient of a message, we need to do so in order to track the unread state for all of those recipients (as well as related details, like mobile push notifications state). We need to write to that row a second time when the user reads the message.
With modern postgres and SSDs, writing 1000 rows is really cheap, and so part this is extremely fast when sending messages with 1000 online recipients, which isn't a thing real users do constantly anyway (since that's effectively an announcement, not a chat message).
Folks who are curious can read https://chat.zulip.org/#narrow/stream/3-backend/topic/send_m..., which is related optimization work we did this week that made it into this release.
(You could have a bad experience if you use remote storage that rate-limits "IOPS", though, because AWS at least used to count each row as an IOP and would use your full quota for 20s if you marked 20K messages as read with a 1000 UOP/s plan).
No software architect here so I might be completely off the target but, is not read/unread count something that squares perfectly with the "eventually consistent" model? You don't need to write it down to the persistent storage right now as long as the client UI has it, then some kind of cache has it (so mobile can be in sync when refreshed) and then you persist it to the DB.
Especially since that latency is mostly invisible, thanks to local echo: https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
It's also not very high-value to optimize; that database write is 10-20% of the total time to process sending a message to everyone in a large open community like chat.zulip.org (with 18K total users).
That's not based on any sorta "secret insider information", it's just the pattern I've seen with companies they/we acquire.
So if Slack and all of its clones copy Zulip's model, I'd call that a success for us having changed the way people work. That said, Zulip is 100% open source under the Apache license (very rare these days), and that will remain a differentiator, as you can't self-host Slack, nor can you audit its source code or fork it to solve a problem specific to your use case. (We also have a lot of other innovative features, like native LaTeX support, customizable linkifers, etc.).
That said, topics are not something one can just copy in an existing chat app -- there's a lot more to Zulip's topic-based threading model than "a feature".
* Being able improve organization by renaming and splitting topics, move topics between streams, etc., is critical to the reading and conversation experience. This requires lot of thought about subtle technical and user experience details. (E.g. if someone renames a topic, and you were in the process of composing a reply, your compose box updates to the the new topic).
* Tracking unread counts on a per-message basis, rather than a "pointer within a channel", which is required for splitting topics to do something sane. This, in turn, requires clever data structures so that the moment the browser loads, you can see where all 35000 unread messages are. (Folks routinely have that when they come back to a busy open community after months away).
* All sort of clever performance and client-side caching things to make it feel like the browser has all your data so that clicking around feels instant.
* Dozens more things along these lines.
And those are just the engineering details. The bigger part of topics that it requires an overhaul of the whole UI. At least for us, a huge fraction of features are different than they would otherwise be because of topics (E.g. Zulip's compose box supporting sending to a different place than what you're looking at, and fading messages that weren't sent to that place to help users avoid mistakes). This sort of overhaul is hard to do, and even harder to do with a large existing userbase.
As a result, if Zulip fails, I'd be very surprised if it's because other companies copied Zulip's model so well that there was no reason to prefer Zulip's topics implementation.
Far more likely is some combination of our competition having infinite marketing dollars, inertia in organizations that don't realize how much better their working experience could be, and Microsoft's campaign to make everyone unwilling use anything other than Teams, because "we already bought Teams with our Office 365 subscription".