Some of the quotes in the article try to blame some of the harm from Coinbase's data breach on "know your customer" regulations. It's such self-serving nonsense.
Society is within its rights to demand that financial institutions both (1) protect their customers' sensitive personal information and (2) fight money laundering, which AFAIK is impractical without KYC rules at institutions like Coinbase that connect crypto to the traditional monetary system.
We're very actively working on end-to-end encryption for notifications; it'll be in the Zulip 11.0 release this summer if at all possible.
While I'm here, the Flutter rewrite of the mobile app is launching next month, and while the initial launch won't add much functionality over the previous React Native apps, the rewrite is way faster, less buggy, and a lot more pleasant to add new features to.
I lead the Zulip project, and frankly this comment is highly demoralizing.
For what it's worth, Zulip is entirely FOSS. In contrast with most commercial open source software on the market today, Zulip charges only for Cloud hosting, push infrastructure, and support -- not the software itself. We offer free or highly discounted plans for non-business use.
And yet, even we get attacked because we stopped letting businesses use our push infrastructure for free too. How are we supposed to publish a professional quality self-hostable product without any monetization?
If you oppose all forms of FOSS monetization, no matter how reasonable, you're advocating for a world where FOSS cannot compete in many product categories.
And if you want FOSS to succeed in team chat specifically, the real issue is that Microsoft Teams and Slack have entrenched their duopoly with some pretty effective anti-competitive tactics (Microsoft Bundling and Slack Connect, most importantly), and that fact isn't on many people's radar as an issue at all.
It is just one comment on Y Combinator's link aggregation service. People who haven't tried starting a serious FOSS project, do not understand how unsustainable it is. Funny thing is, like you mentioned, the monetisation isn't even imposed on the software itself, the entire software is free. It is on the *gratis* service to host it.
Entitlement knows no bounds. Don't worry about those disheartening comments, they are not coming from a place of genuine concern.
Hey friend, just wanted to chime in and say please don't be demoralised. Building a thriving business AND being OSS is extremely hard (I also work in this space) and I have immense respect for anyone who chooses to try and balance those things. Your work means a lot to me and my organisation, please keep building awesome stuff!
I wrote my comment because I want you to stop this practice. Being demoralized doesn't appear to change your mind about the decision to do what not a single other FOSS messaging app out there does. Zulip is the only one. Maybe reconsider Zulip's stance given how completely alone it is in its choice.
Your team made the decision, now you get to own it. And I'll keep putting a light on it until it changes. You call it vitriol, I call it fair warning to anyone considering adopting Zulip.
I am not a business and I certainly would not touch Zulip with a ten-foot pole given your team's decision.
Your comment made me want to check other FOSS messaging apps!
Briar — no push notifications.
IRC - could not find foss client with push notification support (maybe you know one!)
Delta chat — do not seem to provide the service themselves.
DeltaChat, when using a self-hosted Chatmail server, has a service that detects incoming mails for a user account, pulls a token ID out of their account info (file in the maildir), and sends a request over HTTP to the push server run by the DeltaChat team. This sends it on through APNS/FCM, then scrubs the data from memory. The notification only wakes up the app. No encryption needed.
The project runs on a shoestring budget and has no problem delivering 15 million+ push notifications per month without charging the users any money
As of 18 months ago, both Mattermost and Rocket.Chat, the other popular self-hostable alternatives to Slack, required a paid plan for mobile push notifications at the time we started charging for them (they are open core, so they also gate dozens of other features on paid plans). We didn't invent the idea.
For example, Mattermost's $10/user/month plan is proprietary software with roughly the features that Zulip provides as entirely FOSS (with a $3.50/user/month push notifications service).
By the way, since you mentioned Signal: Signal is great, but it's really just not comparable.
Signal is a SMS replacement/messenger app with minimal features that requires very low COGS per user, and launched with a $50M grant from a billionaire. Zulip is a team chat app designed to replace much more complex and capable products (Discord, Slack, Microsoft Teams).
You've left out Element, which does provide a similar suite of features with its Spaces. I concede Mattermost and Rocket.Chat. Thanks for the correction.
Yeah, Element hasn't tried push notifications for monetization, and they are FOSS. I will note https://element.io/pricing only advertises self-hosting options starting at $10/user/month.
I wish them the best of luck, and hope they're seeing success. Certainly in 2025 Europe should be thinking hard about the risks of a huge portion of workplace communication happening in Cloud-based chat and email applications owned by a few US companies (Microsoft/Google/SalesForce).
Honestly, we've had the same problem that Arathorn highlights in that thread. When I first started, I imagine businesses self-hosting Zulip would pay for support and fund the project that way. In practice, Zulip is too easy to operate for self-hosters to do that, and the better we make the product, the less support people actually need. The support-only business model can work, but I don't think it's workable for chat.
You are not an user/customer but you want to change the project? That's definitely not a fair warning, you are being completely unreasonable and should spend your time better in place of smearing other people's work with baseless accusations. People like you kill others motivation to do good for others for some kind of sadistic pleasure
I was a user. They're not baseless accusations, they're statements of technical fact and a statement of ethical belief. I don't believe it's right to deny users (including non-business users like myself) a capability that costs peanuts to run as a strong-arming tactic to get them to pay. I know exactly what I'm critiquing and why.
I'm not going to source-build and force a community of folks to source-build an APK to access an essential technical capability of a messaging app. Zulip is essentially rendered as useless in such a case. That is wrong and unethical.
Zulip's notifications service is free for community use, as well as business use up to 10 users. If you're not a business, why would you need to build a fork? Just spend 5 minutes filling out the brief community plan form and you're all set.
I can't say that the mobile notifications model is perfect. I have my frustrations with it. One of them that might not be obvious is that various military/government installations on airgapped networks are all freeriding.
Alternative options are (1) having no meaningful monetization of self-hosting or (2) moving away from being fully FOSS.
I have a very similar experience. Some students who want to get involved in contributing to open source will try to contribute to Zulip by taking whatever they wanted to say and asking ChatGPT to write it better for them, and posting the result.
Even when no errors are introduced in the process, the outcome is always bad: 3 full paragraphs of text with bullets and everything where the actual information is just the original 1-2 sentences that the model was prompted with.
I never am happy reading one of those; it's just a waste of time. A lot of the folks doing it are not native English speakers. But for their use case, older tools like Grammarly that help improve the English writing are effective without the problematic decompression downsides of this class of LLM use.
Regardless of how much LLMs can be an impactful tool for someone who knows how to use one well, definitely one of the impacts of LLMs on society today is that a lot of people think that they can improve their work by having an LLM edit it, and are very wrong.
(Sometimes, just telling the LLM to be concise can improve the output considerably. But clearly many people using LLMs think the overly verbose style it produces is good.)
Search engines are great at rendering content using JavaScript, they're just not able to explore the Zulip web application's URL structure, so they tend to index one page per Zulip installation.
The current solution is that projects that want their publicly available content to be search engine indexed set up https://github.com/zulip/zulip-archive, which usually involves hooking a GitHub action up to GitHub Pages for a 0-infrastructure deployment. Ultimately, that's the same model as an IRC indexing project like this one: a separate tool from the chat server is responsible for search engine indexing.
Lean runs one here: https://leanprover-community.github.io/archive/, but it looks like it hasn't updated in a year, so likely whoever in the Lean community needs to investigate why it isn't updating.
https://github.com/zulip/zulip/issues/21881 tracks our goal of making the server natively offer search engine indexing. The current separate archive tool model has some advantages (search engine load can't break the server, for example), but I think it'll be worth doing the native version when we can find the resources for it.
Without a clear explanation of methodology, this is meaningless. My guess is this statistic is generated using misleading techniques like classifying "code changes generated by existing bulk/automated refactoring tools" as "AI generated".
I hope the FTC staffs a large office for enforcement on this. There are surely many hundreds of companies in the business of selling fake reviews, many of them outside the US, and I don't expect much change in the consumer reality of "most reviews are fake" without a great deal of investigatory effort tracing money flows to shut these operations down.
Greppability is the reason why I feel it's really quite unfortunate that HTML's dataset attribute went with "canonicalizing" to camel case; if you're using any non-camel-case data attribute names in your project, then they immediately become not fully greppable when making use of `dataset`.
It is kinda amazing how consistently status pages show everything fine during a total outage. It's not that hard to connect a status page to end-to-end monitoring statistics...
From my experience this requires a few steps happen first:
- an incident be declared internally to github
- support / incident team submits a new status page entry (with details on service(s) impact(ed))
- incident is worked on internally
- incident fixed
- page updated
- retro posted
Even aws now seems to have some automation for their various services per region. But it doesn't automatically show issues because it could be at the customer level or subset of customers, or subset of customers if they are in region foo in AZ bar, on service version zed vs zed - 1. So they chose not to display issues for subsets.
I do agree it would be nice to have logins for the status page and then get detailed metrics based on customerid or userid. Someone start a company to compete with statuspage.
Once in the past I did actually have an incident where the site went down so hard that the tool that we used to update the status page didn't work. We did move it to a totally external and independent service after that. The first service we used was more flaky than our actual site was, so it kept showing the site down when it wasn't. So then we moved to another one, etc. Job security. :)
They say you shouldn't host status pages on the same infrastructure that it is monitoring, but in a way that makes it much more accurate and responsive in outages!
Society is within its rights to demand that financial institutions both (1) protect their customers' sensitive personal information and (2) fight money laundering, which AFAIK is impractical without KYC rules at institutions like Coinbase that connect crypto to the traditional monetary system.