71–80 of 93 posts
Earlier quoted context omitted.
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.
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!
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?
Earlier quoted context omitted.
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. 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.
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.
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.
Earlier quoted context omitted.
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.
* 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
Earlier quoted context omitted.
> 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.
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 t…
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] [livematrix] [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.
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 t…
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] [livematrix] [Matrix homeserver] In the end you always have to tr…