Earlier quoted context omitted.
That's excellent news. Being locked out of the community by virtue of it being hosted on a proprietary service, requiring a proprietary code blob to access, was one of the biggest sour notes I had coming to Julia. (Now if only discourse.julialang.org links would render without Javascript!)
I don't quite get this concern about proprietary JS. I agree JS can be malicious, but it has nothing to do with license. Or you can say you don't want to give your data to Slack.
Zulip 3.0: Threaded Open Source Team Chat
111–120 of 134 posts
Re: Zulip 3.0: Threaded Open Source Team Chat
#112Re: Zulip 3.0: Threaded Open Source Team Chat
#113Earlier quoted context omitted.
> Matrix is an attempt, but by no means a solution. Care to elaborate why you think so? (Obviously it's not there yet , but does anything make you think it won't?)
As it's not there yet, it's not a solution for my requirement. Eventually, maybe. For now, I think using Matrix to bridge to every other service is quite daunting. Consider these instructions which seem to be needed to connect to a Telegram group: https://wiki.calculate-linux.org/matrix_telegram_bridge I'm lucky that I can easily follow those instructions if I want. But to do all that just for 1 group? The next one u…
Re: Zulip 3.0: Threaded Open Source Team Chat
#114Earlier quoted context omitted.
E2E encryption kinda breaks with the model of Zulip, ie a company or a project where everything should be visible by everyone even if they arrive after the conversation has started. You'll probably be better served by hosting your own instance and trusting everyone who connects to it.
That is another thing, it would be even better if we could control E2E encryption per room. Since we do everything in the open, instead of needing something like XMPP for private conversations, and IRC for public conversations, we could simply have private rooms with E2E encryption for the team, and public rooms for everyone else. I wish IRC had E2E encryption. In the end, I think we might stay with XMPP with OMEMO f…
Re: Zulip 3.0: Threaded Open Source Team Chat
#115Earlier quoted context omitted.
Google chat is completely unthreaded as far as I can tell. Unless you mean Google Groups?
The other other Google chat https://gsuite.google.com/products/chat/ http://chat.google.com
Re: Zulip 3.0: Threaded Open Source Team Chat
#116Earlier quoted context omitted.
The other other Google chat https://gsuite.google.com/products/chat/ http://chat.google.com
as far as I can tell those links are both to the same product, is that not the case?
I am using Google Chat at work, and it is also threaded. I haven't used Zulip and was asking if it had a similar thread model.
I find the Google Chat thread model convenient and makes sense. But that is more or less the only good thing I can say about this product.
Re: Zulip 3.0: Threaded Open Source Team Chat
#117Earlier quoted context omitted.
That's excellent news. Being locked out of the community by virtue of it being hosted on a proprietary service, requiring a proprietary code blob to access, was one of the biggest sour notes I had coming to Julia. (Now if only discourse.julialang.org links would render without Javascript!)
I don't quite get this concern about proprietary JS. I agree JS can be malicious, but it has nothing to do with license. Or you can say you don't want to give your data to Slack.
Re: Zulip 3.0: Threaded Open Source Team Chat
#118We've been using Zulip for the Ponylang community for about 18 months now. It is by far our favorite tool in the "chat" category. And this release addresses three of our biggest gripes. We highly recommend.
Re: Zulip 3.0: Threaded Open Source Team Chat
#119Seeing as Zulip is growing ever closer to a chat/forum hybrid, I hope you’ll consider making Zulip instances browsable by guests, just like a Gitter or Discourse instance.
There's also an archive tool at https://github.com/zulip/zulip-archive.
Re: Zulip 3.0: Threaded Open Source Team Chat
#120Earlier quoted context omitted.
Remind me of Rust with the added bonus of requiring a GitHub account to upload crates.
You can add crates from other registries or git urls. https://doc.rust-lang.org/cargo/reference/specifying-depende...