zulip-mobile VS Zulip

And a basic feature for the iOS client hasn’t been implemented in 6 years https://github.com/zulip/zulip-mobile/issues/438

But they haven’t managed to fix a rather basic feature in their iOS client in nearly 6 years now: https://github.com/zulip/zulip-mobile/issues/438

Zulip (version 27.191): The Zulip mobile app, chat for distributed teams

Federation would make me almost instantly recommend it for a handful of cases, but in the meantime they have a lot of catching up to do in the privacy department.

Behold, the two five year old tickets requesting that they stop passing notification text to Apple/Google cloud messaging:

https://github.com/zulip/zulip/issues/6954

https://github.com/zulip/zulip-mobile/issues/1190

For those who don't know: if you have an app and want to send a notification to a user, you use Apple or Google push notification services. In both cases, the notification is plaintext but transmitted via encrypted channel to Apple or Google, then transmitted via encrypted channel to the user's phone. But in each case, the push messaging provider gets to see the messaging text.

So companies that give a shit about your privacy send a token instead, that says "hey, wake up, something happened, fetch a notification." Apple likely doesn't do anything with the notification text, but it's a given Google datamines the hell out of it.

They also still don't have any form of e2ee. Here's another five year old ticket requesting end to end encrypted chat, where a bunch of people say "here's a long list of apps that support e2ee" and Zulip devs go "gosh golly how do they handle keys? Math is hard."

https://github.com/zulip/zulip/issues/6096

Indeed. It's been mentioned in the relevant issue: https://github.com/zulip/zulip-mobile/issues/3838

Zulip (version 169): The world’s most productive group chat

We've had similar problems with keeping Zulip in the Apple app store. It's incredibly unpleasant to deal with this aspect of publishing an open source application.

For context, Zulip is a 100% open-source team chat project (in the same space as Slack/IRC/etc.). You can self-host Zulip, which we've put a lot of effort into making easy, or host it on Zulip Cloud (with both free and paid plans). There's no individual subscription option for the product at all -- just like with Slack -- so the app store policies to enforce their monopoly by requiring all individual purchases be taxed by Google/Apple shouldn't even apply to us.

But we've still had multiple rounds of rejections caused by aggressive enforcement of these policies:

* A couple years ago, Apple reviewers repeatedly rejected updates to the app because the privacy policy / terms of service pages linked from the app contained the zulip.com website footer, which in turn link to the pricing page for Zulip's paid offerings. This means our Privacy Policy could be a way to get people to buy something without paying the Apple tax! We "resolved" this, on the advice of their appeals expert, by passing a special parameter when loading these pages from the ToS/Privacy links in the mobile apps that hides the header/footer sections of the page :(.

* In May, Apple reviewers repeatedly rejected the Zulip mobile app for linking to its own source on GitHub. At first we thought the problem was that we had recently set up GitHub Sponsors [1]. Further correspondence determined that the problem was even more ridiculous: Any GitHub page has a tiny link in the https://github.com/zulip/zulip-mobile footer for GitHub's own pricing! We were able to convince them to approve it in the end, but we were close to giving up and removing the GitHub links. I'm still upset about the whole experience because it was a huge waste of energy.

It's not clear to me whether these rejections are what Apple's policies intended or just the policies being incorrectly applied. But it doesn't really matter: these appeal processes are opaque and scary and mostly consist of them repeating what you need to change with minimal explanation. If not for the entrenched monopoly, we'd be looking to switch to another vendor that wasn't so sloppy about something that's very important to us. I think the harm caused by sloppiness on the part of monopolies doesn't get enough attention.

[1] This would have been wrong too, though I do know some companies use a Patreon as the way to sell their product, and I can imagine that being a workaround that Apple would be on the lookout for. But it's easy to check that we're definitely not playing that game.

Zulip — Real-time chat with a unique email-like threading model. The free plan includes 10,000 messages of search history and File storage up to 5 GB. also, it provides a self-hostable open-source version.

(1) Zulip Chat - https://zulip.com/ - seems to be reasonably popular, but more people should know about it

I’ve been using it for over 5 years now [1], and it’s as good as ever. It’s way faster than any other chat app I’ve used. It has a good UI and conversation model. It has a simple and functional API that lets me curl threads and write blog posts based on them.

(only problem is that I Ctrl-+ in my browser to make the font bigger – I think it’s too dense for most people)

(2) re2c regex to state machine compiler - https://re2c.org

A gem from the 90’s, which people have done a great job maintaining and improving (getting Go and Rust target support in the last few years). I started using it in 2016, and used for a new program a few months ago. I came to the conclusion that it should have been built into C, because C has shitty string processing – and Ken Thompson both invented C AND brought regular languages to computing !!

In comparison, treesitter lexers are very low level, fiddly, and error prone. I recently saw dozens of ad hoc fixes to the tree-sitter-bash lexer, which is unsurprising if you look at the structure of the code (manually crawling through backslashes and braces in C).

https://github.com/tree-sitter/tree-sitter-bash/blob/master/...

These fixes are definitely appreciated, but I think it indicates a problem with the model itself.

(based on https://lobste.rs/s/endspx/software_you_are_thankful_for#c_y...)

[1] https://www.oilshell.org/blog/2018/04/26.html

A few more truly in the vibe of open source projects not advertising their hosting providers: https://plane.so/ , https://element.io/ , https://www.loomio.com/ , https://zulip.com/ , and it keeps going... Very few open source projects, in the FOSS sense, are advertising their hosting provider.

I was so excited to see this happen!

I'm not a customer of yours, but your blog posts inspired me a lot. Your journey through quitting caffeine is a great and heartening read.

I've got two things to say;

1) Will you consider source-availabling the web portal (app.keygen.sh) too? Some enterprises could use it for easy management/support for custoner's licenses. Although now that I think about it, it could also discourage custom, more suitable implementations for each use-case... I'm torn on this one. I would like to see it available on GitHub too just out of curiosity too. It's very beautiful.

2) For a team + customers' chat, I cannot recommend Zulip enough. It's a joy to use and has the most innovative chat system I've ever seen. https://zulip.com

I hope your business keeps prospering!

Zulip | Senior Flutter Engineer | REMOTE or San Francisco | Full-time | https://zulip.com/

At Zulip, we’re out to build the world’s best collaboration platform, and we’re committed to keeping it 100% open source. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations. Our product serves as the communication hub for businesses, open-source projects, educators and communities around the world.

We're building the next generation of Zulip's mobile apps in Flutter. We're looking for a senior engineer with Flutter experience to join our small core team and help define the future of team chat. Our Flutter prototype is just a few months old, so this is a greenfield opportunity to help shape the app's architecture from early on.

For full details, check out https://zulip.com/jobs/. Apply at [email protected].

Anyways, I'm an internet stranger, not a social media expert. So let me know what you all think. And if we make a discord or zulip or something to make this a reality, let me know and I'd love to help any way I can.