Live data from Hacker News

Zulip 3.0: Threaded Open Source Team Chat

blog.zulip.com

111–120 of 134 posts

Re: Zulip 3.0: Threaded Open Source Team Chat

#111
post #106
post #48

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.

Often it has nothing to do with maliciousness or data aggregation, it's a matter of principle: not supporting proprietary software.

Re: Zulip 3.0: Threaded Open Source Team Chat

#113

Earlier 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…

Oh yeah, it absolutely has a long way to go before it's approachable for even the average power user. But I'm hopeful that with enough traction we will get to a better point than either libpurple (pidgin) or bitlbee before long.

Re: Zulip 3.0: Threaded Open Source Team Chat

#114
post #68

Earlier 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…

weechat-matrix works impressively well. the guy who wrote it now works on core Matrix stuff for Element :)

Re: Zulip 3.0: Threaded Open Source Team Chat

#115

Earlier 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

as far as I can tell those links are both to the same product, is that not the case?

Re: Zulip 3.0: Threaded Open Source Team Chat

#116

Earlier 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?

Yes, parent was asking what product I meant when I mentioned "Google Chat" since they have so many chat products.

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

#117
post #106
post #48

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.

I sympathize with those who object to proprietary JS, but in my case I'm mostly annoyed at having to run code just to read static content - quite heavy code, too. When I have a lot of discourse.julialang.org pages open, my browser noticeably chugs.

Re: Zulip 3.0: Threaded Open Source Team Chat

#119

Seeing 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.

The master issue for that project is https://github.com/zulip/zulip/issues/13172. It's being worked on and is considered a high priority.

There's also an archive tool at https://github.com/zulip/zulip-archive.

Re: Zulip 3.0: Threaded Open Source Team Chat

#120

Earlier 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...

That's not the issue - the issue is uploading crates to crates.io not using crates published by others.
Post reply on HN