This is a huge win for open chat protocols, and we really need an open protocol for chat communication to become a standard. The fact that most of the popular chat platforms are proprietary is a travesty. It’s especially painful nowadays where a lot of chat apps are implemented using Electron making them rather hefty in terms of resource usage. Having to run both Slack and Discord for example is pretty taxing. This problem wouldn’t exist using open protocols.
I'm old enough to remember the days when you could use a single client to communicate over many networks. Proprietary protocols are the reason that's not possible anymore, and I sincerely hope that every single company peddling them goes out of business.
Discord exists because people are killed, stalked, and otherwise harassed from IP exposure. That's its 'be safe' purpose.
It's not simply a chat service. You also have proxied video calls and VoIP. That in itself is far more expensive and resource heavy than decentralized hosters can do at scale.
It's not about proprietary protocols, it's that we already had decentralized solutions that cant protect it's users. Centralization is a requirement at that point if you want it to be popular and scale.
Once again, it's a completely separate issue. You can have a centralized service that also uses an open protocol that people can make custom clients for. Furthermore, people use stuff like Tor for anonymity with decentralized systems. Trusting a central system to keep your information private is a risk of itself.
Digital sovereignty is becoming differentiating. Open source, on servers you control, end-to-end encryption by default. This is how European SaaS can win.
One supports the other. Running high profile on premise solutions helps support the Matrix eco-system as a whole, especially if the installation federates.
The SaaS offering means that smaller organisations can also get come onboard without going to extra expense of a large scale self hosted installation.
Looks like things are driving towards a kind of "cloud escrow" or shared-management model. You grant a managed-serivces/saas company access to your cloud account to spin up resources. They do the day-to-day management, but you could bring it in-house or go to another firm at any time if they are no longer a good partner. In practice you get a SaaS product. But you actually have the assets of self-hosting.
For anyone interested in why it was renamed from Riot, znpy posted a comment under a now heavily downvoted comment below[1] that links to an explanation blog post[2].
Honestly I think “riot” is pretty recognisable as a software company and it’s fair that they defend their brand against another software company. You wouldn’t expect to be able to trademark “epic.im” or “blizzard.im”.
Without threads, I can't advocate the use of Element yet to the communities that want to leave Slack (usually they use free Slack, then grow, then get stuck with a chat software with no history because it's too expensive to go premium).
Mattermost has no threads either. RocketChat just implemented them in v3.4. Zulip has its own concept of threads, but Zulip frightens non-dev users in my experience.
Zulip needs a couple UI/UX designer to work on it and get a facelift into the "cutesy and smiley interfaces" era. It's great, and it's the only one that's actually free to self host with all features.
Zulip definitely needs more UX design work. I also wouldn't call it great either. Perhaps in comparison to the competition it would be, but it's awful compared to native chat applications.
Invisible scroll bars keep making me miss new messages just because indicators were out of the viewport. Having the browser stall routinely causes full reloads (after a delay, making it more annoying), then the reload is invarialy interrupted by the server due to request overload. Not to mention that the reload is slow already. Long messages show up collapsed, and uncollapsing them often devours whatever text was in the input field, an especially useful feature when trying to write a thoughtful reply cross-referencing multiple posts. Email notifications send out the same message multiple times, and presents author's name the same way as the rest of the text. Constant hitting on the CPU. Confusing notion of threads and forums. I could go on - Zulip is not nice.
I'd be curious to hear more about these concerns, because they're largely not things others have reported. Would you be up for dropping by chat.zulip.org to provide more detail? A few initial thoughts:
* Notification emails for PMs don't include the sender in the body at all. Those that do have the sender bolded on a line by itself. So I am not sure what you're referring to here. Maybe you're using a self-hosted server running an old version? We did a total redesign of missed-message emails in 2019.
* When closing the compose area, Zulip saves message content in the "drafts" feature, so one never loses partially composed work: https://zulipchat.com/help/view-and-edit-your-message-drafts.
* I was able to reproduce the uncollapsing bug as https://github.com/zulip/zulip/issues/15808, and fixed it a couple minutes later. Thanks for the report!
* The issues around CPU load, reloading and server issues are probably best discussed interactively, since I'd like to see browser profiles for your situation and understand if you're using a self-hosted server that might be underprovisioned, which seems a bit much to work out on a HN thread :)
Thanks for replying! I didn't expect the lead dev to actually reply. I will certainly drop by when I find enough time.
- yes, this is self-hosted. I can't check the version, but I think it was recently updated
- notification emails in non-html mode don't carry over the bold, not even in the form of asterisks, so it all blends in with multiple messages
- the "drafts" feature took me a year to discover. Sadly, messages were recomposed. I think it's useful when the composing is interrupted due to external reasons, but not something to work around user action causing clears
- thanks for fixing the collapsing bug, I'll see how my opinion on the composing workflow changes
- CPU load is not that bad, but still way worse than my IRC client or a non-JS forum, so
- I may be somewhat unique in that I automatically `kill -STOP` and `kill -CONT` the browser when not using it, sometimes keeping it frozen for days at a time. That is causing the server issues. Notably, I haven't yet seen any other software or pages having problems with that.
One thing I always respect is the desire to keep improving! Kudos!
> yes, this is self-hosted. I can't check the version, but I think it was recently updated
Well, 3.0 comes out tomorrow (hopefully) so your administrators may want to upgrade once it does :).
> the "drafts" feature took me a year to discover. Sadly, messages were recomposed
Yes, we're planning to add an onboarding notice the first time a draft is saved to avoid this failure mode :).
> notification emails in non-html mode don't carry over the bold, not even in the form of asterisks, so it all blends in with multiple messages
Oh, interesting. Non-HTML emails are hard to do much good with; if you have specific ideas for what we could change to make that better, let us know: https://github.com/zulip/zulip/issues/new
- thanks for fixing the collapsing bug, I'll see how my opinion on the composing workflow changes
Happy to! We generally fix any easy bug as soon as it's reported as a general practice, since users can really tell how buggy a product is, so hopefully this will encourage you to report more :).
Yeah but if you want truly self hosted AND full feature set (notably search and archives) AND owning your data, there isn't much available putting Zulip far on top.
IRC could do it, but IRC never got a clean and prettified client that bob from accounting knows how to use properly, and finding the proper server software sucks.
Fwiw self hosting Element and a Matrix homeserver like Synapse provides a full Matrix feature set (including search, archiving and everything else). You don't lose out for self hosting.
What Zulip needs most isn't UX but a sane installation, upgrades and management.
It's software with many moving parts, it uses PostgreSQL, Redis, memcached (!) and RabbitMQ (!!). That's at least two more than you'd expect. All these have completely different cluster architectures. Point in time backups isn't trivial either. This makes things like HIPAA requirements harder to implement.
The official way to install it is to run a sprawling Puppet manifest, which is dependent on a number of other tools to do the work. How do I store this in an existing configuration management system? How do I connect to existing databases? Those DBAs were hired for a reason. The documentation on that is less than ideal.
You'd better run in on the recommended Ubuntu version, any deviations will cause the above procedure to explode into a ball of mud.
There is a Docker image, but it's not stable yet, and upgrades become a bit unclear. It would also mean running all those databases inside a K8s cluster, again with their own ways of doing clusters, backup and maintenance.
The kind of organizations which needs to run things on-prem, and will glady pay for the privilege, are also the kind of organizations which have streamlined processes, sysadmins and DBAs and there Zulip isn't a great fit. It seems to be decent software otherwise with some great and unique features.
We only store transient cache-type state in memcached/redis/rabbitmq, but they have similar configuration options.
> How do I store this in an existing configuration management system?
Our intent is that you configure /etc/zulip using your configuration management system and then use the Zulip installer to install the Zulip software (and it'll configure the services you've configured it to manage accordingly). Our puppet rules are intentionally written to allow only running the application frontend role on a system (as we do in our own production systems).
> You'd better run in on the recommended Ubuntu version, any deviations will cause the above procedure to explode into a ball of mud.
We support all Debian releases and Ubuntu LTS releases in production (which are the only ones worth supporting given that their-non LTS releases are only supported by Ubuntu itself for a few months and thus are structurally long-lived betas). And we're working on CentOS/RHEL support.
I'd love to collaborate on how we can improve Zulip's documentation around your use case. Would you be up for stopping by chat.zulip.org to discuss specific changes?
The backstory here is that I pitched Zulip for an organization which I suspect would be an ideal customer fit. They told me later they had evaluated it but since it wasn't operationally sound, they didn't take it further. Being surprised by this I spend a number of hours on my own with the product, so I did not write the above lightly.
The installation example is just an example. If script doesn't run or doesn't do what you want, it doesn't help. Perhaps the basic problem here is that you are expected to run a script to set up a complex system, with a number of dependencies on the platform repos, where you'd expect to just unpack a tarball and modify an example config to get running.
This is not completely unheard of, it used to be common with proprietary unices, but most were just a basic shar script whereas this is a series chained scripts where if the version of Puppet on your platform isn't what the script expect it's really hard to even get started. And, no, Debian is (sadly) not as big with enterprises as Red Hat and SuSE is. It might however be a mistake to tie software to a specific Linux distribution at all. Those are moving targets and work is probably better spent on other things.
I could elaborate further on software procurement if this anecdoctal evidence is of any use. Generally, there are boxes to be ticked, and things like four interlocking databases and a dump script in cron makes it hard for a DBA to answer if point in time recovery will be possible.
There is an existing discussion to add threading to Element: https://github.com/vector-im/riot-web/issues/2349. To sum up, the backend already somewhat supports it by tagging a message with a `thread_id`. Then the UI can group messages by their `thread_id`s.
I'm curious about the priorization of this feature. In my personal experience (7 slack groups), the majority of the channels use threads. It's a very important feature to avoid drowning people in a stream of messages irrelevant to them.
I may be mistaken, but it doesn't look hard to add it to the UI if the back already supports it. Is the feature planned for a precise date ? Does the Element team lack money ? Can we pay for this feature, instead of paying Slack e.g. 30 000€/year ? Is the lack of developers the problem ?
Suggestion: offer multiple threads in the same window at once, since slack only offers 1 thread view at a time. IE where slack offers 1 sidebar for threads in 1 column, offer up to 6 threads in a window via 2 columns and up to 3 threads per column.
What it look busy when fully used? Yes, but sometimes when you are working in an Enterprise environment, you need to follow something across multiple rooms or channels and this would save users a lot of clicking back and forth.
while I'm sure there are oodles of feature requests already going, this would be one that would offer a genuine feature that slack does not.
The ability to open a separate tab or window for each thread is what I'd like. Really anything would be an improvement over a single, fixed-width column for a thread.
Ngl I view this as a straight up feature—anything intransient enough to go in a thread should go to a more persistent area like a forum. Otherwise it gets lost in slack and is extremely difficult to find later. Slack anxiety sucks; email and forums are highly searchable and linkable and there’s no shortage of cheap, open-source software providing this AND they don’t have built-in corporate incentives driving engagement in a chat platform like it’s a good thing in itself (hence why the notification and “unread count” settings are trash).
Like how do you store a thread to find it later—loudly announce the subject in as much detail as possible with a “SUBJECT:” index prefix? Deep link to put in your wiki and hope slack actually honors those links in a year? Is slack search usable yet?
Slack threads are the typical example of a feature that is added, raises a lot of noise from the (usually techie) vocal minority and then it is assumed as a fundamental feature by everybody else, like in "why didn't we think about this before?".
I still don't like Slack threads. Too many conversations in Slack turn into threads, removing the conversation from visibility without additional clicking, and fragmenting the flow of information. Real conversations rarely work this way. It's like being in a meeting where every time a new topic comes up, half the people leave the room to start a new meeting, and then come back when the topic changes again. If a topic truly requires enough time and space for that, then by all means take it to another channel or a group chat. Otherwise, keep it in the main space. It breaks the flow and invites premature fragmentation, and the UX is bad.
this. especially jailing threads into a tiny sidebar, with the bad "read status" handling going all over the place when that sidebar happens to be open.
Slack threads suck. Just keep everything in one big thread, break out disposable channels when you need them, and build proper archiving features for those. Linking to an existing channel is already there so that shouldn't be a problem.
I think a simple solution to my primary gripe about threads would be to keep them all inline, and just indent them, ala HN comments, so people can ignore (or perhaps toggle on/off, with a setting to default that state) the threads. But I still believe Slack would be better without threads.
Mattermost actually has threads, but their UI is a little bit more clunky than Slack. All the messages show up in the "main thread" like nornal but once you click on one of the threaded messages, you only see the messages of that thread.
In my opinion that's less clunky than Slack because it gives you a good overview of what conversations are taking place in a channel, instead of scrolling up and seeing a 100 reply thread you missed. It's also how Flowdock does it, which has some of the best threading I've experienced in chat software.
I agree in principle that it's nice to be able to see the full conversations without clicking into a bunch of threads, but a problem that I have noticed when people use Mattermost is that they either forget or don't notice that people are using the thread feature and simply reply directly in the channel to an active thread. This makes it so that anyone who isn't looking at the channel loses track of the conversation. You could fix this by repeatedly telling anyone who does it wrong to do it right, but people simply can't make that mistake when the threads are collapsed by default.
As things are now, the thread feature in Mattermost doesn't really help that much, because if you want to be really sure not to miss part of a conversation you need to keep a separate window with that channel open anyway instead of just having the thread open in the same window.
Mattermost PM here, thank you for the feedback! We are exploring the ability for users to choose if they want to collapse threads.
We’re very excited about it and are currently testing prototypes with the Mattermost community and some customers, with development starting soon after.
This is the same way as pioneered by Flowdock ten years ago or so, right? I think that approach is way way better than what Slack has. I remember eagerly waiting for Slack to implement threading and the being dismayed how crippled design they chose.
Using a chat software for keeping history is the wrong use case. I've had to add some minor chat functionality to one of my side projects and honestly the only benefit of a chat history is that when you join a server/channel you get to see the last 20 min of the conversation instead of an empty screen. I automatically delete chat messages older than one hour. Different use cases might need completely different limits but it doesn't change the fact that you should pick a cut off point beyond which you start deleting messages.
Hilariously, we have the need for the opposite... SEC requires record keeping of written communication. HIPAA covered industries face a similar plight. There is no great chat solution for this... RocketChat is a mess, it used mongodb as a backend and the server side requires roughly 512mb of RAM per user. Mattermost is not much better, it also uses a terrible database choice and has similar scalability issues, and the license is a minefield. Both have major usability issues. Both crash a lot.
I do appreciate E2E encryption for some narrow use cases, but it is not the end-all-be-all.
It’s on by default for 1:1s _and_ private rooms. Though nothing in the protocol demands an encrypted room so unencrypted 1:1s, say, are entirely possible.
I would think that ideally you would want E2E encryption that was on by default for everything. Then rather than turn it off, you would also want the ability to configure a server to effectively MITM everything (and the client to cooperate in this, and notify the user about it).
Such an arrangement is more or less what happens with key escrow, a feature which I believe at least one self hosted cloud stack offers (sorry I can't remember its name off the top of my head).
Slightly o/t but would anyone know an XMPP browser client? The focus here wouldn't be so much E2E encryption/OMEMO but having a persistent chat. Like in a simple traditional chat log (with the option to create new "elements", of course).
Exactly what I had in mind, thanks. Could've found that myself really, but I'd thought I ask; maybe there are alternatives, or experiences to share with jsxc?
Many organisations have made this switch (and of course we use Element at Element for running the org).
We do have support for org wide management in the form of the Communities feature, but we want to completely revamp it to make exactly what you are describing easier. It is the next big thing on the roadmap and I would expect it land in the next few months.
Must admit, when setting up our company server I didn't even consider allowing it to federate as it just looked a bit to complicated, making it easy to get wrong and potentially have confidential information leak.
You can set up a non federated matrix server where you can then control who gets access to what via invites to rooms and communities. So, you can kinda do it, altough it is probably not the best service for a 1:1 translation of a slack setup.
But if you are willing to somewhat alter it, I am sure it'd end up with a overall better setup.
While we're talking about it what's everybody's favorite Matrix chat rooms to hang out in? Are there any unofficial HN discussion rooms? I run a room here for anyone interested in regional / community run Internet Service projects: #startyourownisp:matrix.org and sometimes hang around in the Riot (now Element) and Matrix chatrooms just to see what's happening there.
Regarding the headline, there isn't "the" German education system, it's 16 different systems, one per state. The German constitution puts education as responsibility of the states. In specific, the contract is for the two bordering German states of Schleswig-Holstein and Hamburg.
Element (formerly Riot), Discord, and Slack are all irc successors; Signal, Whatsapp, and Snapchat are sms/mms successors.
The differences used to be desktop vs mobile, primarily [semi]public group/community chats vs primarily private 1:1, and realtime with presence vs async. As technology has advanced, the differences have shrunk. I'd say the last real remaining difference is that the irc successors have named channels with granular permissions and static invite links, while the texting apps might have a group owner but otherwise give everyone full permissions, and people are usually added directly to the group (not invited).
In short: the texting replacements are geared towards communication with friends (ie, based on who you're talking to), while the irc replacements are geared towards communication, possibly with strangers, based on what you're talking about.
To throw another wrench into this: here’s another Matrix client, compatible with the same accounts you’d use in Element, with a UX more like what you’d expect from SMS/WhatsApp/etc: https://dittochat.org/
When it comes to open protocols, I think it’s a bit silly to say they’re “for” anything in particular; the protocol constrains their uses somewhat, but you can do whatever you want with them. I myself use Matrix for all of the above.
(Also, I suspect if you added chat bubbles and invite auto-acceptance to Element you’d have people arguing that of course it’s meant for small group communication! UX seems to shape expectations about these things.)
I wouldn't even call Discord/Slack/WhatsApp discrete categories of software anyway. They're all way more similar than they are different. So another entrant in the field doesn't need to be a X competitor vs a Y competitor; it can just be another messaging app that has a blend of functionalities available in other messaging apps.
I'm old enough to remember the days when you could use a single client to communicate over many networks. Proprietary protocols are the reason that's not possible anymore, and I sincerely hope that every single company peddling them goes out of business.