Element (Matrix) launches Chatterbox, end-to-end encrypted embedded chat | Hacker News Reader

Element (Matrix) launches Chatterbox, end-to-end encrypted embedded chat

element.io

244 pointswatsonkr90 comments

While I like the idea, I feel the that this announce is wrong.

First the pricing is outrageously high.

Second, why not provide a link to try it? And screenshots to see how it looks from an agent's point of view. Because Most embedded chat widgets come with advanced customer support features, and Element applications are not designed for that.

Don't tell, show!

Edit: Github link at [3], couldn't find it when I originally wrote my comment below

I wonder how this compares to alternatives like [1] and [2] that you can also host yourself.

There was also a Matrix project *that I can't find for the life of me) featuring multi-agent live chat support with multiple agents being able to join and leave a room. I suppose the E2EE support is what sets it apart, though I'm not sure if that's actually a feature you really need.

Half the features advertised seem to be existing EMS features (like talking across chat services). I suppose you can use this to portal a web chat box into Slack but honestly I think there are better solutions.

[1]: https://github.com/osousa/livematrix

[2]: https://github.com/nomadic-labs/safesupport-chatbox

[3]: https://github.com/vector-im/chatterbox

You can host chatterbox yourself too - it’s apache licensed FOSS (https://github.com/vector-im/chatterbox).

Oh, I see! I was looking under the matrix-org Github account so I couldn't find the source code, I probably should've looked at the vector-im tag as well.

The former doesn't have encryption, but good question

Hi there.

I wrote [1] (Thanks for the reference) , and i skipped encryption for the sake of simplicity.

I'm enabling encryption as we speak.

If you host the server yourself, on a controlled setting (VPS), it should allow for a fairly secure way of communication if TLS is used. The communication channel would resemble this rough ASCII drawing:

[Browser] <---TLS---> [livematrix] <---e2ee---> [Matrix homeserver]

In the end you always have to trust the person hosting the service. Host things yourself.

I don't see this channel of communication as being truly secure, without audits where and how its deployed. Web apps are riddled with vulnerabilities, how much of the attack surface from a website would compromise the live chat embedded is a guess until it happens.

I should point out that my "solution" is intended for personal websites, people who enjoy Matrix a lot :) . Not for corporations at all.

TLS for browser communication should work great; if the website can't control its scripts, then there's no reason to trust its execution anyway. The main problem space, in my opinion, is encryption support between your service and the Matrix server, as messages get stored long-term in that space, which comes with possible privacy risks. Your solution would probably mitigate that problem perfectly!

What is the benefit of end to end encryption in this scenario?

There is no risk of service provider spying on you because you as the business is the service provider.

This is part of a hosted package. In theory, this means that the folks over at Element.io can't see the chats between you and your customers/business partners because of the E2EE. That does depend on them not hosting the software, of course, because E2EE becomes useless if the software used to encrypt data can be changed at a whim.

With the private keys on the recipient end and the browser end, it does make it easier to follow certain data privacy regulations. Whether the rather leaky Matrix protocol is considered foolproof is still an unanswered question, though; the average encrypted chat session sends a LOT of unique identifiers that shouldn't cause any trouble, but I haven't seen a recent audit of the protocol.

Hmm, I'd say it depends.

Imagine you're contacting a doctor and are communicating about sensitive stuff. I'd still expect this to been treated relatively confidential, i.e. not spreading it within the company, or potentially leaking it.

Plus, the matrix server of the person on the other side might not be in your hands, e.g. hosted by Element

E2EE can prevent the leaking of private conversations to thirdparty middleware/cloud companies. This would allow orgs to continue using those thirdparty services to handle their traffic like usual, but would also guard against middleware disasters like cloudflair's leaking of https traffic.

Thanks to the prevalence of early HTTPS termination (usually at the edge of some big cloud company), that green pad lock at the top of your browser means little when true privacy is needed.

In addition to points from others: no middleman can tamper with the information being sent (e.g: see how Russia changes content of pages served via http to display war propaganda or ads).

How did that work with HTTPS?

> What is the benefit of end to end encryption in this scenario?

Let's say I'm talking to my bank. Is there really any information that you want open? They're going to ask you security questions to confirm your identity. You're likely talking about specific sums of money.

Let's say you're talking to your doctor. Is there really any information that you want open? Are you violating HIPPA and privacy laws just by talking? Your health is of no concern to anyone but you and your health provider. Full stop.

I mean, they use these two examples in the post. The use case is pretty clear to me here. The risk isn't your service provider spying on you, it is anyone that you aren't intending to talk to. A hacker (who may be interested in your bank or health care). A state actor. Abusive ex. Data companies that extract every bit of information they can. Or politicians who want to track your period. Maybe this isn't useful when I'm submitting tickets to wandb, but I can see this being very helpful when I'm talking to my bank.

How does E2EE work here? How can the user know their communication isn't being intercepted?

It’s using normal Matrix olm/megolm double ratchet encryption.

To track the identity of who you’re talking to we can do TOFU and/or normal out of band Matrix verification as per https://github.com/vector-im/hydrogen-web/issues/518 - but this isn’t yet exposed in Chatterbox. We’ll get it added, as without verification you obviously can’t spot a MITM.

How does the user check that, if they are running untrusted clients embedded on untrusted sites? Who is the adversary that the addition of end-to-end encryption is supposed to defeat?

If the business doesn't want to host the chat server themselves, they can have a 3rd party provider host it (like Matrix.org) without worrying about the 3rd party having access to the messages

Edit: sorry I should have clarified that I was answering your second question. As for the first question, the user still has to trust the business to a certain extent

But they host the software, you already have to trust them.

This threat model just does not make sense.

The software = chat box? Could be hosted by yourself, too

The user has to trust the business no matter what. Even if the chat was e2e encrypted, the business could just choose to share the messages with somebody else.

This use case is more for the business, who knows that the chat is hosted by a 3rd party, but is reassured that the 3rd party wont have access to messages.

The point is that the host can modify the code at will and can therefore access the messages if they wanted to. It defeats the idea of e2ee which is to make it impossible for a middleman to access the messages.

With e2ee you have to trust the client. But a client that is running as a website hosted by someone else can't be trusted as the host can modify it and you'd never known because browsers don't have a way to alert you when a site changed.

The only way this makes sense is if you (or your business) self-hosts.

Another option is for the business to host the (open source) chatbox themselves, but the messages are stores and routed through a 3rd party. The chatbox is probably just a plug and play component that can be embedded in any page, and hosted statically by the business. Much easier than self hosting the entire messaging infrastructure.

This is one of the major benefits of having an open protocol like Matrix. The clients are separate from the servers. People with more resources and more expertise can host the servers, while regular users just need to download an open source client, and they can rest assured that the messages are secure.

There are other considerations though aren't there? Assuming that you trust the hosting entity:

* You may not want to trust the hosting entity for all of time. If you trust that E2E is deployed now, then you don't have to trust the future version of the host

* You may want additional protection against the host database being compromised. If you trust that E2E is deployed then a compromise of the host would not mean anything for your users privacy

This is my question, too.

From TFA:

>there’s no need for them to register or create an account just because it’s E2EE, and it still supports persistent messaging.

How does that work? Arathorn in a sibling comment says that there's out of band something, which I interpret to mean some verification process, but for the life of me I can't imagine what that process might be or how it might work without any sort of account... unless the client generates a unique a key per user session and coordinates the key exchange with a single host server behind the scenes to encrypt that session's data?

What am I missing?

Normal users will probably just check that the green padlock in their address bar.

I think this is targeted towards securing chat traffic from thrid-party hosting services accidentally leaking or passively spying on you. Think problems that arise from early HTTPS termination like the cloudflair's https leak.

Incidentally I tried matrix for the first time on the basis of someone recommending it here in HN, and it's extremely slow

this is like saying “i tried the web, and it’s extremely slow”. what server were you using? and which client on which platform?

How about slow compared to Discord?

But this still doesn't answer the question - did you register on the default server that everyone uses (matrix.org)? And in that case, you've given the exact worse case scenario: The heaviest server, being used by everyone else, with massive rooms, and constantly fighting off spam.

Personally, I find that the Matrix.org server is much better for large rooms. Most of the content is already cached on the server by all the other accounts on there, so joining large rooms takes seconds instead of minutes. Modern sync (v3 already, I think?) also helps a huge amount but it needs client and server support.

I've tried to join the main matrix chat room (#matrix:matrix.org) but my poor homeserver just couldn't handle it.

Modern sync (sliding sync, v3 sync) only helps with non-encrypted rooms. For encrypted rooms, it degrades to essentially the old sync v2 performance.

That's true, but most rooms where this is a problem (the huge ones) aren't encrypted. There's no way you're going to cross-verify everyone in a room with 4000 users in it so encryption in such rooms is essentially useless.

Not everyone uses matrix.org. I've run my own server on a $15/mo DO droplet for ages and my whole polycule and friend group use it heavily as well. It's incredibly easy to deploy and maintain for anyone who knows even a little bit about sysadmin.

same. i have yet to bother switching from sqlite to postgres and it's ... fine. it's fine.

Not the person you're replying to but following up on an identical past thread: https://news.ycombinator.com/item?id=30996203

> Linux, x86_64. Getting the same behavior across distros and installations.

It is still very much the case. To emphasize, we have for the past couple of years used Matrix routinely on:

  * Multiple client implementations
  * Multiple OSs (Linux/Android/iOS)
  * Multiple accounts and profiles
  * Multiple Linux distros, desktop environments, window managers, X11/Wayland, CPU architectures (x86_64, aarch64)
  * Private and public homeservers

In particular, multiple accounts on the same Linux installation of element-desktop.

The common denominator seems to be that the account with many (thousands) of rooms (almost all of which fully historical/archived with no ongoing activity apart from participants presence) consistently gets Element freeze, hang, be extremely slow.

This makes element-desktop practically unusable for that account. Other accounts in the exact same environment do not have this issue. Signing in to a fresh profile seems to improve this, for a while, until it starts happening again

The same issue does not appear on Element iOS/Android, or with other accounts on the same client.

It gets more annoying by the fact that even under normal operations it's slow enough to start up that it can take some time to tell if this time it'll eventually resolve by waiting or if it needs to be force-killed and restarted. This is also the case on an otherwise idle 8-core Ryzen3 with 64GB of RAM and fast NVMe drive sitting close to its homeserver on a 1GBps link. (The slowness seems to be all or mostly locally in Element - even when in a mostly empty room, it can take a very long time expanding/collapsing/navigating the People/Rooms sidebar. This, too, only for those particular high-room accounts and only on element-desktop)

For a while we believed it could have been the same cause as this issue[0] but alas, 1.11.0 with Electron 19 has not resolved it.

The common factors that consistently exhibits this behavior seems to be Linux, element-desktop, account with large amount of rooms. Been like this for a while now.

[0]: https://github.com/vector-im/element-web/issues/21147

That is the problem with defining Linux Desktop support as I have said this many times before. It has been more than 20 years and the same fragmentation and inconsistency issues are still here. It is not early days anymore.

It works fine on macOS as mentioned in that thread, especially with 4000 rooms on both Firefox and Chrome and supporting that is simple with a predictable desktop stack. The Linux Desktop however is eternally plagued with these issues and the support and testing is very expensive.

It is a serious and fundamental problem with multiple alternative of alternatives of system components to test and the problem [0] may still happen deeper in the desktop stack and looking for the root cause is like finding a silver needle in the sky and would require a mixture or part time / full time devs to test or debug literally everything that is in the stack to reproduce or actually find it.

The fact that it works fine on macOS and it hasn't been solved on Linux yet, tell us that defining Linux Desktop support and targeting / supporting 100% of Linux Desktop users is an impossibility. It's a very expensive contraption to support, unlike the users on Windows and macOS.

[0] https://news.ycombinator.com/item?id=30983400

For all is warts, electron does make things like this more consistent across distros end environments, as shown in the reproducibility of this issue.

Probably because the app is a bloated piece of junk

A sibling comment [1] says it works fine on Mac and Windows, and it's all the same desktop app. It's likely a Linux quirk that hasn't gotten enough attention yet

[1]: https://news.ycombinator.com/item?id=32021303

There are plenty of apps that run smooth on Linux. If there is a bug, then it almost definitely isn't due to Linux itself. Maybe they could just admit their development efforts aren't actually focused on optimizing for open source.

All Electron apps are slower by orders of magnitude than the native ones by definition. Trying any non-Element client might help.

Could you please suggest one native android client?

Element Desktop shouldn't freeze, hang or be extremely slow on an account with large numbers of large rooms. My personal account is in around 4000 rooms which span around 500K users, and it's completely usable on Element Desktop on macOS on an average intel macbook from ~4 years ago.

So whatever is going wrong here is presumably a Linux-specific bug on Element Desktop, which I'm unaware of, and haven't heard from any of the other linux Element Desktop users. Have you filed an issue with logs to get it on our radar? HN is not our bug tracker...

There are two issues filed already which I think sounds similar enough, and from the referenced it obviously scales:

https://github.com/vector-im/element-web/issues/20431

https://github.com/vector-im/element-web/issues/20143

I think the reason you don't see log reports here is that a condition for this to be problematic is large number of rooms/DMs. We could audit/edit the logs and submit them manually (and perhaps I'll get around to that). I also suspect high-intensity users are more likely to disable telemetry.

Just putting out a possible explanation why this issue may be more prominent than can be gathered from analytics. You do seem to recognize the common complaints of slowness (the dismissal of which prompted me to follow up in the first place), and there is at least one GitHub issue open by prominent community members since ~6 months.

It's literally impossible to tell whether the two issues you've linked are the same as the one you're complaining about unless you submit logs and your own bug so we can triage to see why your client is slow.

Hey, I'm not expecting you or anyone else to spend time or resources on this. These threads were all prompted as replies to different forms of dismissal of other individuals claiming that element-desktop is slow. I want Element to be great and to be able to honestly vouch for it.

It would be more honest to say something like "element-desktop works great on macOS and keeps improving on all platforms", rather than pretending like anyone with issues is an edge case. Could it be that you, who work closely to the product, are more of an edge case?

We all have our blind spots.

If you have time at some point, maybe spin up an Ubuntu/Fedora/whatever VM, install element-desktop, sign in to your account and try to use that as your desktop driver for two weeks. Should be straight-forward enough on a Mac. It needs to be with your largest account. Consider it a challenge.

> this is like saying “i tried the web, and it’s extremely slow”

Uuuuuh ok...? WhatsApp isn't slow.

The matrix protocol is an open protocol where anyone can build on. You using the matrix protocol is the you using http. So your slowness equates to the server you are communicating with. Note: Yes, the protocol has issues when you are joining larger rooms. But for WhatsApp scale (max 256 users in a group) matrix works pretty well.

Uhhhh ok? Email is fast.

I'm running it on my own server and performance is quite acceptable. Picking the right client is very important, though; Element isn't always the fastest, and I find Cinny's UX to be much better for general chat, which is clearly very much… inspired by Discord. On the other hand, Element is ahead in terms of features and protocol support (like the (live) location sharing feature), but Fluffychat has the superior mobile app in terms of general look and feel IMO. On the desktop, Nheko is incredibly fast, being written in a native language and being optimized for performance and all, but I don't use it because I just can't get used to the design.

When joining huge chat rooms like some of those on the matrix.org homeserver, it can take a bit for the clients to sync up and get going. Performance is getting improved all the time, especially in terms of quickly joining a room. Latency also doesn't help, the protocol requires loads of round trips for the JSON payloads to go back and forth, so if you're not near your homeserver you're going to see some annoying problems.

I recommend giving the platform another quick try using https://app.cinny.in/ which to me feels very Discord-like in terms of snappiness.

Cinny user registration told me my username was already taken, and threw up a never ending captcha[0]. I nevertheless got a "validate your email" in my inbox, although I can't login. Not, like, a great start.

[0] https://imgur.com/a/zYBZWoW

https://github.com/cinnyapp/cinny/issues/664 Thanks for the bug report.

I'm not sure the problem was the client (element for Android). Asking around it seems people on the chatrooms kind of agreed the issue was matrix.org

Regardless, if you believe the issue is the client, which would you recommend is the lightest/fastest client?

The problem of slow joins isn't the client, it's the protocol. Just join the Synapse admins channel on matrix.org (will take half an hour to load, your client will time out and give you an error but it will load eventually) and the other admins will tell you they're all aware of the problem.

Shocking to see Arathorn deflecting about this. I run a server and just never use federation to avoid the problem.

Not sure why I keep getting flagged

I disagree that the protocol is the problem. There's a combination of frontend/backend issues impacting performance, but servers written in faster languages don't seem to struggle with joining channels all that much.

Synapse being written in Python seems like a much bigger problem to me. This problem only exists in rooms not already available on the server, though; if you register with matrix.org then matrix.org rooms won't suffer nearly as much as running your own server.

Sadly, alternatives like Conduit still aren't fully-featured and they probably won't ever be as focus lies on the Element ecosystem. It's a real shame.

I’m not deflecting - i’m just trying to figure out which slowness folks are complaining about. Is it really slow joins over federation (which is absolutely a real problem, which is why we’re busy implementing https://github.com/matrix-org/synapse/milestone/6). Or is it Element Android being sluggish when changing rooms? Or is it a slow server being slow to send messages?

My point was that saying “matrix is slow” is unhelpful given it’s completely unclear what aspect is being complained about.

https://news.ycombinator.com/item?id=32020929

I don't know why Arathorn is further down the thread dismissing this problem.. it's a well-known problem in the community..

https://github.com/matrix-org/synapse/issues/1211 there's the seven year old bug

Thank you for this, I was beginning to think I'm the crazy one.

Ok, so matrix is useless then, is that it?

They're talking about a specific issue with federation at scale. I run a hybrid conference in Seattle and we use Matrix. I make a successful living out of this, so it seems a stretch to call it useless.

E-mail has much bigger scale and is fast

A single email messages often takes minutes to receive. Conversations are usually highly asynchronous. I wouldn't call it fast, exactly.

I found the same, as soon as I join any larger rooms it starts to struggle.

The clients feel sluggish as well, just in terms of moving around the UI.

I'm not familiar with pricing in this space, but $3.80 / MAU (says $3 for element product, then 0.80 for the chatterbox product on top) seems really expensive that you would have very specific use-cases (government, hospitals?) to use the product to want to pay the price for it.

It’s $3/MAU for the users who are using a fullblown Matrix client like Element on the server. Meanwhile users who are coming in via the lightweight Chatterbox client are only $0.80/MAU. And users who come in via federation are free.

We’ll see how the pricing fares in practice.

Yeah. I can’t see any of the clients who are using our live chat solution paying almost $1/customer for chat. That would raise the bills of many of our clients by thousands of dollars a month.

not sure i understand what the point is.. Embedded usually means c2b communication, not c2c. The professional you're communicating with is probably already hosting its computer's data on the company's network...

This could be useful for smaller business that don't want to maintain their own servers. Element already provides hosting services for Matrix chat [1]. Businesses can use it, without worrying about messages being exposed to the hosting service.

[1]: https://element.io/matrix-services

Bonus - unlike Signal they don't need your phone number or DNA...

Does it have export?

Signal's complete inability to any kind of history backup is a dealbreaker for me.

Just because there's no "official" way to access history as a client in Signal doesn't mean the history isn't there. You'd have to ask that "Moxie Marlinspike" or whatever his name is fella.

Element has. The app on the other side

I think it's unlikely that this chatbox has export functionality

With E2EE I don't think you can even implement a reliable export on the server side.

It seems like Element is limited to only exporting a single room, though. You need something like https://gitlab.com/argit/matrix-recorder/ to export all messages, it seems.

> With E2EE I don't think you can even implement a reliable export on the server side.

Can't you use your client key(s)?

The client would have to fetch all your messages first. Some rooms can have thousands of messages a day, and some people are in thousands of rooms [1] (though these are core developers so they might be stress testing)

[1]: https://news.ycombinator.com/item?id=32021303

but you would hopefully not export all messages every time? incremental?

If you wanted automated exports I think an easier way would be to host your own homeserver, and create your account on that homeserver. I believe any messages in any rooms you join will be synced with your homeserver, and you can perform automated full backups (or maybe incremental backups if the database supports it?)

> Element has

it has if the the person who you are chatting with didn't already delete their comment (unless you host your own server and modified it to keep a log of everything)

> Element has. The app on the other side

Which is currently broken and has been for some time. If you export a room, images will not show in the final exported chat.

> It’s a surprise to most people that the majority of embedded chat is not end-to-end encrypted (E2EE).

I don’t know about the general populace, but I would instead be surprised to encounter E2EE in embedded chat.

I also go to what I keep on saying in cases like this: first-party end-to-end encryption is broken by design. To have any semblance of real security, you need to self-host the client software, preferably also obtaining it from a different party from the transport provider. Self-hosting of the entire chat system is the only truly dependable solution here, and in that context for this application, end-to-end encryption adds no value at all, being equivalent to transport encryption.

This is very interesting. Does Chatterbox require agents to use specialized matrix clients to interact with customers or will any matrix client do? (e.g Element for android)

If any matrix element would do, how will new customers appear in the client? Will they pop up as a new direct chat?

You can use any matrix client to interact with the customers. New customers will appear as direct chats in your preferred client.

How do you verify that you are actually chatting with the entity that you want to be chatting with?

This is just another firm reminder that Matrix isn't the revolution against IRC/XMPP and instead is just a company running Microsoft's playbook.

How so?

Because they are in the "extend" phase.

New Vector (the company behind Element) is building tools on the matrix protocol. And making a business out of it. Which is good. It shows the world tools that can be built on the matrix protocol. More people get involved and newer tools emerge.

+1 for sustainable open source development. I think I've seen three paths:

1. The employee who has the blessing of the company to work on a side project during some work hours.

2. The developer who does contracting to keep a passion project afloat.

3. The developers who organize a company and try to invent business cases while keeping the core free and open.

Out of these, I feel (3) has the most possibilities. E.g. ability to focus, or if you happen to stumble on a great contributor, you can offer them a job. I don't see how this could be worse than the alternatives.

As far as I can see, they "embraced" their own protocol and now "extend" it by building open source products on top[1]. Would love to see Microsoft do that kind of "extend". :)

[1] https://github.com/vector-im/chatterbox

Reply on news.ycombinator.com