Because I have some experience with FOSS, I know you don't get the recognition that you deserve. So on behalf of everyone who's too distracted to say thank you.

Thank you!

Admittedly, it did take a day (less than), but once I got used to the interface Zulip provides. It's better than what I would have asked for! It's phenomenal software! The whole experience is better than anything else that exists. And everyone charging for the same features should feel embarrassed given how much better Zulip is!

Genuinely, it's impressive what y'all have created. So thank you!

Yes, hear hear! As someone who've run a couple of FOSS communities, many of them having chats via IRC, Slack, Discord, forums and more, using Zulip has always been one of the most welcome options, yet also the one that takes the longest for people to understand if they've never seen it.

But it's easily worth it, as you can actually come back and read through old discussions and understand things and it isn't a mess. It's like if you could force Slack/Discord to only do threads, and the entire UI is optimizing for that specific UX. Overall pleasant experience once you get over the initial bump :)

This feels like you're chatting with yourself.

I think you need to invite more people to your Zulip instance if you keep feeling like you're chatting with yourself.

I'm asking because I hate Matrix and actually want you to convince me: why should I accept the risk of migrating my friend group from Discord to Zulip, which has already "broken the seal" of restricting features behind a monthly fee even for self-hosted users, when I could migrate us to Matrix instead? Matrix seems like the much less risky option.

I see that you have a "community" tier that's free and doesn't restrict notifications, but it's not clear to me exactly what's involved in proving that we should qualify.

Mobile push notifications are a special case because it's literally not technically possible to self-host them. Or rather, it's possible if you build the iOS and Android apps from source and distribute them through TestFlight or an analogous Android channel, but it's not possible for the developer of an App Store or Play Store app to allow its users to point it at a different push-notification server, because the public key has to be hardcoded in the app binary. So if you want your self-hosted Zulip server to work with the Zulip client apps in the App Store and Play Store, you have to use Zulip's push server, and there's nothing Zulip can do to fix that.

Matrix works analogously; if you use the Element app from the App Store or Play Store, then you're using Element's push notification server, even if your Matrix homeserver is self-hosted. It's possible that Element allows their server to be used gratis in situations where Zulip charges a fee, I don't know their policies or anything, but in principle Matrix still leaves you exactly as dependent on a third party's goodwill unless you make your friends install a privately distributed mobile app.

Zulip IIUC does not restrict self-hosting of any feature that's technically possible to self-host.

But how ntfy does it then? It is one app that allows you to subscribe to multiple different notification endpoints. I have uptime notifications set up this way.

Wouldn't it be possible for Zulip to go this route as well?

The same way that Element does - they host a service for you that relays push notifications their Firebase Cloud Messaging endpoint for Android or iOS Instant Notifications for Apple. I believe ntfy's hosted option is the way they offset the costs of hosting this, even if self-hosted options can take advantage of those servers free of charge.

I think it's reasonable for Zulip to ask for compensation for access to these gateways, since Apple and Google do not make them available to end users free of charge, and the burden of responsibility to ensure that these systems aren't abused is on them. Also, the fact that they offer mobile push notifications for any self hosted server of up to 10 users is pretty generous, and there seems to be a Community plan option for larger servers that includes "groups of friends" as a qualifier. It really seems they're offering quite a bit.

This isn't true, self-hosted Android push notifications in ntfy are provided using a "foreground service" by default (i.e: the app keeps a websocket open and listens), unless you set up firebase for yourself and build a custom version of the app with the cert baked in.

https://docs.ntfy.sh/subscribe/phone/#instant-delivery

So it either drains battery and gets significant delays (as per ntfy's own docs), or it still uses Google's solution. There is no free lunch.

I think you misread, the delays are if you don't use instant delivery. I use it and it's extremely consistently delivered instantly, which makes sense, it's a websocket.

As to battery drain, I'm sure it technically does consume more, but according to my phone it's an insignificant amount: <1% of usage which is the lowest stat it gives you. Their docs suggest the same thing:

> the app has to maintain a constant connection to the server, which consumes about 0-1% of battery in 17h of use (on my phone). There has been a ton of testing and improvement around this. I think it's pretty decent now.

https://docs.ntfy.sh/faq/#how-much-battery-does-the-android-...

Honestly it's a good solution that works well with few downsides, the only real one is that iOS doesn't support doing it, but personally I don't have any apple phones so I do get an essentially free lunch.

Google doesn't have any magic way to do instant notification that nobody else has access to. The only thing they have access to in this regard is disabling any battery optimisations without triggering warnings.

Notification and battery performance is on par with google's solution except when an android build does dumb things to prevent the background activity, in which case notification performance gets worse and battery draw gets worse (not sure why exactly, it's just a common issue in these regards).

Well, there is an advantage, if everything is using the one service then you only need to have one thing alive to check it, so each new app is "free" if you already have push enabled (assuming that push notifications are rare enough the activity isn't the cost), as where each app doing it themselves is going to cause more battery use, so it isn't directly equivalent.

However, it also isn't a big deal, at least in my experience, at least for ntfy.sh.

Listening on a socket doesn't drain any battery when no data arrives unless the app does other things that actually use CPU. That's just what Google/Apple want you to believe so you depend on their proprietary lock in services.

Also like, how else would the Google / Apple services do it? Probably via sockets right? I guess you could do it in a pull-based approach on a timer, but that doesn't seem more efficient to me.

But waiting on multiple sockets for each app is surely more expensive than a single one, isn't it?

A single process waiting on multiple sockets is basically no more expensive than a single socket, but if each app has its own background process then that is more expensive. So for best performance you really want to delegate all the push-notification-listening for all the apps on a device to a single background process owned by the OS, but it'd be fine for each app to use its own push server (though of course most apps do not actually want to self-host this).

Because ntfy doesn’t, at least not in a way that detaches you from a central authority.

On its own notification to your device will happen eventually when the ntfy app on your phone wakes up and polls. Pull, not push.

My ntfy server has a config line for an upstream, which is a service that then uses push. Basically it’s self hosted and handing off push.

The default behaviour for self-hosted on Android is to have a foreground service which holds a websocket open, so it does get pushed from the server and doesn't rely on your phone being awake.

https://docs.ntfy.sh/subscribe/phone/#instant-delivery

The upstream approach you describe is only necessary for iOS devices that don't permit apps to do that.

https://docs.ntfy.sh/config/#ios-instant-notifications

On Android the OS implementation of "push" notifications is pull/poll based as well. At some interval, the OS polls Google's servers to see if there are any messages available. Firebase essential acts as a message broker, so that it only has to poll a single server, instead of a separate server for every service that wants to send notifications, and there is only a single service polling.

But I really wish Android supported specifying additional servers to poll (and/or replace the default server), so you could use a self-hosted service in addition to or instead of Google's service.

The difference between ntfy and another type of push is that you don't need a server owned by the group that makes the app forwarding messages through apple or Google. You can have your chat server send messages to your ntfy server, which then arrive on your phone.

You can self-host their notification server, and in their app you provide this server's url.

There is a lot of truth in what you write, so I am just going to point out the UnifiedPush project[0].

Of course with the, rather large, caveat of that not working outside of

> TestFlight or an analogous Android channel

This implements a push service (caveat: Android only) that is less restrictive than what google provides, and allows the reuse of an existing notification server (ntfy, prosody, etc) by other installed apps.

Since f-droid exists, this allows for a halfway decently user-friendly-ish way to completely self host outside of relying on googles server's and zulip, for example, could offer the ability to receive notifications through it if there's an a unified push distributor available on the phone. It seems that there is at least awareness for this in the project [1].

But with google tightening the noose around alternative ways to install apps, who knows how long this will be even possible.

[0] https://unifiedpush.org/ [1] https://github.com/zulip/zulip-flutter/issues/1198

The solution for this is to install the self-hosted Zulip as a PWA, but unfortunately they don't support web push.

Yeah. This is exactly my worry: as soon as solutions to technical problems like this start going in the direction of "we'll offer a monolithic solution and charge users for access to it" instead of "we'll make it as generic as possible even if the alternatives for now are flawed", it makes me wonder about the long term trajectory of the project.

I don't mean to cast aspersions on the developers—I respect everybody's right to try to get paid for good work, and this looks like good work. I am just not convinced it's the right option for my specific needs.

It's not a technical problem, it's a policy problem from the mobile vendors. You'd basically be paying them to deal with Apple's and Google's messaging infrastructure through their (zulip's) infrastructure.

I think it's right to worry about this. However, the Zulip project has a long (10 year?) history and track record with a stable team.

Can someone explain to me why we should do engineering work to build features where the stated objective is to help corporations use our product without paying for it?

Remember, self-hosted mobile push notifications already have a free community plan!

I can't say whether Zulip might be a fit for your needs. But you can always email our lovely sales/support team. https://zulip.com/help/self-hosted-billing#paid-plan-discoun... should give you a sense of our policies.

> Can someone explain to me why we should do engineering work to build features where the stated objective is to help corporations use our product without paying for it?

I'm not sure what you mean by this. I am looking for a replacement for Discord for my small community of friends, and before today I had never heard of Zulip and knew nothing about its pricing or policies or history.

> our product

It's either your product first or an open source project first. If you care more about having a marketable product then it's fair for people who care about open source to go elsewhere.

What would "as generic as possible" look like in practice?

> because the public key has to be hardcoded in the app binary

Nope. On iOS the flow is:

1. Generate a "push token" on the device (with the user's approval).

2. Send this token to your server.

3. Now you can send notifications to the device via this token. Your server needs to authenticate itself with Apple, and this requires an Apple account. But it's not linked to an individual app.

The situation is different on Android. Google went out of their way to make it impossible to customize `google-services.json` at runtime. So the built-in "easy" flow won't work. But notifications ultimately work using veeeeery obfuscated remote procedure calls to Google Play Services and you can run them manually. I need to do a write-up about this....

> Your server needs to authenticate itself with Apple, and this requires an Apple account

How does Firebase Cloud Messaging work with Apple without an Apple account, or is that implied in the client generated push token residing in Firebase?

I'm not sure, because I'm using Apple's notification servers directly, not through Firebase.

I believe it works just as a proxy, and you need to specify your own Apple credentials when you set up the Firebase project?

You're implying some difference here that I don't see.

Both platforms need some way for the client to register to their respective push services, Apple needs an Apple account, Android needs google-services.json.

Both platforms require your app to generate a token which the platform's respective push service holds, and send it to your server which you then use to identify the client you're pushing to.

Apple also requires the Auth p8, Bundle ID, Team ID and Key ID, which are roughly equivalent to the contents of the google-services.json.

On iOS you don't need a separate binary, the server-side infrastructure is not scoped to individual apps.

I don't think that it's possible on Android.

i would read that write-up!

It would be nice if you could run separate instances of an app that were considered separate, and forking around a push notification key would make a lot of sense. Another reason I would like to do this is to be able to have different Discord accounts coexisting on the same device. (But, the idea of having some set of different Zulip instances is maybe the exact same use case, with better server-side support.)

I understand that (IIUC in Matrix the client decides what push gateway to use, and the Element client just hardcodes matrix.org and lets anyone use it for free), but it doesn't really do much for my practical concerns. I'm looking for something my users can tolerate (which means no monthly fee) and that I can be reasonably confident won't rugpull us or vanish in the next ~10 years.

I guess my question is, what makes you confident that Element won't change the terms under which people can use their push server?

Nothing, but there already exist many other Matrix clients (shitty as they may be at present), as well as (IIUC) an Element PWA that uses web push (which is IIUC supported by Synapse) for notifications. Synapse also (IIUC) can be configured to use an arbitrary push gateway.

This is what I mean by "generic" in the other comment you replied to. I appreciate the value of tightly integrated server and client applications, and fully believe that Zulip's implementation of notifications may be both a) better for usability and b) a lower maintenance burden for the development team than supporting web push in a PWA, but---again---I am looking at this from a certain perspective where the way Matrix is architected and the breadth of the ecosystem imply less long term risk for my use case.

So it's not actually an architectural issue, it's just that in practice there are multiple competing Matrix apps whereas nobody has yet bothered to do this for Zulip?

> So it's not actually an architectural issue

I mean, maybe? It's not obvious to me that Zulip is just as easy to develop a third party client for as Matrix.

> in practice

What's true in practice is all that matters to me, because I have a real life use case. The only might-bes I care about are the risks.

> but it's not possible for the developer of an App Store or Play Store app to allow its users to point it at a different push-notification server, because the public key has to be hardcoded in the app binary

Setting up stoat.chat right now, I'll let you know if I have any notification issues with it ...

Doesn't Element support unified push?

So you can use a custom push server

I don't think we've ever charged a friend group or other non-incorporated group of people a dime for self-hosted notifications.

For the community tier, you don't have to do anything up to 10 users.

If your server has more than 10 users, you fill out a brief form (https://github.com/zulip/zulip/blob/main/templates/corporate...). We work hard to consistently process these requests within a couple business days, and the vast majority of communities are approved for full sponsorship without further interaction.

(Large communities managed by a business are quoted nonzero but extremely discounted pricing for self-hosted notifications).

I use Zulip every day for the julia programming language (https://julialang.zulipchat.com).

I really like Zulip, and I'd like to migrate my friend-group onto it, but it probably won't happen. I think Zulip is just a bit too heavy-duty for a friend group chatting, and also lacks the visual polish that a lot of people want.

For now, my friends and I mostly just use Signal for group chats, which leaves a lot to be desired, but IMO is still just a better experience for our purposes than Zulip or Matrix.

That said, if you have friends who are keen to try things out, I would definitely recommend at least trying Zulip and see what you like and what you don't. It has a lot of really nice features and things to love.

Having interacted a fair amount with the Zulip devs over the years, and being an open-source product, I believe that they have no plans or intention of trying to fleece or milk self-hosted users or small communities.

Thanks for the input. I'm working on setting up an instance, so we'll see how it goes!

Regarding risk: I certainly won't blame you for feeling risk-averse given the history of the tech industry. I can tell you about some unusual choices we've intentionally made to minimize risk for our users:

- We eschewed VC funding. A big part of my motivation was that I felt that VC funding usually requires eventual enshittification. https://zulip.com/values/ talks more about this.

- Zulip has been 100% FOSS software for more than a decade.

- At the very beginning, we built a complete data import/export system that allows migrating between our Cloud hosting and self-hosting; we put a lot of care into maintaining it well.

I can't promise that we'll never have something to sell for self-hosting communities. For example, I could imagine offering a paid add-on for encrypted backups.

That said, I'd like to push back on the idea that charging businesses for a tool that's an important part of their daily work "breaks the seal". Organizations with a software budget should be happier to pay a fair price for ethical, user-first software from a friendly vendor than for a closed-source product from a megacorp. And Zulip's full-time development team should be able to make a living building ethical FOSS software.

Thanks for the response. I'll discuss it w/ my users.

> That said, I'd like to push back on the idea that charging businesses for a tool that's an important part of their daily work "breaks the seal". Organizations with a software budget should be happier to pay a fair price for ethical, user-first software from a friendly vendor than for a closed-source product from a megacorp. And Zulip's full-time development team should be able to make a living building ethical FOSS software.

I think you touched on the sort of thing I'm concerned about with your mention of enshittification, though I think you're probably right that VC funding is involved in most cases. It is good to know that you've been at it for a decade and have (apparently) built a sustainable business selling a product people like.

My concerns (which I hope are understandable) aside, I certainly support your right to charge money for what you've made, as I said here (https://news.ycombinator.com/item?id=46953048).

Do you think clang, linux, and kubernetes could ever exist and survive in their current forms without the work of salaried developers? Volunteer maintenance is not sustainable; the long hours of unpaid labour are famously prone to causing burnout.

Free software is free as in speech, not free as in beer. If you want to save your cash, go use discord. If you're not paying, you're the product.

Grep and vim are a much smaller magnitude than Linux, so don't mix the two. And you do pay for Linux indirectly, it ain't written by some developer in their basements out of their good heart for a long time. It's written by Intel, Nvidia, cloud vendors' etc - full salaried employees. You just pay for it via hardware or cloud fees.

But to be honest your stance is extremely detached from reality. It's a huge privilege to be able to work on a hobby project, people tend to need food and a place to live, you know?

Grep and vim are obviously stand ins for a myriad of tools that together are much larger than Linux. And even Linux still has unpaid volunteers and even the majority corporate contributors are not that relevant to the discussion because none of them have control over the project to the degree that they could enshittify it.

> people tend to need food and a place to live, you know

That has never been enough reason to require that others support your business model. I for one don't need or want any more "products" in my life, especially ones that are or depend on services I can only get from a single vendor.

Etymologically, a product is a thing which is produced. But it's unpleasant to think about how the sausage gets made, so nobody wants to consider the goods in their lives as products. They want their Nikes to simply pop into existence before them.

Tools like grep and vim dangle by a thread based on volunteer work, and open-source maintainers are famously prone to burnout. Some tools survive by being very small—nobody's out there updating `ls` every month—but the only sustainable way to maintain a large piece of software is with a salaried workforce.

You may not want to interact with the systems that produce Zulip for you, but you should be suspicious of goods that hide their status as products. There's no such thing as a free lunch.

How is it double-speak? The "free" part doesn't mean "free beer"...

Huh? Where did he argue that you shouldn't pay for those things?

> The federation of Matrix seems risky to me to the person self-hosting. I don’t want to host random people’s content. I’ve read some interesting articles about the design flaws of Matrix that led me to believe that it’s not a good option.

You can just not federate.

My experience with Matrix as a "discord replacement" at the scale of a few tens of people is that it works and is stable but is also jank and has a lot of features I don't really care about, federation being one of them. Hence my enthusiasm for a possible alternative.

> What is confusing to you about the community tier? It is basically describing any type of community of people who are not a for-profit business. Groups of friends, non-profits, volunteer groups, etc.

The part that isn't clear to me is how you prove to the Zulip people that you are worthy of being included in that tier. I'm certainly willing to write a few sentences explaining my use case, but the help page is light on specifics.

I'm pretty sure it's just an honor system similar to a lot of similar software.

Corporations tend to self-comply because they don't want to risk failed audits and lawsuits.

If you don't want to just random people's content, dont let random people use your server

I recently moved a small community group from Slack to Zulip. Half because of the UX for infrequent visitors (topics are so much better than "50 unread messages in #general"). And half because of your organisational values, which are more aligned with ours than are those of Salesforce.

The Bluesky team talks about "credible exit", and Zulip has that in spades - which makes me not want to exit.

Thank you for the work you do. Hanging out in CZO watching the Zulip team work in public is inspiring!

> topics are so much better than "50 unread messages in #general"

my experience is exact opposite

Agree, unfortunately. Zulip is one of those apps I want to see succeed but I cannot for the life of me get used to the UX.

Huh, I have the opposite experience, I love Zulip's UX. The fact that everything is a thread in a channel means I can quickly skip the threads I don't want, and I don't have to mark things as read in an all-or-nothing fashion. Slack doesn't let you do this, if you read a channel, it's now read, and you can't say "actually, keep this thread unread for later".

I understand that part but it makes it really difficult to peruse when joining a large instance. I have little to no idea what I'm even looking for, which actions are going to cause side effects others can see, etc.

How so? I haven’t used Zulip but am curious to hear why

Not the person you are replying to, but I much prefer catching up on a small number of channels, than having to click around a bunch of different individual topics. But it is a tradeoff.

You don't have to click into topics. Zulip has a "channel view" which lets you see all messages in a channel, chronologically, just like Slack or Discord or IRC. That's actually the default experience when you click on a channel in the sidebar.

It also has an "entire server" view if you want to see everything in one stream.

I see thank you!

I think it depends on how you're interacting with the instance/server. I find the rust zulip much easier to follow than the k8s slack (or the lancer discord). I can see on a (much) quieter instance where it's a group of friends you want to see most messages where a single channel is a better option.

I agree with this. We use Slack at work, where we have a small team, and most of us are reading most messages in realtime. It works*

Contrast that to my experience with a group of volunteers who might log in a couple of days a week, communication is a lot more async, and you might not care about all the topics of discussion. I have found Zulip makes it easier to come back and catch up on just the bits you care about.

*I still think Slack encourages a "continuous partial attention" way of engaging with chat that I don't like. But, we do make it work.

Imagine communication server as... a house

Discord server is a flat. It's full of predetermined brick-walled rooms (channels) that have titles on the doors. You look at the titles, you choose the closest to the topic you want to talk about, you walk in.

Slack server is a meeting place. It has rooms, rooms have titles... but you can't talk in them. If you start a conversation there, you're encouraged to "go outside" (to a thread) with whoever joins you to solve the problem. If you walk into the room, you'll only see pointers to "meeting places outside" (also sometimes you can't even discover that room exists without a pointer?)

And Zulip is a warehouse (or a blimp hangar) - it's one open space with no walls. When you come in you hear everyone echoing off the walls. To not get lost, there are markings on the ground that color-code which parts of the space are for what category. And people are standing in groups, so you can come closer and concentrate on one topic at a time

---

If I want to ask a question,

- on Slack I'm immediately get shoved into a car and driven away to discuss (I don't feel community)

- on Zulip I have to navigate the cacophony of main screen, stand in the open and scream my question, hoping that people approach and form a group around me (I feel both open and alone)

- while on Discord I walk into a room that's "close enough", maybe look at conversation that happened right before to get a feel, and ask away (I feel like I'm in a lived-in space and can navigate the tone)

---

If I want to participate in a conversation

- on Slack I have to keep track of new threads. I have to explicitly open each one. I have to read through to see the convo state

- on Zulip I have to scan the "all recent messages" main screen, form an opinion on what discussion I'm interested in, explicitly open it, start reading last messages (now of the specific topic) again to form opinion again on what the state of convo currently is

- on Discord I can see the channel name to pre-emptively get general theme I'll be in (and I can mute channels I'm completely not interested in), I open it and start acquainting myself with the current convo state right away, learning specific topic from the context

---

I can definitely see how Discord's hard structure-ization can fail on large scale, when there is constant demand to use the rooms.

And I definitely have experienced channel "memory leak" (when they get allocated at one point and stop getting used as activity lowers, necessitating archival or garbage collection)

But I do feel that discord got that perfect middle ground between "everything together" and "everything in separate" extremes that all other options tend to fall into

This experience sounds very formed by the particular communities you've interacted with on each platform?

Personally I found Flowdock's thread model the best at least for small'ish teams (company size was <30). You can see it in action at https://web.archive.org/web/20210728031306/http://blog.flowd.... Unfortunately the company itself didn't survive. It was eventually acquired by CA which then killed it later.

(from my older comment) Essentially there is a default view which contains all messages as usual. Each message also has a symbol next to it. If it's grey message bubble, it's a message that is not tied to any thread (it can be replied to to start a new thread. Previously if no other messages have appeared on channel so far, it can be dragged & dropped to another thread). If it's colored message bubble, it's the first message in the thread. A colored arrow means it's part of the thread with that color.

This allows you to mostly just stay in default view with all of the channel's messages. As long as people are putting the messages in the thread itself, you could quickly use the colors to see which thread the message is on (color collisions did happen, but they were fairly rare). You would need to open the thread only if you needed more context or wanted to reply to it, though replying can also be done by writing to channel & dragging the message to thread.

Yes it's odd that nobody I know has copied this. Clearly better than what Slack and Teams are doing.

Your metaphor is slightly insane but I agree with the conclusion 100%. People who try to segregate every single line of text into a completely seperate walled off space is incredibly annoying, if for no other reason than real conversations tend to cover multiple subjects.

In Zulip, if a thread meanders with messages about a tangent, the authors/mods can choose to move those messages to a new thread (and IIRC messages with links between the two threads are created so it's easy to jump back and forth for any missing context)

I agree with most of what you said, apart from Slack in practice.

> on Slack I'm immediately get shoved into a car and driven away to discuss (I don't feel community)

It completely depends on the community / people. I'm in multiple slack servers where the threads are an exception for things that would otherwise really pollute the discussion. But otherwise, everyone just chats mostly in #general (or different rooms if the community is really large)

Slack depends heavily on the vulture that you build around it. I've been in companies where it was either everything in the specific channel (Discord like)/dm only, and in others, where threads have worked wonders. What caused this?

Different people at the wheel making decisions on how we will all use it, and encouraging the structure.

agreed, slack channels can definitely have the "lived-in space" feel to them (which is feel is the key point to the GP's comment)

Hey, just wanted to say that I am a happy Zulip customer.

I used it at my previous employer and after a month of hangringing from people- many did not desire to go back to what we had before. (though some people did say they wanted Slack for the emojis and “prettiness”).

Now I started in a new position and I’ve positioned Zulip (on prem) as the only viable solution since we’re shirking SaaS as a strategic move.

The people who followed me to the new place are quite glad of this, or at least thats what I am told.

So, thank you, sincerely.

Thanks so much for sharing the story!

I believe it was actually meant to be haranguing

https://dictionary.cambridge.org/dictionary/english/harangui...

> like twisting your hand until you agree

I'm also gonna be that guy - hand wringing is a stereotype of an expression of distress, not coercion. You're thinking of the idiom "twisting someone's arm".

Hey man, don't be sorry!

I actually didn't know so this was a good correction! :)

I think you got flagged for the "incorrect" definition, but I think you were being playful with a mnemonic to remember it- so that's not fair.

Some of the big weaknesses of running a self-hosted Zulip server for your community are:

- Your server admin can see DMs (or at least metadata, not sure if Zulip does E2E for DMs). The same is true for centralized services in theory, but unless you're a terrorist or a person of interest to a major government, it's extremely unlikely that a Discord employee will have an incentive to spy on your messages specifically. Your admin is likely part of your community and may know you personally, so the temptation is much, much higher.

- If the admin dies and nobody else has the keys to the kingdom, the server can go down at any point, and there's no way for users to reconstitute the network semi-automatically. Discord servers don't just go away unless somebody actively makes them to.

- It's much less secure in practice, it relies on your admin to always be on guard and constantly update their server to prevent vulnerabilities, either in Zulip or in the myriad of other self-hosted services running on it. One guy in his basement that goes on vacation once a year and has family responsibilities is far more likely to make mistakes than a team of trained cybersecurity professionals.

- Many Discord users are in 20+ servers. Anything that doesn't provide a one-click server joining experience (for users who already have an account on a different server) is nowhere near a Discord replacement.

- People want bots (for things like high-fidelity Youtube music streaming on voice channels), and those are mostly Discord-only.

- Anything open source will be worse at phishing and fraud / abuse prevention by definition, as many fraud-prevention approaches rely on the fraudster blindly guessing at what the code and ML models (do you even have ML models for this) are doing.

> it's extremely unlikely that a Discord employee will have an incentive to spy on your messages specifically

No, but history shows some unscrupulous staff members will always snoop, whether its just pure interest or something more nafarious like intent to sell on the black market. This makes the risk of your private data being leaked > 0, which should always be treated as a valid risk.

>- People want bots (for things like high-fidelity Youtube music streaming on voice channels), and those are mostly Discord-only.

So basically Discord is a warez service?

> If the admin dies and nobody else has the keys to the kingdom, the server can go down at any point

This is how infrastructure works, and supposed to work, besides the point that servers "die by themselves" which of course isn't true in reality. You decrease the bus factor if this is a problem for you.

> Discord servers don't just go away unless somebody actively makes them to

If all the sysadmins at Discord died and nobody else has the keys, exactly the same problem happens. Discord though surely have multiple backups of the keys and so on, something you too can do when you have your own infrastructure, so overall that argument feels almost dishonest, since you don't compare the two accurately.

> Anything open source will be worse at phishing and fraud / abuse prevention by definition

What? Completely orthogonal concerns, and if your main "fraud-prevention approaches" depend on security by obscurity, I'm not sure you should even attempt to be involved in those efforts, because that's not what the rest of the industry is going by a long mile.

> People want bots (for things like high-fidelity Youtube music streaming on voice channels), and those are mostly Discord-only.

Actually, the further I get in your comment, the more it seems like you don't actually understand what Zulip offers nor what the parent comment is about. Music streaming on voice channels? Completely outside the scope of Zulip...

----------

I think you have to understand the comment you're replying to a bit better, before attempting to lift Discord above Zulip. They're specifically talking about Zulip as an alternative "for managing the firehose of busy communities", not as a general replacement for every single Discord "server" out there. Yet you've responded to the comment as that's what they've been doing.

> This is how infrastructure works, and supposed to work

No, infrastructure doesn't have to work this way. This is a very old-school mentality.

Sign the content with a key that you control. Back up the content locally. And boom- your server is easily replaced. It only helps copy data around and performs certain conveniences.

I've been working on this full-time for a few years. If we succeed, we solve link rot (broken links) on the web.

Well, you're basically repeating what I'm saying, but with more detail. It's still what I true, "the one who holds the key holds the kingdom", just shifting it to the user rather than the admin. This is great, and works too, but doesn't make what I say less true.

Glad to hear E2EE is coming soon, but it’s been “soon” for probably a year now. It’s a bit odd that encrypted notifications still don’t work, and I’d argue it’s a very big caveat with regard to privacy and security.

Our main reason for using Zulip is that we work in a highly regulated space (healthcare) and would like to be able to safely talk about things. I suspect this sort of situation is a major motivator for Zulip adoption, so it’s weird that transit encryption was left as an afterthought.

(There has always been an option to just not include message content in mobile notifications).

Cryptography is not something you can do sloppily, and requires coordination between the mobile and server teams. Zulip 11.x included the protocol, but while doing the mobile implementation, we decided to make several more changes which have delayed it to the upcoming Zulip 12.0.

Some important context is that we retired the old React Native mobile app this summer in favor of the new Flutter apps (https://blog.zulip.com/2025/06/17/flutter-mobile-app-launche...), which has been an enormous improvement in the quality of the app and developer experience.

But as you can imagine, the cutover and relentlessly addressing feedback after it took a lot of time for the mobile team. We've also experienced an AI slop bombardment in the last few months that has consumed a lot of time. I'll save that story for another time.

What was wrong with React Native that caused it to be slow? How did you figure out that flutter was the reason for improved performance, rather than simply rebuilding the app with lessons learned from the old app?

Put another way, given enough time, what was not possible to do with react Native and is now possible with flutter?

What is Zulip's position on speech they/(you?) disagree with -- if someone is paying for non-selfhosted Zulip, are you going to delete/shutdown/dox users/operators that you politically disagree with?

If say the hyprland people were using a Zulip instance and someone astroturfed/brigaded/massreported a campaign to shut them down because they didn't agree to some external code of conduct and external enforcement of such, what would Zulip's response, as a company, be?

Moderation of self-hosted servers is entirely the responsibility of the server's owners (and perhaps hosting providers, if it's extreme enough). We have no way to know what's happening on self-hosted servers, and it's none of our business.

Regardless, there is no technical mechanism through which we could block access to a self-hosted Zulip server via the web application (which is hosted by the self-hosted server itself and designed to work on both desktop and mobile devices).

For Zulip Cloud, you can read https://zulip.com/policies/rules. One of the nice things about Zulip's model is that communities that we do not want to host can just migrate to self-hosting.

I'm really hoping for Zulip to succeed, which is why I'm even commenting. But it really needs people with UI/UX expertise. E.g. good user onboarding does not mean showing them a 2 minute video, as another comment on here mentioned.

My biggest feature use of Discord is the drop in / out voice with PTT. I couldn't quite tell if this feature exist.

PTT = push to talk (at least that seems the most probable match on Wikipedia)

Doesn’t exist in Zulip, theres a “camera” button that generates a jitsi link, I tried (and failed) to make it a google meet link, but it works surprisingly well, though it is a context switch.

Yeah Google Meet doesn't have an API to just create a call; several people have tried to hook together the Calendar APIs to make a reasonable similar integration and failed.

I assume this API omission is intentional on Google's part but don't understand the motivation.

Google workspace integrates with google meet. It's likely they don't want a competitor to google chat that uses meet infra.

Thanks for your work. Moved my company from Slack to self-hosted Zulip after Salesforce unilaterally decided to transfer our account to Alibaba Cloud and the transition has been very smooth. We especially appreciate proper markdown support !

Wow what the hell, Salesforce.

This is great to hear and ironically we (Pidgin) just decided that Zulip was going to be the next protocol we were going to add support for just barely 24 hours ago before all this Discord nonsense!

https://discourse.imfreedom.org/t/protocols-to-support/234/1...

Awesome, feel free to start a thread in #integrations in chat.zulip.org! We'd be happy to chat about some of the things that will make your life easier to do carefully when writing a new client.

The main thing regards our double-entry API changelog system. Basically, the API documentation for individual endpoints, say https://zulip.com/api/get-user, natively cover for each endpoint all the changes relevant for that endpoint from https://zulip.com/api/changelog... and how to write nice code using feature level checks to support all server versions.

That sounds great! I literally just wrote the initial skeleton last night so there's lots of work to do so any help is greatly appreciated! I'm hoping to have something somewhat usable by the end of the month.

Happy to hear Pidgin is still at it after all these decades. I still fondly remember using it when it was still called Gaim and only spoke OSCAR, back when Rob was involved before he started Asterisk. I lurked on IRC back then and even made a simple TUI when libpurple first came out.

It's kind of weird that e2ee is kind of afterthought everywhere. If I was making a chat system I'd obviously didn't want to keep anything that the users talk about on my servers unencrypted or decryptable. Why would you? If something is supposed to be public then keep it. If not, don't.

The weird "we pinky promise to try to keep it non-public for some time" is a weird idea.

Most consumers don't know the difference between "encryption" and "end-to-end encryption".

Zulip uses standard TLS encryption, where the messages are encrypted in transit, but the server has access to the messages.

The server having access to the messages is extremely useful for many key features. Access control policies. Search. Markdown rendering that can make guarantees to clients about its behavior. Mobile notifications for mentions. And many more. There's options for all of these problems, but it's /hard/ and you end up having a lot of risk of nasty bugs where "all the message history become unreadable" and a lot of performance issues.

This is why why end-to-end encrypted messenger apps like Signal are extremely minimal with basically no chat features, and can take a while to load long conversations ... there's a lot of expensive cryptography happening in the background. AFAIK it's not realistic to use the Signal protocol with the volume of messages people do in high-traffic Discord or Zulip communities.

Some other E2EE chat systems have more features but fail to actually provide end-to-end security. (For example, the server provides the source code for the web app and can freely modify that code to steal all the messages the user can still read, or the server is still in charge of metadata like channel membership ... so a malicious server could just add a fake user to every channel).

You get almost all of the security benefits of these "E2EE" chat systems by having a trusted person self-host the server, and setting a message retention policy if you want messages in certain channels to be automatically be deleted after a period of time.

Our vision for Zulip is not billions of people on our Cloud service. People should own their own communities, not corporations. And in that world, usually the person who runs the community can be trusted to host it.

> where the messages are encrypted in transit, but the server has access to the messages.

So the easiest and most useless kind. There were 1000s succesful db leaks for 1 successful mitm. Last time I heard of one, I did it myself on WEP. Https everywhere trend is super annoying for me because all it does for me is make my life difficult when I want to save time and transfer by setting up local caching proxy for myself.

> the volume of messages people do in high-traffic Discord or Zulip communities.

Why do people recieve volume of messages that's too expensive for their device to decipher? Are they gonna read them all?

Decryption should happen as needed. Before render. Before building local search index.

And what's up with notifications? Can't background process of my local app notify me?

> metadata like channel membership ... so a malicious server could just add a fake user to every channel

If you post to a channel anyone can join it's by definition public message regardless of any encryption. So no encryption needed.

> For example, the server provides the source code for the web app and can freely modify that code to steal all the messages the user can still read.

We should have an abstraction that is a socket that encrypts outgoing packets with my private key and deceypts incoming with provided public key.

Such chat apps should have only the right to use such sockets but not general ones.

It turns out e2ee in a chatroom is really, really, really difficult.

How does Zulip compare to Campfire and Stoat (and other FOSS) efforts? How is onboarding for non-tech people?

Onboarding has a thread going here: https://news.ycombinator.com/item?id=46951401.

My understanding is that Campfire hasn't been actively developed for ~10 years (https://once.com/campfire/changelog shows some minor fixes after the OSS launch; their GitHub has no 2026 commits). There are no mobile apps. It is not an actively maintained Discord alternative.

Stoat is early in development. For example, https://github.com/stoatchat/stoatchat has 1421 commits, compared with 68K for https://github.com/zulip/zulip/. I wish them luck! It's really important that we have multiple independent efforts.

https://www.rocket.chat/ and https://mattermost.com/ are open-core military contractors these days. You'll see what I mean if you visit their websites. But like Zulip, they are full-featured team chat systems, and if the parts of their system that are OSS work for your organization, they're certainly valid options.

Finally there is Matrix/Element. They have an inspiring vision and similar values to mine, and I'd recommend checking it out. Element/Matrix is built on an ambitious distributed consensus protocol with an E2EE option, which provides capabilities Zulip don't have but also adds complexity. Zulip is focused on just doing team chat really well, and does not support more than ~100K users in an instance. Hopefully will have a lot more resources now, thanks to Current Events. I wish the Element team the very best of luck!

----------------------------------------

Overall, Zulip's focus has always been on making a delightful chat experience, especially when you have multiple conversations happening at the same time. We aren't trying to build a clone, but instead the best possible experience for having lots of possibly complex conversations. So there will be some differences from what you're used to.

But critically, we spend a very large amount of our time relentlessly fixing micro-interactions that annoy us or are reported to us. If you read #design, #issues, and #feedback in https://zulip.com/development-community/, you'll get an idea of how we work.

So while there's some features we don't have that are present in other products, and we don't have dozens of designers on staff to do cool end-of-year animated reports like Discord does, you can expect few bugs and a lot of interaction design polish.

-----------------------------------------

The one mistake that I think a lot of folks make in evaluating options is focusing on buzzwords like E2EE without thinking through their threat model. E2EE doesn't add much practical security over self-hosting for many threat models, and it comes with significant usability trade-offs. And some current E2EE systems don't actually protect against a malicious server, say because they only protect message content, not metadata like who has access to what... just against raiding the server's disk.

(For example, WhatsApp has E2EE for message content, but I expect Meta's databases know everyone who's had a conversation with me on WhatsApp and the precise timestamps and approximate lengths of every message I've sent or received on the platform. And apparently some keyboard apps send what you're typing to remote servers!).

I think the single most convincing feature that I would like in a conversation app is for there to essentially be two companies with a public benefit charter that said that they cannot have common ownership or management, yet provided the same paid service, developed a common product though open source and had an etremely easy migration between them.

Ideally migration should be easy enough that it would be easy enough to automate a mobious strip subscription where it seamlessly alternated between providers.

If that structure existed it would be nearly impossible for a single provider to enshittify. The sad fact is that no matter how many assurances (often sincerely delivered) have been made, we have all seen instances where buyouts, management changes, or just someone in control going nuts, have turned platforms sour.

Open source is great but as this thread shows, just being open source does not mean functional or maintained.

Nothing is certain in this world, but I don't think that means one should give up and just use megacorp software.

And Zulip is specifically designed by some very capable people to be resilient. While we can mess up future versions, but you can always run (forks of) the older version. And as discussed on our values page, we've worked very hard to make the code readable and maintainable. (Various professors use Zulip as a teaching codebase).

We've made a lot of investments in the goal of having keeping-the-lights-on work for Zulip to be doable with a couple excellent people working part-time. It's good for our ability to spend our limited time on improving the product. But it also means that it doesn't require a lot of people to care in order for Zulip to remain functional and maintained. And I certainly care quite a bit.

So while I'd certainly expect other maintainers to introduce a lot more regressions, especially if doing significant changes... If you like the product today, probably the option will exist to continue using roughly that for a long time.

So like git and GitHub/GitLab/BitBucket should have made GitHub enshittification impossible?

No, How git and GitHub/GitLab/BitBucket should have made git enshittification impossible.

> Campfire hasn't been actively developed for ~10 years

For people looking for a simple chat that stays simple, is this a bad thing? When do we call something feature complete? If a product is free, they no longer need to manufacture new features to justify continued payments. It does look like there were updates 2 months ago. Based on the few number of open issues, and a PR closed last week, it feels like it’s being maintained, even if it’s not getting major new features.

I’m not a Campfire user, so can’t speak to the UX, but I feel like there is a market for actively maintained projects, that are considered feature completely, which aren’t searching for new features to shoehorn in. In the long-term, this need to constantly add features generally gets interpreted as enshitification by users. Avoiding falling victim to this relentless push for “more” can be seen as a feature in itself.

>For people looking for a simple chat that stays simple, is this a bad thing?

If the application does everything you want it to do, then no, it's fine. How much new development does grep get these days?

However, it was mentioned that it has no mobile apps, and that's a deal-breaker for probably most organizations and teams. If you can't access your team's communications channel when you're away from your desk, that probably isn't acceptable to many. And of course, developing and supporting mobile apps (on at least 2 platforms these days) is a large effort, and also requires constant maintenance since the two dominant platforms are continually evolving and changing their APIs.

No mobile app sounds like a feature in my book. Few things are so urgent that people should be expected to be reading and replying to chats while away from their desk.

If your job requires you to go on-site, or even to another part of the company to work with physical equipment, this is going to be a no-go. Not all jobs can be done from your desk.

Looks to me like it doesn't have mobile apps because it doesn't need them to work on a mobile.

Does your app pass the grandma and quarterback test? Can I get my grandma and the group's jock/quaterback to use it without handholding?

I'd say so, especially if you start on desktop and have them watch the 2-minute onboarding video. We are satisfied with what we see with our internal usability studies with nontechnical users.

Among customers, one reference that I can quickly cite is this one:

https://zulip.com/case-studies/gut-contact/

> Agents at GUT contact use Zulip every day to communicate with their team leads. “Most of our agents are in their 60s or 70s, so the software must be as simple as possible. That’s why we love Zulip,” says Erik Dittert, who’s been leading GUT contact’s IT team for the past 20 years.

I would recommend doing a little training/handholding call/video when moving over a community -- but this is true for any new app.

My mom needed training to do basic things in Squarespace, and I had a friend who worked at Slack whose manager started every chat message with "Hi <name>" and ended it with a signature, like you would an email. :)

    > and have them watch the 2-minute onboarding video

I'm going to be very honest here. The jock ain't watching no video. Dude has (possibly) early CTE. Do you think he has the attention span to sit through a two minute video? For a messaging app??

That's an automatic fail.

First, quarterbacks are not typically the concerning position with respect to CTE. Second, because he plays football he doesn't have a 2-minute attention span? "Dumb jock" is about as accurate as "ignorant HN poster". Third, he either spent 2 minutes learning how to use discord, or stumbled through it long enough to learn, why can't he do the same thing with Zulip? Would it help if they chopped it into a dozen TicToks?

They were needlessly inflammatory, but none of that changes the fact that something requiring you to watch a 2-min video to get started does not pass the [non-inflammatory term for non-technical person but you know what I mean]-test.

I'm saying this in a jocular tone, because - otherwise - the reality is too depressing. But I know people like this.

Anyone with a large enough social group will have some people like this. These are people who've engaged in football, boxing or contact sports like rugby. Or, people with severe ADHD. Or have had some kind of traumatic brain injury. These are real users and they're my friends.

I won't switch to using your application if they're going to be left out in the cold.

If a messaging application can't be used by that person, then that's a default fail. I'm not going to expose them to it.

But you will expose them to Discord's nagging popups for random quest thingies, animated emojis, disorganised channels, etc.? It sounds like you've already decided it's a foregone conclusion.

I am not arguing from a particular desire to get your jock friends on Zulip. Like I said in another subthread, I consider Zulip to be mainly for people who want to achieve things together, not just hang out. It's a productivity app. I wouldn't recommend it as a social app. Why I'm replying is because I feel your approach to the discussion is a little... uncharitable?

They're already using discord. It's a single click.

I think you're misunderstanding me. I'm not here to argue particulars. I'm sharing my reality as a user. A user who runs multiple communities. Including one for my friends. And my friend group extends to 2k+ people (my friends, their friends, their friend of friends... It adds up).

It's not fair that the CTE friend uses discord out of the box, but that's the power of network effects. Any competing solution needs to be 10x better to incentivise the switch.

I can setup a new discord server in a click. Versus,

    Sponsorship and discounts
    Contact sales@zulip.com with any questions.
    
     Community plan eligibility
     Open-source projects
     Research in an academic setting
     Academic conferences and other non-profit events
     Many education and non-profit organizations
     Communities and personal organizations (clubs, groups of friends, volunteer groups, etc.)

Respectfully, I'm not emailing your sales team to create a movie night server. Or one for class / group notes. Actual use cases. https://zulip.com/plans/#self-hosted

That's a huge friends group! :)

You don't need to email the sales team unless you have questions about the policy. It should be clear that "groups of friends" are eligible from the text you quoted.

You just need to spend 2 minutes filling out a brief form that's integrated in the server setup process if/when you have more than 10 users on your server. We enjoy hearing the brief notes users provide about how they are using Zulip. Is that too much to ask in exchange for reliably delivering you a service that you use every day?

It takes quite a bit longer to install a self-hosted server or configure an organization for thousands of users than to fill out the form -- I'd expect most people to spend more than 2 minutes creating a VM before they even get to running the installer. I'd expect that nicely configuring a Discord server for 2K people takes hours.

Is there something that we could change in the website that would make it obvious this is not an onerous process? The purpose of the section is to make clear that self-hosting Zulip is free for this sort of non-incorporated community use ... but we do need to have some eligibility process where you describe what you are, or it's free for Amazon too.

Not the original commenter, but I have faced similar friction from people who are not grandmas or quarterbacks. I don't particularly agree with its tone, but I agree with the original commenter's general message.

I won't be so confident to identify what it is, but there is something that causes "end users" to bristle at Zulip.

Where I'm coming from, everyone uses Slack. I spearheaded an effort to switch to Zulip because our Slack server is on a free plan and our messages get sucked into the void after 60 days now. Everyone agrees that this is bad, and that we don't have the money for Slack premium (we're an academic organization, so AFAICT we wouldn't even have to self-host to avoid paying), and yet so many people do not want to switch. Here are some common responses I've gotten:

* I refuse to use another messaging app and Slack is nonnegotiable for some of my collaborators.

* I don't want to learn a new UI.

* I don't want to learn a new UI that isn't basically the same as Slack.

* I will only switch if everyone else switches.

This is half a social problem ("I will only be receptive if everyone is using this"), but I do think there is some legitimate friction in Zulip's UI. I am fairly confident that we could successfully switch to Zulip if the Slack dissenters could be convinced to use Zulip --- or if Zulip could somehow be coerced into being more Slack-like.

As the "agent of change" at my organization, I felt like the resources Zulip provides are lacking in what I really need. Like I know there are technical details on how to move to Slack (https://zulip.com/help/moving-from-slack), but what I really need is help with the above: convincing people to try and acclimate to the UI. And yeah, I kind of agree that a 2 minute video on how to use Zulip is not the resource I need since it presupposes a degree of openness and cooperation that I don't have access to.

These are somewhat disorganized thoughts, but happy to expand upon anything if you're interested. I really do want to successfully move our org to Zulip since I'm tired of our messages disappearing.

It's not required. It's just there if you want it. Zulip is easy enough to jump into, especially if you have friends who actually care to onboard you into a community.

Adminning a Zulip for a small community group, I've actually found I have better tools to help with this. E.g. in Slack, we had constant nags to "please reply in the thread!" In Zulip, I can just move messages where they belong, and either leave the automated notes there to show where the messages went, or DM the person to let them know what I did.

Rather than getting outraged about prejudices that you don't want to be true, try to see the point of the response you are replying to: if you need to watch a two minute video to understand a chat application then it does not have a good user experience.

Tbf, Discord takes way more than 2 minutes to understand.

But reveals it step-by-step. When you click on a Discord link without an account, it says: Hello! What is your name? You check there are no faefolk around, and then type your name. Now you are in the chat room and you can chat to people.

A lot of discords have hoop jumping for rules or explainers. Then Nitro nags almost immediately and periodically thereafter. Server ops beg for Nitro boosts/packs.

I've gotten through a few of these, but they're not trivial.

But the friend group server won't have hoops, and the other nags while annoying don't act as a barrier to basic use.

discord lost me at having to use task manager to shut it down on Windows.

I am using it every day but never saw the need to download it.

> start on desktop

Echoing this. Navigation is better and clearer on desktop. The mobile apps works really well once you know what you're doing. Part of onboarding into Zulip is being able to get an "overview" of the community and the discussions that are currently happening, and this is easier on desktop.

In my experience, the median user for communication apps is mobile _only_. Before that, it better be a website that works well on phones, and decently on desktop.

As a developer I don't like it, but reality doesn't have to appease me.

This is a case where people can start talking past each other.

In my view and experience, Zulip is a collaboration platform for groups who want to get shit done. I wouldn't recommend it for a "place to hang out".

People who are serious about achieving something will use a laptop. Similarly, in a cousin comment - they will watch a short onboarding video.

No platform is "intuitive" for everyone. WhatsApp and Signal are "basically just SMS" so they can lean on the knowledge phone users built in the 00s and 10s. Anything else is a new mental model and takes some adjustment.

EDIT: also if you are an open source community, or a company, and you choose Discord for your support/project collab community... do better. (Looking at you CloudFlare)

> People who are serious about achieving something will use a laptop

Two decades ago it was said "People who are serious about achieving something will use a desktop" in response to laptops being underpowered.

> People who are serious about achieving something will use a laptop.

That really depends on what that "something" is.

That's true, and there are also people - like my partner - who only own a mobile device. She unfortunately wouldn't be able to have what I regard as the ideal experience joining a Zulip.

I use it for a non-it non-engineer group and everyone is happy with browser experience.

The mobile app is worse as it only allows writing in a few views that are not easy to access, and is becoming slower over time.

Data point of one: in my small community group that has moved to Zulip we do have a grandma contributing. No jocks though so I can't speak to that.

I would also like to note that Slack did not pass the grandma test in our case. I highly doubt that Discord would given how hyperactive the UI is.

As a software engineer who's had to interact with Discord only a handful of times, I had no idea when other people could hear me or where I had to click to find people I was looking for.

I've only rarely used it for voice, so I think I'm not in the right demographic. But I find its text/chat UI janky as hell.

man, I want to support something like Zulip, I would even want to work on a product like this but one thing I'd say is you have to go back and study why Slack beat Hipchat and others. It's so simple in hindsight but it was the marketing and the UI/UX of Slack that made it so much easier to use. If you'd like, I have a ton of ideas and experience building UIs and would love to give you some of my input. Too much typing for a comment at the moment.

You should stop by #feedback in chat.zulip.org and share your ideas!

Regarding the history: Slack had very effective marketing, powered by a lot of venture capital. And HipChat was a weak product that had an embarrassing total hack, which did not leave customers with confidence that their data was safe there.

Zulip is not venture-funded, so we're reliant on people sharing it with others to get the word out.

As a side note, I don't think Slack could have succeeded if it launched today. Microsoft Teams has far far more users as Slack, and it's slopware. You can thank the end of anti-trust enforcement for that.

Fun fact: Shortly after MS Teams launched I created an internal "reconstituted" desktop Teams client for myself and the poor souls in my org that had MS Teams thrust upon them. It extracted resources from the (unminified!) electron app as well the js and CSS files from their web version, then repackaged it again via electron, wrapping into a standalone executable. Think like a really complicated greasemonkey/tampermonkey script.

My fork at the time replaced their criminal white space use and offered a more compact and information dense alternative using CSS and JavaScript, injected all post rendering. Ah, the silly things one is capable when faced with a minor inconvenience and a wandering mind...

Based on some (admittedly very surface level) research, one spot where Zulip will still struggle to replace Discord is Voice/Video chats and Screensharing - the little I could find about voice chatting in zulip is that it has to be configured to use an external service (jitsi, zoom, etc)

If you do no configuration, it'll use the public Jitsi service for video calls. So no action required unless you want a different video call provider.

> Zulip is much better than Discord or Slack for managing the firehose of busy communities. Or at least, a lot of people tell us that they prefer the user experience to everything else they've tried, after a few weeks of getting used to it. :)

Could you expand on this?

Slack has basically one main hierarchy level (messages are grouped into channels) while Zulip has two, streams and topics. So you can create a stream for each project (say) and create a different topic for any given point that needs discussion about that project.

Kind of like if each slack thread discussion had a title and was discoverable from the left sidebar and didn’t get in the way of the other threads.

> didn’t get in the way of the other threads

But also, critically, if you want to, you can drop back to the "show me everything sequentially" view. Threads hide discussions away - which is good when you want to focus on something else, but bad when you can't remember where a discussion was.

The killer feateure is that it's very easy to move last $x messages to another topic, so if someone writes a short note that begins a conversation everyone is free to reorganize it, and also moving messages between threads is easy and nice.

From what I have read (not having actually used Zulip) it always sounded like the chats were threaded in the same way that mailing lists or newsgroups are threaded.

How accurate is that understanding?

That seems like a reasonable comparison. I've thought of Zulip as halfway between IRC and a forum.

No, it’s not fully threaded like those examples (or HN). In a particular discussion, you can’t reply to a post in the middle and have your reply branch off from the main discussion.

Check out https://zulip.com/for/communities/ and some of the linked case studies; they explain it better than I'll be able to in a quick comment.

But the main reason is that the topics-based organization and ability for moderators to move/split conversations means one can read and participate in a community much more fully given a fixed amount of time.

Hi Tim. For pricing, it would seem that large, public-facing, Discord-style organizations would have to go with the free plan to avoid the pricing being prohibitive. Think something like the new Limewire community on Discord which has 2 million members. Or am I missing something about what a 'user' is considered in terms of being billable or not?

On a related note, I'm gonna check out Zulip for PortableApps.com. Any interest in having the Windows desktop app be portable? (We'd love to do that if we wind up using it)

The advertised pricing is for workplace use where the users are on payroll; if you read the plans page carefully you'll see we have free or highly discounted pricing for other use cases, both in Cloud and self-hosted.

Zulip is not designed to support 2M user accounts in a single organization. But if you enable the public access option (https://zulip.com/help/public-access-option), such that no account is required just to read content, you can end up with 1-2 orders of magnitude fewer "total accounts" that just wanted to see something once and don't actually use the server.

Ah ok, that makes sense.

If you're curious, I put together a dev test for our developers and users to check out: https://portableapps.com/node/80118

Just dropping in on a completely unrelated note to thank you for developing PortableApps - as a kid with no UAC access almost two decades ago now it helped me immensely to develop my interest in IT :-)

Hi Tim! (We know each other :))

I'm curious whether you feel you're actually in control to actually make policy decisions about data protection or whether you feel you could be hit any day by the "$5 wrench" by the government any time they feel it necessary. I'm starting to feel that in this environment, nothing is safe, even if encrypted and on FOSS platforms.

Hey Dheera! It's been forever.

Personally, I advocate for self-hosting communications software, ideally on physical hardware that someone in your community has control over. Zulip runs great on old laptops, if you can solve the IP address problem for hosting it in your house.

And if you want to be extra careful, put your chat system behind a VPN/firewall, so it's difficult to identify what software is being used externally.

And if you're not going to do that, because it sounds like too much work, the next best thing is to at least pick a Cloud service where you can migrate your group to paranoid self-hosting overnight if you decide the work is now worth it.

Self-hosting this way doesn't protect against all threat models. I am human and have children who I love dearly, so it's hard to rule out the possibility of my being compelled to make a malicious release.

But at least the Zulip source code is entirely open and highly readable; so users would at least have a chance to notice and not upgrade. With a centralized architecture like Discord, you're entirely reliant on whisteblowers.

Also your website (https://zulip.com) is so fast and snappy, I was surprised to see everything load instantly when clicking around. I have not tried the app yet, but seeing a static website like this is quite refreshing.

Do you know if migrating from Mattermost to Zulip is remotely possible?

I had been using Mattermost because it's also (mostly) FOSS. However, they've recently been changing their released OSS edition to restrict capabilities... Unfortunately the org I maintain it for is having some issues with it now and I have metaphorical egg on my face.

Yep, it's easy: https://zulip.com/help/import-from-mattermost.

Hi tabbott. Thanks kindly for offering to answer questions. :)

I signed up on your site just a bit ago, but I'm a bit concerned with the paid upgrade. Unlike Discord, I need to pay per user, which I find onerous and would get out of control fast for the group I run with around 100 members. Is there any plans for a flat fee model? I'm even happy to pay twice what I pay for Discord Nitro, but yeah, $8/mo per user is too expensive.

If it helps at all, it's for a retro computing community group, and not for profit.

Not affiliated with Zulip, but have you checked the "Free and discounted Zulip Cloud Standard" info on their help center? https://zulip.com/help/zulip-cloud-billing#free-and-discount...

Sounds like you could be eligible for free or for a significant discount. Also:

"If there are any circumstances that make regular pricing unaffordable for your organization, contact sales@zulip.com to discuss your situation."

Thank you! I didn't see this when I was first looking into it.

First time hearing about this project and it feels mature. However, the landing page example of the app on web is…messy and noisy to the point i am totally lost.

This is not the case for slack or discord. I think having an awesome clean first impression would do wonders to sell what younare doing.

Can you give more specific feedback -- what specifically are you looking at, and what specifically do you think contributes to it being noisy?

Well for me it's the animations, and it doesn't seem like prefers-reduced-motion is handled anywhere. I go to some great lengths to try to eliminate animations with custom js/css, and things are still moving and changing. The logos are probably most immediately noticeable.

What is the video calling and screen share experience like?

Zulip "shells out" to other apps like Zoom or Jitsi for this with a light integration in the UI.

I'd call that a pretty major feature omission since it means splitting things across multiple apps.

Why is it a major feature omission? Screen sharing isn't an easily solvable problem, there aren't any good FOSS libraries out there (at least that I'm aware of).

Expecting a way way way smaller team that didn't get $1billion in founding, like Discord did, is an extremely poor mindset to have.

All you're proving is the need to implement a tech tax to force companies to fund FOSS at the behest of the federal government, which frankly I'm all for.

It's a major omission because the voice and video integration is one of Discord's killer features. Sorry that it's hard, but something that doesn't integrate those seamlessly isn't a discord alternative

Okay, I'm sure if they got $1billion in funding they could implement the same feature but expecting a way smaller team with way less resources to have parity with such a company is just unrealistic.

I'm not expecting anything from anybody, but I'm also not switching to a discord alternative that doesn't support those features

Zulip is a website packaged into an electron app. It does not take $1billion to implement webrtc into a website as screensharing + video / audio calls are a solved problem on the web (Zulip is a web app).

Where did you get the idea that it takes a ton of money to do it?

Discord's main competitive advantages:

* Centralized identity, and participating in multiple communities at once: People sign up once, then navigate to whatever autonomous communities they choose quickly.

* No hosting requirement (good for ease of use): Want a new autonomous space? Create it! Boom! No installation, no hosting, no monetary cost.

* Video streaming: No other chat client does this easily. Not Mumble, Ventrilo, Teamspeak, or these chat programs.

If you want to defeat Discord, particularly in the gaming server arena, you need to make interacting with multiple servers better and you need screen/video streaming.

> Create it! Boom! No installation, no hosting, no monetary cost.

Don't Discord servers have free tier caps? A few of the larger ones I'm on beg for Nitro boosts/packs from premium users for capacity and features.

Discord's main competitive advantage was getting a cool $1billion in founding and being able to support a massive team without the need to worry about profit for the entirety of its existence.

Nobody gives a shit about that man. I don't care if it's unfair. I care that this app does the things I want. How it came to be is entirely irrelevant to me.

It is when you're talking about competing with Discord which has very good voice and streaming support

This is my problem with the alternatives, nothing has replicated simple voice channels (next to text ones) that you can see who's in and just jump in and out of, with screen share. This shouldn't be any harder to implement than video calling itself but almost nothing has done it. Even spacebar chat is more interested in keeping discord bots compatible than achieving feature parity.

As a former user of Zulip at a previous company, thank you for this software, I enjoyed using it. Maybe I'll setup a private instance for friends and family so I can enjoy it once again.

how does zulip as a technical solution solve the ultimate problems with discord and gmail and so on - EU chat control, US porn control, etc?

arent you as a zulip instance owner going to have to implement all the same stuff as discord?

It depends on what you’re doing with the instance, where you and your users are located, etc.

If you create an invite-only Zulip chat for your pub trivia league or school parent association that’s all adults, probably not.

I don’t have any questions as of yet, but reading your site; it speaks to me and those values align with mine. Just wanted to say that I think the world could use a bit more of this.

Value-focused organizations mean nothing to me. They throw out their values as soon as they are in the way of financial success.

Having a fully open-source self-hostable product improves this significantly.

Hi @tabbott I've been meaning to pass this feedback on for 5 months, and I hope it comes across in the spirit it's meant.

I tried Zulip (cloud offering) with some techie/designery friends, so we should have been right at home but... the desktop app on macOS and the web app was visually unappealing and clunky, and we ended up going back to a paid Slack plan.

I looked for docs on how to theme Zulip (so I could contribute), or for existing theme packs that would soften the transition but found neither.

tl;dr: The functionality was good (Love the threading!) but the UI feels like the 2000s came calling. Some UI polish would go a long way.

My feelings as well.

You are referring to yourself as an “organization”, can you define that precisely?

> https://zulip.com/values/

Every word of this page appears as its own line on mobile.

How well does Zulip protect users' privacy against snooping admins? I.e., does it have E2EE DMs? Unfortunately, this is a legitimate threat to be concerned about

> Given current events in the USA

Don't worry - they're repealing section 230 of the Communications Decency Act.

The one that says platforms aren't liable for what their users post.

This means there will be no platforms at all very soon.

What is the purpose of repealing this act? Make platforms liable and thus enact more restrictions, is that right?

Makes selective political retribution easier.

As you suggest, it's clearly to curtail free speech further; but in a way that their supporters can claim isn't fascist because 'it's the companies doing it not the government'.

We do really need non-USA based social media, stat.

Companies already have the right to curtail space as much as they want. The government wants to force companies to ban left-wing speech.

>Don't worry

I'm not worried. We'll use Zulip which has values and thus takes responsibility for everything its users post, right?

How do you see Zulip comparing to anytype, https://anytype.io/ ?

Self hosting could be an option, but it does not help when a country require you to identify if a user is adult or not.

Doesn't self hosting usually exempt you? Most such regulations only apply to commercial entities above some minimum user count.

While I personally strongly favor federated solutions those are of significantly more concern in this regard.

Thank you! Zulip is a great project.

very good take. IMO "current events" goes back to The Patriot Act if not further. Aggressive digital surveillance by 3-letter-agencies has been active for 20-60 years

Looking for your features but no voice chat, no screen sharing, no deal.

The built-in Jitsi integration lets you create a voice chat call via a single button click. You can also put those call links in a channel description if you like.

We do have plans to make the integration offer some additional ways to jump into a call, and have been talking about adding video chat. But our focus has been on building the best text chat possible, given there are multiple actively developed FOSS video call systems that we can integrate with.

Jitsi used to be so frictionless, but now that their public instances are a bit more locked-down (understandably...) I wonder if developing a deeper first-party integration would be sensible.

If you are selfhosting zulip, what prevents you to selfhost jitsi?

I have in fact done that before several years ago, though when I looked at it again late last year it seemed more complicated.

Looks like it has integration with Jitsi Meet https://zulip.com/integrations/jitsi

in slack and discord i don't need another app i just hit the huddle button (in slack) and join a voice chat room in discord.

This is the problem with pitching zulip to this audience. The original thing that got gamers to switch to discord, it was their original and probably still is their primary target market, was a single login to a huge universe of voice chat rooms. Before discord gamers were setting up/renting teamspeak and ventrillo services (that were voice chat only). Hell for the first couple of years of using discord with my gaming group the only thing anyone ever posted in text was what time they were going to be on and what game they wanted to play.

I would say the main thing that got people to switch to Discord was the fact that voice chat was free, paid for by VC money.

sure but also that you didn't have to pass around your teamspeak/ventrillo information to every rando you wanted to play with, less friction in discord with invite links etc

I have never created an account nor logged on to use jitsi.

What’s the state of accessibility on Zulip?

(Thanks for making Zulip, I love it)

You can do everything with the keyboard, and we do write everything with screenreader accessibility and colorblindness accessibility in mind.

But we don't have a dedicated accessibility tester on staff, so we're reliant on people reporting issues that bother them in actual use.

I should also mention there's a nice TUI app: https://github.com/zulip/zulip-terminal, which can be helpful for some people.

Thank you!

I'd like to convince other parts of my organization to move to Zulip, this will help.

Why zulip instead of the good ol' IRC?