
Element wins deal to supply half a million licences to two German states - neiljohnson
https://sifted.eu/articles/element-germany-deal/
======
yogthos
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.

~~~
devwastaken
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.

~~~
yogthos
This is completely tangential to using open communication protocols.

~~~
devwastaken
Open communication protocols currently have no goal of ip protection, and by
design cannot unless it's centralized.

~~~
yogthos
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.

------
jeremiahlee
Digital sovereignty is becoming differentiating. Open source, on servers you
control, end-to-end encryption by default. This is how European SaaS can win.

~~~
znpy
> on servers you control

> SaaS

that's not really a saas though.

a managed services offering maybe, but that would be a differend type of
business.

~~~
neiljohnson
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.

------
hnarn
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].

[1]:
[https://news.ycombinator.com/item?id=23842974](https://news.ycombinator.com/item?id=23842974)

[2]: [https://element.io/blog/the-world-is-
changing/](https://element.io/blog/the-world-is-changing/)

~~~
taneq
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”.

~~~
carstenhag
Different area of business (games vs chat program). But I see your point, all
companies you mentioned have a messenger with mobile apps (AFAIK).

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

~~~
nolok
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.

~~~
rhn_mk1
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.

~~~
tabbott
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](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](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 :)

-Zulip lead developer

~~~
rhn_mk1
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!

~~~
tabbott
> 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](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 :).

------
doener
Element's chat is part of the Matrix ecosytem used also by German federal
agencies and Bundeswehr: [https://matrix.org/](https://matrix.org/)

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

~~~
vlmutolo
It’s not like E2EE is required for Matrix (or Element). It’s just on my
default, which is great.

~~~
brunoqc
Also, it's only on by default for 1-on-1 conversations.

~~~
neiljohnson
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.

------
tannhaeuser
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).

~~~
iicc
[https://www.jsxc.org](https://www.jsxc.org) ?

~~~
tannhaeuser
_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?

------
sandGorgon
does Element/Riot have private rooms/org-level permissions ?

if i want to move my company from slack to element - can i have permissions at
the company level (all rooms in a company) and on a per room level ?

~~~
neiljohnson
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.

~~~
Arathorn
[https://github.com/matrix-org/matrix-
doc/blob/matthew/msc177...](https://github.com/matrix-org/matrix-
doc/blob/matthew/msc1772/proposals/1772-groups-as-rooms.md) is the plan for
revamped communities, ftr

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

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

~~~
rob74
Thanks for the clarification! Just wanted to ask about this and noticed that
my question is already answered.

So that's a combined population of ~4,8 million, which is only about 5,7 % of
Germany's total of ~ 83 million...

~~~
cxcorp
To be fair, that's practically the population of Ireland.

------
gadders
I thought Element was Discord, not Slack?

~~~
k__
I thought Discord was an alternative to Slack and Element/Riot was an
alternative to WhatsApp.

~~~
smichel17
My opinion/analysis:

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.

~~~
ryukafalz
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/](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.)

