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.
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.
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.
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:
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!
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.
> 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.
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).
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
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
>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?
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.
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.
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.
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.
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.
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.
I don't know why Arathorn is further down the thread dismissing this problem.. it's a well-known problem in the community..
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.
> 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.
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...
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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)
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?)
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)
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.
> 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?
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". :)
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.
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!