We can do better than Signal(icyphox.sh)
icyphox.sh
We can do better than Signal
https://icyphox.sh/blog/signal/
289 comments
> I feel like Signal is held to a ridiculously high bar when it comes to anything.
Maybe I can help:
I feel Signal is doing a lot right and if I need to send a message right now and be 99.999% sure nobody except the recipient can read it, Signal is my choice.
My criticism is mainly directed not at Signal, but at the people trying to promote Signal by trying to trash every other messaging technology.
The reason is that until Signal solves:
- backups
- stable API available for everyone (I don't think they have one)
- bots (I mean a bot API for creating bots)
- large groups
- a number of ux issues
- and allow armed forces and other groups that need it to run their own servers
... until then there will be room for other messaging solutions.
I'll take it a step further:
- if you would be happy to stuff it in a physical envelope
- or send it by email
- and you don't hold a grudge against Facebook or are willing to live with the thought of FB knowing who you talk to and when
then you can safely send it by any messaging service.
Fighting about which just keeps people using sms or email, both trivially interceptable by a number of parties.
TLDR:
1. Signal is fine, excellent AFAIK
2. there's room for other messaging services as well
3. one doesn't make Signal better by trying to trash other messaging solutions
Maybe I can help:
I feel Signal is doing a lot right and if I need to send a message right now and be 99.999% sure nobody except the recipient can read it, Signal is my choice.
My criticism is mainly directed not at Signal, but at the people trying to promote Signal by trying to trash every other messaging technology.
The reason is that until Signal solves:
- backups
- stable API available for everyone (I don't think they have one)
- bots (I mean a bot API for creating bots)
- large groups
- a number of ux issues
- and allow armed forces and other groups that need it to run their own servers
... until then there will be room for other messaging solutions.
I'll take it a step further:
- if you would be happy to stuff it in a physical envelope
- or send it by email
- and you don't hold a grudge against Facebook or are willing to live with the thought of FB knowing who you talk to and when
then you can safely send it by any messaging service.
Fighting about which just keeps people using sms or email, both trivially interceptable by a number of parties.
TLDR:
1. Signal is fine, excellent AFAIK
2. there's room for other messaging services as well
3. one doesn't make Signal better by trying to trash other messaging solutions
> - and allow armed forces and other groups that need it to run their own servers
if you can afford to run your own servers, then you can afford to run a build server too and push your own releases with the server patched.
if you can afford to run your own servers, then you can afford to run a build server too and push your own releases with the server patched.
> then you can afford to run a build server too and push your own releases with the server patched.
I think you are looking in the right direction.
The cost for servers were never the reason why others aren't running their own Signal networks AFAIK.
I think you are looking in the right direction.
The cost for servers were never the reason why others aren't running their own Signal networks AFAIK.
I should have stated in my original post that there are a lot of features that Signal could add/improve on; my post was meant to be commentary about the implementation critiques levied against Signal.
Your only point I disagree with is backups: there is simply no way for a non-for-profit company that doesn't monetize user data to afford providing cloud backups.
P.S. "New" groups in Signal support up to 1,000 users, did you need something bigger?
Your only point I disagree with is backups: there is simply no way for a non-for-profit company that doesn't monetize user data to afford providing cloud backups.
P.S. "New" groups in Signal support up to 1,000 users, did you need something bigger?
> Your only point I disagree with is backups: there is simply no way for a non-for-profit company that doesn't monetize user data to afford providing cloud backups.
I would actually prefer local backups. I can always upload them to the cloud myself, and then I pay :-)
> P.S. "New" groups in Signal support up to 1,000 users, did you need something bigger?
OK, this might come off as moving the goal posts, so let me say why it is not intended to[1]: Signal is very usable for what it is intended for. 1000 is enough for my family in law and even my family.
I'm fairly certain I read at least one other messenger has a limit of 200 000 members in one group, moderation tools, channels with channel publishers, subscribers and comments.
And my point is not that it is better than Signal but that they are different!
If I need to send pass codes or something I can use Signal. If I need to receive broadcasts from one of the channels I follow I can use Telegram etc.
I have 32GB (or even 64GB?) of storage on my phone so I never had to choose :-)
[1]: That is, it is not moving my goal posts. My hope was never that Signal should replace everything else.
I would actually prefer local backups. I can always upload them to the cloud myself, and then I pay :-)
> P.S. "New" groups in Signal support up to 1,000 users, did you need something bigger?
OK, this might come off as moving the goal posts, so let me say why it is not intended to[1]: Signal is very usable for what it is intended for. 1000 is enough for my family in law and even my family.
I'm fairly certain I read at least one other messenger has a limit of 200 000 members in one group, moderation tools, channels with channel publishers, subscribers and comments.
And my point is not that it is better than Signal but that they are different!
If I need to send pass codes or something I can use Signal. If I need to receive broadcasts from one of the channels I follow I can use Telegram etc.
I have 32GB (or even 64GB?) of storage on my phone so I never had to choose :-)
[1]: That is, it is not moving my goal posts. My hope was never that Signal should replace everything else.
At least on Android, there is a local backup option although you need to manually pull it off the device.
I get what you're saying about chat/moderation tools. For some reason I limit my view of Signal to groups of people I actually know. I would personally never use it instead of something like Gitter or community-based chats. I fully agree various chat programs (mostly) each have their own niche.
I get what you're saying about chat/moderation tools. For some reason I limit my view of Signal to groups of people I actually know. I would personally never use it instead of something like Gitter or community-based chats. I fully agree various chat programs (mostly) each have their own niche.
I want none of this stuff in a messaging app, it's not a social media platform.
Agreed. If all you need is glorified SMS replacement, Signal is the way to go.
Indeed, and Signal has been marketed from day one as a drop in SMS replacement. Initially it even used SMS as the transport for encrypted messages. it was literally called "TextSecure". This is why I have always found the attacks on it using phone numbers to be amusing.
Fine, then you can go on using Signal.
I am happy with that.
My point wasn't about that but about those people who won't let the rest of us use one or more other messengers.
I am happy with that.
My point wasn't about that but about those people who won't let the rest of us use one or more other messengers.
Agreed. In fact, as I also said here (https://news.ycombinator.com/item?id=25802021) I consider the lack of backups to be a huge security flaw that is conveniently left out in such promotions.
Why is not wanting vendor lock-in a high bar? After dealing with Messenger, WhatsApp, Face time, etc all my life I'm tired of it.
It doesn't matter if the code is open source, I'm still going to be locked in when all my friends move to Signal.
It doesn't matter if the code is open source, I'm still going to be locked in when all my friends move to Signal.
I understand what you're saying but I don't know if calling it vendor lock in is quite correct. You can export your list of messages out of Signal and presumably import them to whenever you motivated to do so. Your friends could then join you on the new service and life would continue on.
I am personally unaware of any communication service with a universally portable user identifier and that allows you to freely switch upstream providers other than phone service. I think this what you're talking about?
I am personally unaware of any communication service with a universally portable user identifier and that allows you to freely switch upstream providers other than phone service. I think this what you're talking about?
Well... yes, email and sms and telephone. They're protocols that anyone can decide to support and participate in. Honestly SMS was a good solution for my needs for 1:1 messages, it just didn't properly evolve to support the f a featureset we expect from modern messaging.
I was actually thinking about this before I posted and discounted email. It has high interoperability but you cannot move your email address to a different provider if you didn't opt to use a domain you owned.
This is obvious when you say it but I can port my phone number between phone companies whereas I cannot move my Gmail address to a different email provider.
This is obvious when you say it but I can port my phone number between phone companies whereas I cannot move my Gmail address to a different email provider.
You can see some proposals for server migration/fallback here:
https://github.com/matrix-org/matrix-doc/issues/915
https://github.com/matrix-org/matrix-doc/issues/915
Messages arriving out of order when you switch devices and missed notifications isn't supposed to be a high bar for a messenger.
Telegram and WhatsApp get these things right, Signal is just lacking at the moment.
Telegram and WhatsApp get these things right, Signal is just lacking at the moment.
>when you switch devices
Signal requires and only supports a single mobile device, you can link multiple desktop clients to a mobile device. But one cannot have signal on multiple devices.
Signal requires and only supports a single mobile device, you can link multiple desktop clients to a mobile device. But one cannot have signal on multiple devices.
If the goal is to protect yourself from the NSA, switching from WhatsApp to signal is not going to change things.
Signal could well be a honey pot software designed to attract people who don't want to be listened to by the NSA.
I agree that signal is secure and oriented towards privacy, two different things.
Signal could well be a honey pot software designed to attract people who don't want to be listened to by the NSA.
I agree that signal is secure and oriented towards privacy, two different things.
I believe you're talking about a hypothetical but are you saying that the E2E crypto in Signal is flawed and therefore useful as a NSA honeypot?
We've seen from previous subpoena that Signal really only does retain the limited data they claimed and the content is auditably correctly encrypted.
We've seen from previous subpoena that Signal really only does retain the limited data they claimed and the content is auditably correctly encrypted.
If they're transparent, why don't they expose their commits to server code to the public?
This is a great example of what I'm talking about. Are you also commenting how you can't see the source of your phone's baseband, Google's services, your ISP's router firmware, WhatsApp's servers, Facebook's service's, etc?
Because Signal's client is open source it's considered a unique-to-Signal downside that we don't have access to the server's source. I feel like some people would bring up the server source issue if someone was asking if it would be a good idea to migrate off of Facebook Messenger.
Because Signal's client is open source it's considered a unique-to-Signal downside that we don't have access to the server's source. I feel like some people would bring up the server source issue if someone was asking if it would be a good idea to migrate off of Facebook Messenger.
Well Signal has put itself as a high privacy option, we are open, check out our code. Well we can check the client code but we dont know what you are running on the server.
FB, Google etc never claimed to be open source with their infrastructure.
So if WhatsApp cant be trusted as to what happens on the server, right now neither can Signal.
Can Signal show that what they are running on the server is the same as whats on Github? Are we just trusting them because we have been trusting them all along?
FB, Google etc never claimed to be open source with their infrastructure.
So if WhatsApp cant be trusted as to what happens on the server, right now neither can Signal.
Can Signal show that what they are running on the server is the same as whats on Github? Are we just trusting them because we have been trusting them all along?
You don't need to trust the server with E2E encryption. If you can review and trust the client, the server only has access to the information that the client sends.
Even if they release up-to-date server code, we have no way to confirm that's the code that's running on their servers. People would then complain that they don't have shell access to the servers to ensure the code is what is expected.
Even if they release up-to-date server code, we have no way to confirm that's the code that's running on their servers. People would then complain that they don't have shell access to the servers to ensure the code is what is expected.
Actually there's a way to check the code running on their servers. At least Signal claimed that:
Modern Intel chips support a feature called Software Guard Extensions (SGX). SGX allows applications to provision a “secure enclave” that is isolated from the host operating system and kernel, similar to technologies like ARM’s TrustZone. SGX enclaves also support a feature called remote attestation. Remote attestation provides a cryptographic guarantee of the code that is running in a remote enclave over a network.
https://signal.org/blog/private-contact-discovery/
But of course you need published source code and reproducible build.
Modern Intel chips support a feature called Software Guard Extensions (SGX). SGX allows applications to provision a “secure enclave” that is isolated from the host operating system and kernel, similar to technologies like ARM’s TrustZone. SGX enclaves also support a feature called remote attestation. Remote attestation provides a cryptographic guarantee of the code that is running in a remote enclave over a network.
https://signal.org/blog/private-contact-discovery/
But of course you need published source code and reproducible build.
Well one way you could confirm is to run your own instance of the server and run the client against it and the client works as if you are going against Moxie's server
Right now if you run the published server code and point the client certain features don't work. Doesn't that sound a little concerning ?
Right now if you run the published server code and point the client certain features don't work. Doesn't that sound a little concerning ?
Huh? I googled "signal server" and got https://github.com/signalapp/Signal-Server
if you look at the changes, there havent been any updates since April 2020. Seems odd for it to have no changes in close to a year, esp after what we know happened last weekend ( when we know feature flags were added )
The forum has posts of people who cant even run their own instance of Signal.
So why arent they sharing what is happening server side
The forum has posts of people who cant even run their own instance of Signal.
So why arent they sharing what is happening server side
As I wrote in https://news.ycombinator.com/item?id=25795575
- WhatsApp: Oh wait, SMS etc. is completely insecure
- Signal: Oh wait, WhatsApp is structurally unable to be a force for privacy
- Matrix: Oh wait, even benevolent centralization is an unnecessary risk
It's not that worse is better, but the general public's imagination can only grow so fast. We need to coax people along. As such, I do think all 3 serve a purpose in certain times and places.
I took advantage of the Signal downtime to get a few people onto Matrix. There will be more opportunities.
- WhatsApp: Oh wait, SMS etc. is completely insecure
- Signal: Oh wait, WhatsApp is structurally unable to be a force for privacy
- Matrix: Oh wait, even benevolent centralization is an unnecessary risk
It's not that worse is better, but the general public's imagination can only grow so fast. We need to coax people along. As such, I do think all 3 serve a purpose in certain times and places.
I took advantage of the Signal downtime to get a few people onto Matrix. There will be more opportunities.
In fairness, I think WhatsApp's value proposition is and was as little more than 'just' oh wait, sms etc. is completely insecure. I don't think the majority really cared about that (especially since end-to-end encryption was a later addition). I think most people primarily started using WhatsApp because a) it was (is) free b) cross-platform c) worked very reliably
Most people profoundly do not understand or care about the vagaries of how their messaging is encrypted.
They do care about SMS fees, especially across international borders.
They do care about sending group texts between Android and iOS and not having things go slowly haywire as messages don’t come across.
They do care about sending messages over wifi if they’re somewhere without a cell signal. (OK, bit of a Canadian thing, but the cottage has wifi and no cell signal.)
They do care about SMS fees, especially across international borders.
They do care about sending group texts between Android and iOS and not having things go slowly haywire as messages don’t come across.
They do care about sending messages over wifi if they’re somewhere without a cell signal. (OK, bit of a Canadian thing, but the cottage has wifi and no cell signal.)
> They do care about sending messages over wifi if they’re somewhere without a cell signal. (OK, bit of a Canadian thing, but the cottage has wifi and no cell signal.)
That you have to explain why you might be without cell signal shows that you are blessed up there. Today I talked with someone a few miles outside of Frankfurt (Germany) - huge financial hub - and the line broke down almost 3 times due to bad signal...
That you have to explain why you might be without cell signal shows that you are blessed up there. Today I talked with someone a few miles outside of Frankfurt (Germany) - huge financial hub - and the line broke down almost 3 times due to bad signal...
Simple Groups and painless multimedia was what gave WhatsApp the edge in the early days
Liked "Simple Groups and painless multimedia was what gave WhatsApp the edge in the early days"
-------
^ That's and ultra low res photo sharing what you get when you group SMS/MMS with folks in the Apple ecosystem. You don't get it in WhatsApp, etc.
-------
^ That's and ultra low res photo sharing what you get when you group SMS/MMS with folks in the Apple ecosystem. You don't get it in WhatsApp, etc.
And general costs. Whilst SMS might be free (or effectively free, plans including thousands of messages per month are not unknown) for vast swathes of people, but MMS is most definitely not.
I really doubt it was about security. My bet is on convenience and the fact that it's free for Non-North Americans while SMS is not.
E2E encryption is certainty a reason that non-techies use WhatsApp, particularly in preference to Facebook Messenger since 'Facebook reads all those messages' as a friend said. Which I don't think is technically possible any more, but remains a common suspicion.
A lot of people I knew that used WhatsApp used it because international text used to be prohibitively expensive and it was notoriously unreliable. So most of my friends used it in Europe. Also you can still use it if you aren't on cellular while traveling. Although I'm sure the cross-platform, freeness, and reliability were all pluses.
Also for all of the messaging apps out there it's surprising how much feature differentiation they still have. Once you get used to a certain feature set it's hard to move to something with a different set even if it's overall probably better.
It wasn’t free in the beginning but it was cheaper to send a picture message from it than from MMS
One thing that I think will always give Signal and WhatsApp an edge over something like Matrix is that it's simply tied to a phone number. You don't "make an account" and have to memorize a password or anything, it just falls into place like any other texting app. The barrier to entry is about as close to frictionless as possible.
There's nothing inherent about this to Matrix, I don't believe.
I mean, maybe? There could certainly exist a phone-verified Matrix server, obviously, but unless the default server that is used for Matrix does that, it's still going to be a bit of friction entering in the server information.
Or even more critically, a discovery server that supports phone number registration so your existing contacts can find you again after they switch.
The only major discovery server on Matrix is currently the vector.im one, and it only supports email identity registration. As many people have pointed out, most users care far more about usability than they do security/privacy, so a service that allows an optional registration of identity using the currently-standard identity tracking system of phone numbers is pretty much a requirement.
The only major discovery server on Matrix is currently the vector.im one, and it only supports email identity registration. As many people have pointed out, most users care far more about usability than they do security/privacy, so a service that allows an optional registration of identity using the currently-standard identity tracking system of phone numbers is pretty much a requirement.
Maybe so, but that is completely irrelevant for now.
I have been able to convince quite a few non-tech friends to use Signal, but that would have been impossible with Matrix.
I have been able to convince quite a few non-tech friends to use Signal, but that would have been impossible with Matrix.
[deleted]
This is the worst thing about Matrix fans gloating over the outage: do you really think the outage helps Matrix become widespread? No, it will make people think twice before potentially taking that next step. And rightly so, because the same problem can happen in Matrix as well. A sudden surge in popularity can make matrix.org go down, and federation or not, that's not going to be a good look.
But alas, growing pains are part of the game. Let's hope they're not fatal for either.
But alas, growing pains are part of the game. Let's hope they're not fatal for either.
I'm not trying to move people off signal. I of course wish the outage hadn't happened, but I'm not to avoid finding a silver lining when I can.
I'm not positive, but I think the signal protocol and signal messenger came before Moxie worked with Whatsapp to provide e2e encryption.
Not refuting your point at all, just providing additional context.
Not refuting your point at all, just providing additional context.
Yeah I'm charting the public's realizations, not security experts' realizations.
Matrix is merely federated, right? Why is it unlikely that a situation like email or the Internet will emerge, where the network still ends up massively centralized because that's just more convenient?
We're proactively working on P2P matrix, as per https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/, to prevent this risk.
This is literally the saving grace for Matrix in my opinion. As can be seen with Mastodon, federation tends toward centralization of the servers if there's even an incremental benefit to doing so and nothing encouraging otherwise.
Matrix at least seems to have fewer barriers to usability/functionality when self-hosting, which decreases the detriments of self-hosting and slightly lowers the drive to centralize, but until P2P is default standard for clients the convergence is likely to remain with a mostly centralized federation infrastructure target than a heavily decentralized one.
Matrix at least seems to have fewer barriers to usability/functionality when self-hosting, which decreases the detriments of self-hosting and slightly lowers the drive to centralize, but until P2P is default standard for clients the convergence is likely to remain with a mostly centralized federation infrastructure target than a heavily decentralized one.
Thank you, btw. I know it's a hard problem, but there is no substitute for going P2P as far down as you can. To my understanding, there is profound moral merit in your work.
As I recently said in another thread, an email sort of scenario is exactly what I'd like, or at least it would be many times better than what we currently have for im systems. The most important thing to me (and I suspect many other people in favor of decentralization/federation) is the ability to host my own service. I couldn't care less if 90% of email users are on gmail as long as I can run own email server or pay someone else to run one for me while still communicating with everyone.
I'm sure some people would disagree with my priorities above but for my experience as a user, that is what makes the most difference to me - not being boxed into what someone else thinks my client should look/act like or being locked into their server. Naturally I think more decentralization is better, but that's more a philosophical preference whereas wanting to run my own server or pick my own client is more about usability and control.
I'm sure some people would disagree with my priorities above but for my experience as a user, that is what makes the most difference to me - not being boxed into what someone else thinks my client should look/act like or being locked into their server. Naturally I think more decentralization is better, but that's more a philosophical preference whereas wanting to run my own server or pick my own client is more about usability and control.
While e-mail usercount is not evenly distributed across many servers, the fact that it's open an interoperable gives you several things:
- you can use whatever client/server you want (or host your own)
- you can still communicate with your friends if they're on another server
- servers are run by separate entities in politically distinct regions
None of these things depend on there being a uniform spread of users across servers.
- you can use whatever client/server you want (or host your own)
- you can still communicate with your friends if they're on another server
- servers are run by separate entities in politically distinct regions
None of these things depend on there being a uniform spread of users across servers.
matrix.org is already 30% of network I read once? For the general public I expect this to continue (at least until we with NixOS making self hosting things far easier someday :P).
However, just as regular users want to get off the Facebook ecosystem, business's should want to get away from GSuite (Really, it's embarrassing if you are anything close to a google competitor) and I have some optimism there. The "element matrix services" of course isn't political decentralization, but is a helpful stepping stone, and still more isolated per tenant than GSuite (e.g. completely distinct accounts).
However, just as regular users want to get off the Facebook ecosystem, business's should want to get away from GSuite (Really, it's embarrassing if you are anything close to a google competitor) and I have some optimism there. The "element matrix services" of course isn't political decentralization, but is a helpful stepping stone, and still more isolated per tenant than GSuite (e.g. completely distinct accounts).
your causality is wrong here; on day 1, matrix.org was 100% of the network, because there weren't any other servers. since then it's been decreasing steadily - at around 30% atm.
But when Matrix gains massive adoption from the mainstream, wouldn't you expect those people to primarily rush to matrix.org?
When Matrix enters the mainstream, it will be helped along by technical friends telling people about it. Hopefully friends technical enough that hosting their own server for their group isn't too big a deal.
I'm a bit annoyed at "we can do better than X" when, you know what? Maybe we can't.
Yes, it's nice that you and I can install Element and deal with the finicky crypto handshake that for some reason always shows red for me because a friend opened the web UI and closed it before he completed the handshake and now we can never actually make that check go green, and it's nice that Mastodon is distributed but mastodon.host went down one day with all my toots without a word from the administrator, and yeah I know I should have picked a better host (though if you could predict that mastodon.host will die why didn't you tell me?), but my mom can't.
Users value their convenience, and security and privacy are inconvenient. Hell, we started decentralized and over email and newsgroups and personal websites and blogs and it's all Facebook Facebook Facebook now that the Eternal September came around.
If we could do better, we would have done better by now.
Yes, it's nice that you and I can install Element and deal with the finicky crypto handshake that for some reason always shows red for me because a friend opened the web UI and closed it before he completed the handshake and now we can never actually make that check go green, and it's nice that Mastodon is distributed but mastodon.host went down one day with all my toots without a word from the administrator, and yeah I know I should have picked a better host (though if you could predict that mastodon.host will die why didn't you tell me?), but my mom can't.
Users value their convenience, and security and privacy are inconvenient. Hell, we started decentralized and over email and newsgroups and personal websites and blogs and it's all Facebook Facebook Facebook now that the Eternal September came around.
If we could do better, we would have done better by now.
I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it.
To me, we have to accept the incremental wins where we can get them; getting my parents on Signal means that they're not on WhatsApp.
I am a believer in federation, honestly, but the fact of the matter is that there's a reason that XMPP hasn't taken the world by storm, and people have gravitated towards centralized stuff: it's just easier, and not everyone is a software engineer.
That said, I would love to be wrong about this....if we can make Matrix/Element approachable by anyone, I would support that.
To me, we have to accept the incremental wins where we can get them; getting my parents on Signal means that they're not on WhatsApp.
I am a believer in federation, honestly, but the fact of the matter is that there's a reason that XMPP hasn't taken the world by storm, and people have gravitated towards centralized stuff: it's just easier, and not everyone is a software engineer.
That said, I would love to be wrong about this....if we can make Matrix/Element approachable by anyone, I would support that.
Speaking as project lead for Matrix (and Element), I'm trying to understand the mixed feedback we've had this week, and somehow channel all the negativity into improving things. While some folks are clearly using it successfully and seem to like it, another bunch of people say "it was a huge pain in the butt to get E2EE working, and if it two software engineers struggled this much..." etc.
When did this E2EE failure happen (so I know if these are current bugs or ones fixed months/years ago)? What platforms was this (web, iOS & Android are entirely separate codebases)? What actually went wrong? The simple case of signing up and DMing someone should just work, and the E2EE should be transparent.
The main possible failure modes I'm aware of right now are:
* Risk of undecryptable messages during federation outages (due to messages being shared separately from their keys)
* Risk of verifying another user getting stuck if there are weird failures/edge cases we haven't spotted yet
* Verifying yourself when you log in on a new device has confusing UX, and there's a known bug that can stop keys being synced to the new login even once verified.
If anyone in the "I tried Matrix and it was awful" camp could give detailed feedback (either here, or on github.com/vector-im/element-{web,ios,android}/issues) then it would be genuinely useful for prioritising our work. At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.
When did this E2EE failure happen (so I know if these are current bugs or ones fixed months/years ago)? What platforms was this (web, iOS & Android are entirely separate codebases)? What actually went wrong? The simple case of signing up and DMing someone should just work, and the E2EE should be transparent.
The main possible failure modes I'm aware of right now are:
* Risk of undecryptable messages during federation outages (due to messages being shared separately from their keys)
* Risk of verifying another user getting stuck if there are weird failures/edge cases we haven't spotted yet
* Verifying yourself when you log in on a new device has confusing UX, and there's a known bug that can stop keys being synced to the new login even once verified.
If anyone in the "I tried Matrix and it was awful" camp could give detailed feedback (either here, or on github.com/vector-im/element-{web,ios,android}/issues) then it would be genuinely useful for prioritising our work. At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.
> If anyone in the "I tried Matrix and it was awful" camp could give detailed feedback (either here, or on github.com/vector-im/element-{web,ios,android}/issues) then it would be genuinely useful for prioritising our work. At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.
Your two modes of suggested contact (HN, GitHub) ensure only a certain type of user will contact (both require tech skills and a login). If there really are UX issues, you might want to encourage different types of users to give feedback (and if the fear is that the feedback won't be detailed/useful, maybe a guided form can help).
Your two modes of suggested contact (HN, GitHub) ensure only a certain type of user will contact (both require tech skills and a login). If there really are UX issues, you might want to encourage different types of users to give feedback (and if the fear is that the feedback won't be detailed/useful, maybe a guided form can help).
I can easily use both of those methods and even I always like apps that allow me to just push a button and it composes an email in my phone's email app, prefilled with application version etc., and lets me send an email to report a bug/crash.
Yep, there should be a crash or bug report form within the app itself, and an email for bugs at something like [email protected]
There is one in Element Android. When the phone is shaken, a dialogue pops up "It seems you're shaking your phone in frustration, file a bug report". It has in-app bug reporting.
Also 'Menu > Report Bug' on Element Android.
> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.
That's the nature of the HN beast: getting all the "it sucked" comments without STR and/or use-case descriptions is certainly demoralizing (reading HN comments about your own work is not for the unprepared) but asking folks who've had a bad time with your product to spend more time, for free, going through that same experience again so they can do a detailed report-out for you is probably not going to get a lot of takers (even if you might get a few high quality reports).
If you're not already doing so, I would strongly recommend you invest some money in getting access to "people who've never used Matrix before but are familiar with messaging apps" to do user testing (there's a number of sites for doing that for you, where you hand over money and instructions, and they find folks to do unbiased testing for you) where you ask pairs of people to get started with your software, with the explicit goal of getting to the point where they can set up E2EE messaging, and reviewing the recordings to see what roadblocks they run into.
And for bonus points, dev-blog about those experiences on the matrix/element site (where did folks get stuck? was this a surprise to you? why? how did you fix it? what were the user reactions to the fix? how much better is Matrix now, thanks to this work?).
That's the nature of the HN beast: getting all the "it sucked" comments without STR and/or use-case descriptions is certainly demoralizing (reading HN comments about your own work is not for the unprepared) but asking folks who've had a bad time with your product to spend more time, for free, going through that same experience again so they can do a detailed report-out for you is probably not going to get a lot of takers (even if you might get a few high quality reports).
If you're not already doing so, I would strongly recommend you invest some money in getting access to "people who've never used Matrix before but are familiar with messaging apps" to do user testing (there's a number of sites for doing that for you, where you hand over money and instructions, and they find folks to do unbiased testing for you) where you ask pairs of people to get started with your software, with the explicit goal of getting to the point where they can set up E2EE messaging, and reviewing the recordings to see what roadblocks they run into.
And for bonus points, dev-blog about those experiences on the matrix/element site (where did folks get stuck? was this a surprise to you? why? how did you fix it? what were the user reactions to the fix? how much better is Matrix now, thanks to this work?).
I couldn’t emphasise this more. Stick to the YC mantra: always talk to users. Ask them what they want or have problems with, quantitatively (questionnaire style) and qualitatively (talk to them in person, real user testing).
Added a new feature? Don’t assume it’s well designed. Assume something is wrong with it and that it can and should be further optimised and sweat the details. Details matter.
Unless you sweat the details, users will notice.
Added a new feature? Don’t assume it’s well designed. Assume something is wrong with it and that it can and should be further optimised and sweat the details. Details matter.
Unless you sweat the details, users will notice.
> I would strongly recommend you invest some money in getting access to "people who've never used Matrix before but are familiar with messaging apps" to do user testing
I think they already do quite a bit of this, which is probably what makes it puzzling when tech oriented users on hn keep reporting how terrible it is, thus the desire for more details to see whether it's just an older anecdote, something missed in testing, etc.
Two matrix blog posts[1][2] from the past 2 months both mention new user testing/research, and there's definitely more if you go back in their blog history.
[1] https://matrix.org/blog/2020/12/17/matrix-to-reloaded#whats-...
[2] https://matrix.org/blog/2020/11/27/this-week-in-matrix-2020-...
I think they already do quite a bit of this, which is probably what makes it puzzling when tech oriented users on hn keep reporting how terrible it is, thus the desire for more details to see whether it's just an older anecdote, something missed in testing, etc.
Two matrix blog posts[1][2] from the past 2 months both mention new user testing/research, and there's definitely more if you go back in their blog history.
[1] https://matrix.org/blog/2020/12/17/matrix-to-reloaded#whats-...
[2] https://matrix.org/blog/2020/11/27/this-week-in-matrix-2020-...
For me, this was a month or two ago. I don't remember exactly now, but my friend and I tried to verify each other, but one of us quit the device verification (with the five emojis) half-way through and uninstalled the app, so now there is a half-verified device that we can never remove. My icon with him always shows up red because of this device, and there's nothing we can do.
UPDATE: I just checked now, there's a "manually verify by text" option, I clicked "verify" and that device finally turned green, so at least now there's a way to fix this.
One major source of confusion for me is that one-on-one chats and multi-user rooms are different, but one-on-one chats seem to be multi-user rooms with just two people in them? That is confusing to me, because I see "people" and I see "rooms" but apparently people are rooms too.
All that having been said, I am very pleasantly surprised by the overall experience, and especially the pace at which it seems to improve. I use Element semi-regularly with a friend and it's been working okay. Hopefully all these kinks will be ironed out, because I really really want a better IRC, and Gitter has become infinitely better now that I can just use Element to access it.
> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.
Also, I don't think that's what the majority of users are saying (and I certainly never said and don't think Matrix sucks). I'm saying "this is not good enough yet that my parents could use it", which is an extremely high bar, and I think that's the way you should take the feedback.
UPDATE: I just checked now, there's a "manually verify by text" option, I clicked "verify" and that device finally turned green, so at least now there's a way to fix this.
One major source of confusion for me is that one-on-one chats and multi-user rooms are different, but one-on-one chats seem to be multi-user rooms with just two people in them? That is confusing to me, because I see "people" and I see "rooms" but apparently people are rooms too.
All that having been said, I am very pleasantly surprised by the overall experience, and especially the pace at which it seems to improve. I use Element semi-regularly with a friend and it's been working okay. Hopefully all these kinks will be ironed out, because I really really want a better IRC, and Gitter has become infinitely better now that I can just use Element to access it.
> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.
Also, I don't think that's what the majority of users are saying (and I certainly never said and don't think Matrix sucks). I'm saying "this is not good enough yet that my parents could use it", which is an extremely high bar, and I think that's the way you should take the feedback.
In case you don't know, like Gitter, Freenode has a public Matrix bridge!
I remember trying the bridge but it wasn't working entirely well, has this changed recently? That's going to be another great integration if it works well.
On another note, yesterday I set up my own matrix-synapse [0] homeserver along with a token-based registration page [1] with nginx+lets encrypt as a reverse proxy. I spent ~1 hour setting it up on a fresh Ubuntu 20.04 VM.
I then on-boarded my wife, brother, father and mother without issue. I just sent them a text with screenshots and detailed instructions on what to do. Everyone's in, and we have E2EE group chats going. Within ~20 minutes of sending instructions everyone was participating in chat.
The only issue encountered was that my mom entered the wrong homeserver URL (I set up the sign-up page to be join.subdomain.tld and the homeserver to be chat.subdomain.tld and she entered the former into Element). My dad was able to resolve the issue quickly for her.
All clients are Element [2] right now, though I plan on trying Weechat [3] this week.
Honestly, I didn't expect it to be this easy to do after seeing all the complaints on HN. I subscribed on Patreon yesterday and wish you all the best of luck!
[0] https://github.com/matrix-org/synapse
[1] https://github.com/ZerataX/matrix-registration
[2] https://element.io
[3] https://github.com/poljar/weechat-matrix
I then on-boarded my wife, brother, father and mother without issue. I just sent them a text with screenshots and detailed instructions on what to do. Everyone's in, and we have E2EE group chats going. Within ~20 minutes of sending instructions everyone was participating in chat.
The only issue encountered was that my mom entered the wrong homeserver URL (I set up the sign-up page to be join.subdomain.tld and the homeserver to be chat.subdomain.tld and she entered the former into Element). My dad was able to resolve the issue quickly for her.
All clients are Element [2] right now, though I plan on trying Weechat [3] this week.
Honestly, I didn't expect it to be this easy to do after seeing all the complaints on HN. I subscribed on Patreon yesterday and wish you all the best of luck!
[0] https://github.com/matrix-org/synapse
[1] https://github.com/ZerataX/matrix-registration
[2] https://element.io
[3] https://github.com/poljar/weechat-matrix
I can share the bugs that happened to me. All of these happened in the last 6 months:
- A message would get "pinned" to the bottom in Element. Basically, you could send new messages but a specific message would always look like it was the most recent message (even though it was not). This was a purely visual bug and the other party wouldn't have the issue.
- Messages send/receive slowly compared to other services. It could also just be the matrix.org homeserver, I'm not sure. You gotta be aware you are competing against the likes of Discord however, who deliver messages nearly instantly.
- Decryption would randomly break for one party and they would be unable to decrypt new messages until they restarted the client. I couldn't identify the trigger for this as it seemed to occur randomly.
- A message would get "pinned" to the bottom in Element. Basically, you could send new messages but a specific message would always look like it was the most recent message (even though it was not). This was a purely visual bug and the other party wouldn't have the issue.
- Messages send/receive slowly compared to other services. It could also just be the matrix.org homeserver, I'm not sure. You gotta be aware you are competing against the likes of Discord however, who deliver messages nearly instantly.
- Decryption would randomly break for one party and they would be unable to decrypt new messages until they restarted the client. I couldn't identify the trigger for this as it seemed to occur randomly.
> - A message would get "pinned" to the bottom in Element. Basically, you could send new messages but a specific message would always look like it was the most recent message (even though it was not). This was a purely visual bug and the other party wouldn't have the issue.
Is this in Element Android? I've had that issue happen there too, but only there.
Is this in Element Android? I've had that issue happen there too, but only there.
I don't actually remember unfortunately, I haven't had it happen in a while. It's either the Linux client or the Android client though as those are the only two I use.
This is not in the same vein as what you're looking for. (I haven't tried user-user encryption), but the verification popups are annoying.
- I don't want popups or notifications, but whenever I use it, I'm greeted with one.
- Once I click "Verify", it's not clear how to proceed. It indicates to use a mobile phone etc with the app installed to verify. There are two clickable things: A big red "Skip" that appears to be the default button: This takes you back. A green hyperlink showing "Use recovery key or passphrase". Is this the "continue with verification and making the popup go away" button? It then asks for a passphrase, which I can only pass because it's stored in Firefox. What does this have to do with phone? Is the phone picture supposed to be clickable?
- Once I get past this, it still show a popup every time I open the page; this time, it asks me to review where I've logged in.
- Once I click review, I'm sent to a "Welcome to Element" page. The popup shows again next time I refresh or open the page.
- I don't want popups or notifications, but whenever I use it, I'm greeted with one.
- Once I click "Verify", it's not clear how to proceed. It indicates to use a mobile phone etc with the app installed to verify. There are two clickable things: A big red "Skip" that appears to be the default button: This takes you back. A green hyperlink showing "Use recovery key or passphrase". Is this the "continue with verification and making the popup go away" button? It then asks for a passphrase, which I can only pass because it's stored in Firefox. What does this have to do with phone? Is the phone picture supposed to be clickable?
- Once I get past this, it still show a popup every time I open the page; this time, it asks me to review where I've logged in.
- Once I click review, I'm sent to a "Welcome to Element" page. The popup shows again next time I refresh or open the page.
Here's a screen recording of me trying to log in to app.element.io [0].
0:10 - Stuck on "Verify this login" despite cancelling
1:00 - Same as above. The security phrase I have saved seems to be invalid.
1:38 - Can't drag or expand the left panel. Went away when I made the window wider after I stopped recording.
1:52 - After clicking "Verify" again, the session immediately verifies? I didn't enter any passphrase or do anything in my other logged in sessions.
2:18 - Every time I log in I get a notification about trusting a bunch of old sessions. There doesn't seem to be a way to get rid of them.
This is on a non-private Firefox (68, Debian) session, so maybe the security key is saved somewhere and didn't get loaded the first 2 times I tried to verify?
Also, not necessarily a bug, but to verify by phone I should just get a notification and not have to do 'Settings > Security & Privacy > Show All Sessions > [Guess one of several identical unverified Element Web sessions] > Verify.
[0]: http://files.widloski.com/matrixbug.webm
Mirror: https://youtu.be/QIRHAusQyYI
0:10 - Stuck on "Verify this login" despite cancelling
1:00 - Same as above. The security phrase I have saved seems to be invalid.
1:38 - Can't drag or expand the left panel. Went away when I made the window wider after I stopped recording.
1:52 - After clicking "Verify" again, the session immediately verifies? I didn't enter any passphrase or do anything in my other logged in sessions.
2:18 - Every time I log in I get a notification about trusting a bunch of old sessions. There doesn't seem to be a way to get rid of them.
This is on a non-private Firefox (68, Debian) session, so maybe the security key is saved somewhere and didn't get loaded the first 2 times I tried to verify?
Also, not necessarily a bug, but to verify by phone I should just get a notification and not have to do 'Settings > Security & Privacy > Show All Sessions > [Guess one of several identical unverified Element Web sessions] > Verify.
[0]: http://files.widloski.com/matrixbug.webm
Mirror: https://youtu.be/QIRHAusQyYI
Firefox 68? I'm running Firefox 84.0.2 on Pop_OS 20.04. I can empathize with the project maintainer for not prioritizing a browser ~20 versions behind latest.
I forgot to turn on automatic updates. Still, it's only 1.5 years old.
Hi!
I'd like to share something I consider a success story.
I'm using matrix successfully with my construction contractor and his helper. They've been working on a building site 2000km away for months. He and his helper have been uploading pics and video every day. They also use the chat now and then. I've shared pdf documents with them too.
Mind you, they were used to Whatsapp, so I had to nudge them into downloading yet another app and explain. As their client, I had the necessary leverage, so they did install Element (well, riot at the time). These are people who don't speak a word of English, from a remote countryside village, and totally unfamiliar with computery stuff, and they managed.
Thank you for helping to make that possible!
I'd like to share something I consider a success story.
I'm using matrix successfully with my construction contractor and his helper. They've been working on a building site 2000km away for months. He and his helper have been uploading pics and video every day. They also use the chat now and then. I've shared pdf documents with them too.
Mind you, they were used to Whatsapp, so I had to nudge them into downloading yet another app and explain. As their client, I had the necessary leverage, so they did install Element (well, riot at the time). These are people who don't speak a word of English, from a remote countryside village, and totally unfamiliar with computery stuff, and they managed.
Thank you for helping to make that possible!
I don't actually think anything is awful, but my main complaint about Element as a GUI app, is that aside from opening the chromium developer console and watching what it does, it has very few options to diagnose client-server connectivity or TLS crypto key handshake issues.
I wish it wasn't an Electron app built on Chromium which makes it a huge resource hog. There's lots of underlying dependency and reliance on whatever design decisions the Chromium developers might make now or in the future, which would not be best suited to the security and single-purpose-focus of a chat application.
I wish it wasn't an Electron app built on Chromium which makes it a huge resource hog. There's lots of underlying dependency and reliance on whatever design decisions the Chromium developers might make now or in the future, which would not be best suited to the security and single-purpose-focus of a chat application.
Isn't the beauty of Matrix that you or anyone else can build a client on top of the platform easily? I know on my Linux machine there are some non-electron options, like Qt [0].
[0] https://matrix.org/clients/
[0] https://matrix.org/clients/
I have used Element on n off. The UX around encryption and passphrase still needs some work. I cant imagine moving my family and less tech oriented friends on it.
I logged on to it yesterday and got a prompt to enter the passphrase. I have it all in bitwarden, so easy to get around but for the average joe that would be the end of the journey. Even the verify session, when in fact Ive verified them in the past.
Minor thing, I echo the sentiment to get some average joes and non-tech oriented using the product and get some feedback.
I logged on to it yesterday and got a prompt to enter the passphrase. I have it all in bitwarden, so easy to get around but for the average joe that would be the end of the journey. Even the verify session, when in fact Ive verified them in the past.
Minor thing, I echo the sentiment to get some average joes and non-tech oriented using the product and get some feedback.
I've been self-hosting synapse for 6 years (? before vector) with small active group of about 30 non technical users. You've helped me to set up synapse all those years ago. I am super grateful for that and for your work.
But we've had issues over the years
Some issues i thought are happening because we are not always on the most up to date synapse (my problem) and clients expect version of the master instance but it seems happening even on the root instance: - Verification issues that are impossible to understand even for me. Often it fails even you go through the process. - In past year huge increase in amount of notifications. Everytime i log in i am greeted with "Review where you’re logged in Verify all your sessions to ensure your account & messages are safe". - Some my users enabled e2e and randomly locked self out of rooms because they log out somewhere or updated client and couldn't back in.
All my users have similar problems and actually started avoid e2e on matrix now. It's shame because most of them are now also on Signal because they want e2e.
Other issues:
- I had to make special video tutorial for users to be able to register and log in at our own instance. They keep trying to log into matrix.org instance. Custom instance seems like something second tier in clients. It would be really nice if instead "login to matrix" vs "use custom server". It would be login to your server with multiple public servers as options by default and + button to add custom servers. More like you add services/logins in ios or something. It wouldn't feel like discrimination.
Overall i feel like there is some duality in Matrix goals. On one hand it markets federation and decentralization but on other hand it promotes matrix.org so it looks like is the only instance. It would be cool to support different servers to get some diversity (like this https://www.hello-matrix.net/public_servers.php is not on matrix.org page).
But we've had issues over the years
Some issues i thought are happening because we are not always on the most up to date synapse (my problem) and clients expect version of the master instance but it seems happening even on the root instance: - Verification issues that are impossible to understand even for me. Often it fails even you go through the process. - In past year huge increase in amount of notifications. Everytime i log in i am greeted with "Review where you’re logged in Verify all your sessions to ensure your account & messages are safe". - Some my users enabled e2e and randomly locked self out of rooms because they log out somewhere or updated client and couldn't back in.
All my users have similar problems and actually started avoid e2e on matrix now. It's shame because most of them are now also on Signal because they want e2e.
Other issues:
- I had to make special video tutorial for users to be able to register and log in at our own instance. They keep trying to log into matrix.org instance. Custom instance seems like something second tier in clients. It would be really nice if instead "login to matrix" vs "use custom server". It would be login to your server with multiple public servers as options by default and + button to add custom servers. More like you add services/logins in ios or something. It wouldn't feel like discrimination.
Overall i feel like there is some duality in Matrix goals. On one hand it markets federation and decentralization but on other hand it promotes matrix.org so it looks like is the only instance. It would be cool to support different servers to get some diversity (like this https://www.hello-matrix.net/public_servers.php is not on matrix.org page).
I should be clear, I wouldn't say Matrix/Element "sucked", and I apologize if that's the tone that my comment implied. It's pretty cool, and I greatly preferred it over trying to finagle XMPP + OMEMO, and I will probably try it again soon enough.
In my case, my issues came down to mostly your last point:
> Verifying yourself when you log in on a new device has confusing UX, and there's a known bug that can stop keys being synced to the new login even once verified.
If I installed a desktop client on two different mac computers, I would have issues with messages not decrypting properly until I do a re-verification, and figuring that out took some Googling and trial-and-error.
In my case, my issues came down to mostly your last point:
> Verifying yourself when you log in on a new device has confusing UX, and there's a known bug that can stop keys being synced to the new login even once verified.
If I installed a desktop client on two different mac computers, I would have issues with messages not decrypting properly until I do a re-verification, and figuring that out took some Googling and trial-and-error.
OOT: Haters are going to hate anyway. Thank you for the incredible work you do with Matrix and the open ecosystem it fosters.
It's against the rules to call it out on HN, but given how incredible Matrix is, I will happily risk being banned to share that I believe there is an astroturfing campaign currently being undertaken to promote Signal and that you should take the complaints with a grain of salt. Matrix and other competition are being cast with FUD in an attempt to sway fence sitters.
Thank you for Matrix and Element. My non-technical friends and family all use it without issue.
Thank you for Matrix and Element. My non-technical friends and family all use it without issue.
Funnily enough it seems like opposite and people are trying to put down Singal. Seriously we are all on the same side. It's not competition.
I've been running matrix instance for probably 6 years from times even before Vector.
The constant popups happening and mysterious verification fails gotten pretty annoying. So much that my non-technical friends started to complain. It has gotten objectively worse in past year.
I happily use both Signal as SMS replacement and Matrix for community/slack. Signal can't do chatrooms / more people well and it will probably never will. Matrix on the other hand is much worse at ux of the encryption process and overall user friendliness for casual users. It's not long ago when matrix didn't have 1on1 chats and would just make new room with 2people named after them.
I've been running matrix instance for probably 6 years from times even before Vector.
The constant popups happening and mysterious verification fails gotten pretty annoying. So much that my non-technical friends started to complain. It has gotten objectively worse in past year.
I happily use both Signal as SMS replacement and Matrix for community/slack. Signal can't do chatrooms / more people well and it will probably never will. Matrix on the other hand is much worse at ux of the encryption process and overall user friendliness for casual users. It's not long ago when matrix didn't have 1on1 chats and would just make new room with 2people named after them.
Signal is a single point of failure, cell-phone number dependent chat app. It should be put down along with WhatsApp.
If you don't own the server, you are not in control of your information.
If you don't own the server, you are not in control of your information.
Nobody cares if you own the server if there are no users on it.
Also it's not like Matrix.org is not single master instance that can fail just as easily. Even better most of data there is not e2e encrypted so yes if somebody hacks it you will loose all the information.
Also it's not like Matrix.org is not single master instance that can fail just as easily. Even better most of data there is not e2e encrypted so yes if somebody hacks it you will loose all the information.
My experience with Matrix/Element and the various standard-compliant Matrix chat clients, in an ISP environment, is that it's totally possible to set up a rock solid replacement for Slack within an organization that has a person on staff to spend some cycles setting it up, and periodically maintaining it.
We don't have any major technical challenges or problems running our own Synapse daemon server. It's a debian stable xen PV VM stored on a LVM logical volume, so easily moved between hypervisors, or cloned, if ever necessary. It runs at a load average of 0.01.
In my specific ISP environment it's the same person that admins the X.509 private root CA PKI so we're well equipped to deal with running it in a purely intranet environment with no access to the global routing table.
For widespread non technical random end user use? Totally agreed it's not ready yet.
We don't have any major technical challenges or problems running our own Synapse daemon server. It's a debian stable xen PV VM stored on a LVM logical volume, so easily moved between hypervisors, or cloned, if ever necessary. It runs at a load average of 0.01.
In my specific ISP environment it's the same person that admins the X.509 private root CA PKI so we're well equipped to deal with running it in a purely intranet environment with no access to the global routing table.
For widespread non technical random end user use? Totally agreed it's not ready yet.
An "internally-run-Slack" is definitely a great use case for Matrix in its current form. I don't own a business, but if I did, I would almost certainly consider running my own Synapse server, just to have a stronger guarantee that internal chats stay internal.
Yes at my bigco they've set up a whole matrix (rebranded) service. Great. Only thing I miss is some kind of 'ephemeral chatroom' option, where nothing is saved or expires after some time. Some conversations are not worth saving and wading through all the chat logs to find some stuff can be painful.
Also I like the other tools' (cisco jabber and some others) option to save chat logs in exchange folders, so you have local search indexation/capabilities.
On the other side, I'd also like a button to record a whole conf-call, so minutes of meetings can be backed up with the actual conversation. Yes, how 'trusting' of me...
Also I like the other tools' (cisco jabber and some others) option to save chat logs in exchange folders, so you have local search indexation/capabilities.
On the other side, I'd also like a button to record a whole conf-call, so minutes of meetings can be backed up with the actual conversation. Yes, how 'trusting' of me...
It's an sqlite database on disk, so in our case fairly easy to know exactly where the data lives, and keep it secure.
I'm not worried about people that I moved to signal "grumbling" about being moved again to Matrix. If the Signal move was successful it should build confidence in future moves.
The killer app for Matrix for most people won't be ability to run your own home server, but the easy generalization of Matrix to things like Reddit/HN with good integration with 1-1 chat someday will be. Also organizational usage. That of course is way cooler than Signal "not being facebook". So biding our time is fine.
When the time does come, we should probably campaign for HN to be officially bridged with Matrix too :D.
The killer app for Matrix for most people won't be ability to run your own home server, but the easy generalization of Matrix to things like Reddit/HN with good integration with 1-1 chat someday will be. Also organizational usage. That of course is way cooler than Signal "not being facebook". So biding our time is fine.
When the time does come, we should probably campaign for HN to be officially bridged with Matrix too :D.
HN won't even get dark mode, so the only way we'd ever get Matrix on HN is through a random macroscopic quantum event.
It doesn't seem like these problems are fundamental to Matrix, though.
I agree that Element is not that good, but if you were to replace Signal's backend with Matrix, your experience would (could?) be nearly identical as Signal is now and we wouldn't have the issues of a closed ecosystem anymore.
I agree that Element is not that good, but if you were to replace Signal's backend with Matrix, your experience would (could?) be nearly identical as Signal is now and we wouldn't have the issues of a closed ecosystem anymore.
Ehhh, Matrix is more than a transport protocol though, it lives a lot higher up the stack. It would be akin to trying to make Signal into a Slack client. So you’re basically saying “if you paper over all the weirdness of Matrix with a better UI” which is easier said than done.
Nobody thinks about it but the most professionally used communication medium is the email, and part if not all of its success if not all its success is that is decentralized.
A company cannot afford to use a service that can be closed and loose all the communications. Centralized services are single point of failure, and in that regard Signal is no better than WhatsApp, because yes, in theory you can run your own server, but have you tried to do so?
It's not practical or even endorsed by the Signal creators themself, since there is no way in the clients to make them connect to your server instead of the centralized one.
Another bad thing of Signal is the use of a phone number as the authentication method. A phone number is not something that preserves your privacy. Well in theory in countries where you can go into a shop and buy a SIM card cash yes, but in a lot of countries you have to give your ID. Another aspect in which email is just better.
A company cannot afford to use a service that can be closed and loose all the communications. Centralized services are single point of failure, and in that regard Signal is no better than WhatsApp, because yes, in theory you can run your own server, but have you tried to do so?
It's not practical or even endorsed by the Signal creators themself, since there is no way in the clients to make them connect to your server instead of the centralized one.
Another bad thing of Signal is the use of a phone number as the authentication method. A phone number is not something that preserves your privacy. Well in theory in countries where you can go into a shop and buy a SIM card cash yes, but in a lot of countries you have to give your ID. Another aspect in which email is just better.
> Well in theory in countries where you can go into a shop and buy a SIM card cash yes, but in a lot of countries you have to give your ID
another huge problem with using phone numbers as IDs, which software developers in the US/Canada often don't think about, is that in many developing nation environments there is no such thing as local number portability, or the ability to move your phone number between any of the major national-scale mobile phone network operators or VoIP providers as you wish.
As you can do in the USA if you become unsatisfied with your Tmobile service and want to move to ATT, keeping your phone number. This is one of the reasons why dual (and even triple) SIM phones are so popular outside of North America.
In a lot of countries I don't see number portability in the SS7/PSTN system ever becoming a political reality, due to regulatory capture on the part of the national telecom regulator. At least not before pure IP based communications and apps make the concept of a PSTN phone number irrelevant entirely.
another huge problem with using phone numbers as IDs, which software developers in the US/Canada often don't think about, is that in many developing nation environments there is no such thing as local number portability, or the ability to move your phone number between any of the major national-scale mobile phone network operators or VoIP providers as you wish.
As you can do in the USA if you become unsatisfied with your Tmobile service and want to move to ATT, keeping your phone number. This is one of the reasons why dual (and even triple) SIM phones are so popular outside of North America.
In a lot of countries I don't see number portability in the SS7/PSTN system ever becoming a political reality, due to regulatory capture on the part of the national telecom regulator. At least not before pure IP based communications and apps make the concept of a PSTN phone number irrelevant entirely.
On the other hand, email is the single largest causes of cyber attacks.
The communication is not E2E encrypted (apart from a few GPG/SMIME users), no forward secrecy and barely any signature checks. Even if outlook, thunderbird maybe supports it, goodluck getting all the mobile versions to support it too.
The clients used to view emails suffer from the same problem with browsers so are subject to all the HTML/JS/CSS privacy attacks.
I wish all companies would move to something centralized solution where communication is guaranteed to only come from those within the same service. This way Sharon from HR won't open every link, download every crypto/ransomeware.
Maybe my IT could also save 150k a year by not having to send me phishing 'training' emails and instead deal with some decent forms of signature checking. Heck billions of dollars a year are wasted because of phishing, spam, crypto attacks because of email.
From my perspective, email is a shitty legacy tech from 1990s that should be moved to a modern solution that enables E2E encryption or signature checks at a minimum.
The communication is not E2E encrypted (apart from a few GPG/SMIME users), no forward secrecy and barely any signature checks. Even if outlook, thunderbird maybe supports it, goodluck getting all the mobile versions to support it too.
The clients used to view emails suffer from the same problem with browsers so are subject to all the HTML/JS/CSS privacy attacks.
I wish all companies would move to something centralized solution where communication is guaranteed to only come from those within the same service. This way Sharon from HR won't open every link, download every crypto/ransomeware.
Maybe my IT could also save 150k a year by not having to send me phishing 'training' emails and instead deal with some decent forms of signature checking. Heck billions of dollars a year are wasted because of phishing, spam, crypto attacks because of email.
From my perspective, email is a shitty legacy tech from 1990s that should be moved to a modern solution that enables E2E encryption or signature checks at a minimum.
> I wish all companies would move to something centralized solution where communication is guaranteed to only come from those within the same service. This way Sharon from HR won't open every link, download every crypto/ransomeware.
It's totally possible to set up 'email' for intranet purposes only, using your own DNS setup, standards compliant smtpd and imap daemons over TLS. The persons using it just need to know it can't send or receive emails from outside of the organization.
It's totally possible to set up 'email' for intranet purposes only, using your own DNS setup, standards compliant smtpd and imap daemons over TLS. The persons using it just need to know it can't send or receive emails from outside of the organization.
It's possible, but every company security, tech otherwise is not setup like this.
Frankly, I am just happy slack is picking up the slack here.
Frankly, I am just happy slack is picking up the slack here.
A Lets Encrypt for email certs is badly needed.
Haha, I love the angry honesty in this post. That's exactly how I feel. I think it's possible that we can get the UX right for a chat app based on a decentralized protocol such as Matrix some time in the future, but that's just not the case today.
And today, I'd rather have everyone using Signal instead of WhatsApp. Yes, Signal might go evil in the future, but we'll deal with it then. In the meantime let's improve our decentralized chat systems. And as this current period shows, it's absolutely possible for a lot of people to quickly switch from one social network to another.
And today, I'd rather have everyone using Signal instead of WhatsApp. Yes, Signal might go evil in the future, but we'll deal with it then. In the meantime let's improve our decentralized chat systems. And as this current period shows, it's absolutely possible for a lot of people to quickly switch from one social network to another.
It turns out that decentralization closes the door on top-down censorship, but at the same time, invites spam and abuse of the system for personal gain. It's very easy to do this in a decentralized model, and every single decentralized service suffers from this. IRC, Email, Mastodon, you name it. It's all bad.
The footnote[1] project helps to provide spam and abuse by limiting each user to 10 MB.
[1] https://github.com/kyokan/footnote/
[1] https://github.com/kyokan/footnote/
The solution is simple. Make the decentralized systems social, with reputation.
And that then is extremely easy to abuse as soon as you have enough people with high rank enough deciding to start to misbehave.
It even happens in the real world too. I remember one guy who had been on eBay or something for years working up a huge positive karma, and then one day a switch flipped and he disappeared with everyone's money and was never seen again.
Sounds like IRL
Turns out most problems are people problems, not tech problems. Tech is just how the symptoms present.
[deleted]
If everything revolves around people I give authority to (my "friends") then any attempt to game my feed is going to result in a swift defriend. Problem solved.
“If you like my post I will like yours.” We can’t have many nice things, it’s human nature.
How do you prevent bots giving each other reputation?
Some strategies:
Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot.
Implement Sybil resistance with a combination of verifiable cost and blacklisting. Make it cost real verifiable resources to create an identity (hashcash or Bitcoin burning or something) and then have a system for blacklisting fake IDs.
Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot.
Implement Sybil resistance with a combination of verifiable cost and blacklisting. Make it cost real verifiable resources to create an identity (hashcash or Bitcoin burning or something) and then have a system for blacklisting fake IDs.
> Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot.
This is just 'web of trust', right? https://en.wikipedia.org/wiki/Web_of_trust
This is just 'web of trust', right? https://en.wikipedia.org/wiki/Web_of_trust
I can't believe I'm suggesting this, but maybe trade it through cryptocurrency. Pay a few bucks to create an account. It might get expensive to start a server and have others agree to federate with you though.
Could also just use regular money.
Could also just use regular money.
By punishing their connections when they misbehave.
Or at least, that's how you make it not matter. If spam-bot hands out reputation to spim-bot and then you get a bunch of garbage from spim-bot, derate everything coming from anyone that has given either of them reputation (and perhaps ignore their attestations also).
Or at least, that's how you make it not matter. If spam-bot hands out reputation to spim-bot and then you get a bunch of garbage from spim-bot, derate everything coming from anyone that has given either of them reputation (and perhaps ignore their attestations also).
Now what happens when spam is done through a compromised user, or when the user acts human and has real interactions before spamming?
I suppose it depends on the details quite a lot.
But fundamentally, it isn't particularly harmful to just burn a user that starts spamming. If a compromised account is recovered, it's fine if they have to restore communication out of band, if it isn't recovered it's fine that it is burned.
But fundamentally, it isn't particularly harmful to just burn a user that starts spamming. If a compromised account is recovered, it's fine if they have to restore communication out of band, if it isn't recovered it's fine that it is burned.
Will the arbiter of reputations be central or decentralized?
If each person controls the authority they provide to others (via friending, upvotes, etc) then the system can't be mass gamed, which is enough to deter most bad behavior.
I see a lot more witch hunts these days than I did 10 years ago, and most of them are as principled as the days when they were with torches and pitchforks. If I came across a system with a reputation-based feature it would be a red line I would definitely not cross.
It's not easy to do better. Sure, Moxie has has a strong opinions, but has reasoning behind it.
Not distributed or federated, because then you'll inevitable version drift, complex handshakes, more attack surface, different quality implementations, more risk to users, and overall a less secure system.
Requiring a sim, annoying, makes it easier to track people through whoever paid for the sim. However it does make it hard for an attacker to create millions of accounts and camp on user names.
Not distributed or federated, because then you'll inevitable version drift, complex handshakes, more attack surface, different quality implementations, more risk to users, and overall a less secure system.
Requiring a sim, annoying, makes it easier to track people through whoever paid for the sim. However it does make it hard for an attacker to create millions of accounts and camp on user names.
> Users value their convenience, and security and privacy are inconvenient.
True. A messenger will be widely adopted if it offers features that WhatsApp et al. don't have. And by that I don't mean security or privacy, but something that people actually care about, like the stickers in telegram for example. And then that messenger just needs to be secure without interfering with functionality, convenience or UX ... problem solved.
True. A messenger will be widely adopted if it offers features that WhatsApp et al. don't have. And by that I don't mean security or privacy, but something that people actually care about, like the stickers in telegram for example. And then that messenger just needs to be secure without interfering with functionality, convenience or UX ... problem solved.
> If we could do better, we would have done better by now.
We should have given up on Linux UIs way back then. They're still garbage when it compares to the alternatives.
We should have given up on Linux UIs way back then. They're still garbage when it compares to the alternatives.
> Hell, we /started/ decentralized and over email and newsgroups and personal websites and blogs and it's all Facebook Facebook Facebook now that the Eternal September came around.
We didn't do the decentralization then because of good politics and security: look how bad the other security properties were. Rather we did it because the field was new and the actors not consolidated.
Creating decentralization after in a mature, consoliditated space is a completely different enterprise. In particular, a lot more attention needs to paid to inefficiency and defense against the central hegemons.
It's a hard battle, but if won, will be a much more durable victory.
We didn't do the decentralization then because of good politics and security: look how bad the other security properties were. Rather we did it because the field was new and the actors not consolidated.
Creating decentralization after in a mature, consoliditated space is a completely different enterprise. In particular, a lot more attention needs to paid to inefficiency and defense against the central hegemons.
It's a hard battle, but if won, will be a much more durable victory.
These are all complaints about the app's UI, not Matrix or federated networks.
> If we could do better, we would have done better by now.
I'm guessing you might have said something similar about a non-profit running a massively popular chat application 5 years ago.
The only pieces missing now are interoperability and community involvement.
> If we could do better, we would have done better by now.
I'm guessing you might have said something similar about a non-profit running a massively popular chat application 5 years ago.
The only pieces missing now are interoperability and community involvement.
We need to think of ways to run the various Matrix, Mastodon, peertube etc in tiny boxes in our homes! There is no real reason for not promoting self hosting. The same way i buy a small Nas or an amazon firetv stick, with apps, I would buy a small box with pihole, mastodon and matrix.
Have you tried running Mastodon and Matrix on a Pi? I'm not so confident it'd work, these aren't lean servers.
I would love a tiny server I can run on my home server (for my tiny message volume), but Mastodon and Synapse are optimized for large servers.
I would love a tiny server I can run on my home server (for my tiny message volume), but Mastodon and Synapse are optimized for large servers.
synapse is actually quite tiny, but its use of an sqlite db on disk and other disk-write related activities, over a long term of months or years, seems quite likely to destroy a raspberry pi microsd card in much the same way that ordinary logging will destroy a microsd card. yes the rpi4 can boot from a USB-connected 'real' sata device now, which is an improvement.
> synapse is actually quite tiny
Hmm, is it really? My server has a SSD so I don't care about writes, I just want it to be low on CPU and memory requirements.
Hmm, is it really? My server has a SSD so I don't care about writes, I just want it to be low on CPU and memory requirements.
an entire synapse with its python environment is about 150MB of disk space occupied, before any user data starts getting written to the database.
chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3.
this same machine also has a minimal nginx setup as the standard reverse proxy configuration for TLS1.2/TLS1.3 in front of the synapse daemon, which isn't set up for any crypto and only listens on localhost.
chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3.
this same machine also has a minimal nginx setup as the standard reverse proxy configuration for TLS1.2/TLS1.3 in front of the synapse daemon, which isn't set up for any crypto and only listens on localhost.
It's worth noting that this sounds to be an unfederated server.
The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources.
The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.
The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources.
The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.
Yes, absolutely, this is for company internal use only. I imagine the resources for a server that talks to the outside world are much greater.
I have tried it on a RPi3 and it is painfully slow. I would not recommend this to anyone.
There's been work on integrating the server and client together in a p2p fashion.
Then you are essentially self-hosting on your phone/laptop when you run the client.
Then you are essentially self-hosting on your phone/laptop when you run the client.
one of the challenges with that from the perspective of an ISP, is that residential broadband connections are very often highly asymmetric in bandwidth.
for example on two of north america's largest DOCSIS3/DOCSIS3.1 based cable modem operators, you can get 200-600 Mbps downstream speeds, but uploads may max out at 16-18 Mbps. Depending on your exact location. This is because of how RF channels are bonded together by the CMTS operator.
lots of other access technologies will face significant challenges and capacity constraints if a sizeable percentage of residential broadband end users start trying to actually use their upstream bandwidth at a greater rate than they do now, when averaged over the traffic for hundreds or thousands of individual end point users.
for example on two of north america's largest DOCSIS3/DOCSIS3.1 based cable modem operators, you can get 200-600 Mbps downstream speeds, but uploads may max out at 16-18 Mbps. Depending on your exact location. This is because of how RF channels are bonded together by the CMTS operator.
lots of other access technologies will face significant challenges and capacity constraints if a sizeable percentage of residential broadband end users start trying to actually use their upstream bandwidth at a greater rate than they do now, when averaged over the traffic for hundreds or thousands of individual end point users.
Which is more or less verbatim addressed in the article...
"While that is somewhat true — at least by the metric of “secure messengers your granny can use”, there are some promising alternatives who are especially focused on decentralizing E2EE communications.
Nobody's saying there's a better alternative already, which seems to be your main gripe. The point is that Signal's model is still imperfect, and it's worth improving upon.
>If we could do better, we would have done better by now.
To claim this regarding tech, of all fields? I seriously can't imagine what would have to happen to make me think that everything has already been invented, and what we've got now is the best we'll ever get.
"While that is somewhat true — at least by the metric of “secure messengers your granny can use”, there are some promising alternatives who are especially focused on decentralizing E2EE communications.
Nobody's saying there's a better alternative already, which seems to be your main gripe. The point is that Signal's model is still imperfect, and it's worth improving upon.
>If we could do better, we would have done better by now.
To claim this regarding tech, of all fields? I seriously can't imagine what would have to happen to make me think that everything has already been invented, and what we've got now is the best we'll ever get.
I agree with this. Even Signal is just barely this year entering in the realm of practically useable for most of my friends and family.
I'm not so sure. It really hasn't been that long in a generational sense that the internet has been around. Society may still be in the honeymoon phase of it's relationship with the internet. If building network services was like building houses, we may not be anywhere near drywall.
Who is the "we" who can't do better, just technologists? Or humanity as a whole? Is it all just a demand side problem, and the people chose centralization, or was centralization a matter of policy for some group of sufficient influence? Is it just a byproduct of unfettered capitalism? A conspiracy to make the internet less 'libre' by a powerful special interest looking to profit (or a three letter agency looking to snoop) isn't outside the realm of possibility, is it?
Anyway, I guess my point is that there are a lot of different factors that got us to this moment, and as people say, change is the only constant. I don't think anyone should give up on their ideas for the future, even if they've been tried without success before in some form.
Who is the "we" who can't do better, just technologists? Or humanity as a whole? Is it all just a demand side problem, and the people chose centralization, or was centralization a matter of policy for some group of sufficient influence? Is it just a byproduct of unfettered capitalism? A conspiracy to make the internet less 'libre' by a powerful special interest looking to profit (or a three letter agency looking to snoop) isn't outside the realm of possibility, is it?
Anyway, I guess my point is that there are a lot of different factors that got us to this moment, and as people say, change is the only constant. I don't think anyone should give up on their ideas for the future, even if they've been tried without success before in some form.
Skype was good when it used to be p2p... but when Microsoft bought it, they changed how it works.
One of the root causes for centralization is that we lost the ability to make our devices talk directly to each other.
Before the Internet, people could contact each other directly by just making phone calls, and the phone network was neutral, so any phone or any network could call any other (even internationally) provided they pay the fee. Same with SMS and MMS.
With the early Internet, every computer had an IP address and could send packets to any other one.
With the late Internet, because of NAT and unwillingness of ISPs to make progress on this issue, we've now lost that ability and now always require some kind of central coordination server for devices to be able to talk (through it).
There is no reason why Signal (or any other messenger) requires a central server if it wasn't for this. Provided you have the person in your contacts (by having their IP address + a crypto fingerprint for authenticity) they should be able to talk directly.
Until we solve this issue, decentralized alternatives (such as Matrix, Mastodon, and others) are just bad workarounds that will never catch on because people aren't willing (and shouldn't have to) host a server (or use a sometimes unreliable benevolent one or a paid one) when they've already got a smartphone and are paying their phone/Internet bill.
Before the Internet, people could contact each other directly by just making phone calls, and the phone network was neutral, so any phone or any network could call any other (even internationally) provided they pay the fee. Same with SMS and MMS.
With the early Internet, every computer had an IP address and could send packets to any other one.
With the late Internet, because of NAT and unwillingness of ISPs to make progress on this issue, we've now lost that ability and now always require some kind of central coordination server for devices to be able to talk (through it).
There is no reason why Signal (or any other messenger) requires a central server if it wasn't for this. Provided you have the person in your contacts (by having their IP address + a crypto fingerprint for authenticity) they should be able to talk directly.
Until we solve this issue, decentralized alternatives (such as Matrix, Mastodon, and others) are just bad workarounds that will never catch on because people aren't willing (and shouldn't have to) host a server (or use a sometimes unreliable benevolent one or a paid one) when they've already got a smartphone and are paying their phone/Internet bill.
> Before the Internet, people could contact each other directly by just making phone calls, and the phone network was neutral, so any phone or any network could call any other (even internationally) provided they pay the fee.
the more you learn about SS7 and the traditional phone network the worse it looks. it's actually held together with the metaphorical equivalent of duct tape and string, and is highly centralized...
the more you learn about SS7 and the traditional phone network the worse it looks. it's actually held together with the metaphorical equivalent of duct tape and string, and is highly centralized...
I'm not talking about the security or reliability aspects of it - you are right about those (though Internet isn't much better, see BGP). But when it works as intended, the telephone "world" offers something that the Internet world often no longer offers: end-to-end connectivity.
Even the cheapest phone plan will come with a phone number that's reachable from anywhere and can reach anywhere (provided you pay the call fee). Most consumer-grade internet plans come with a single, dynamic IPv4 and no IPv6 (or the IPv6 prefix is also dynamic). No end-to-end connectivity is possible unless you engage in some NAT traversal workarounds that require an external server.
Even the cheapest phone plan will come with a phone number that's reachable from anywhere and can reach anywhere (provided you pay the call fee). Most consumer-grade internet plans come with a single, dynamic IPv4 and no IPv6 (or the IPv6 prefix is also dynamic). No end-to-end connectivity is possible unless you engage in some NAT traversal workarounds that require an external server.
That's a very good point, and if you look at ordinary residential end user broadband services in many developing nations, where the ISPs long ago ran out of IPv4 resources to assign each customer a /32 from a DHCP pool, you don't even get a real ARIN/RIPE/APNIC/AFRINIC/whatever dynamic v4 anymore but an IP on your WAN interface that's in carrier grade NAT IP space, already behind one NAT, before any small home/office routers for wifi are introduced into the setup.
Well put. this is a core issue.
Apple also require all push notifications go through their servers btw. Afair
Apple also require all push notifications go through their servers btw. Afair
I disagree. A decentralized version of Signal might not be necessarily more reliable. What do you do when your Matrix home server is down? Will you still be able to log in? Receive messages? Is this overall system more stable if only 90% of the network work all the time?
Apart from that, most non-technical users won't care about it, and a decentralized solution might not be as convenient for them. It also might open up other attack vectors, like compromised servers in the network and stuff like that.
Signal is probably the best solution for now.
Apart from that, most non-technical users won't care about it, and a decentralized solution might not be as convenient for them. It also might open up other attack vectors, like compromised servers in the network and stuff like that.
Signal is probably the best solution for now.
I'd argue that vendor lock-in is a far more important issue.
You're right that non-technical people won't care about why decentralization matters. It's up to technical people to nudge the boat in the right direction.
That's why it's so disappointing to see HN embrace another silo.
You're right that non-technical people won't care about why decentralization matters. It's up to technical people to nudge the boat in the right direction.
That's why it's so disappointing to see HN embrace another silo.
I never understood what problem E2E encryption actually solves if you don't have full control over the client. All it would take Signal or WhatsApp to extract all your private messages is a single update of the client, which is trivial to do and currently very hard to validate as e.g. Apple does not even (to my knowledge) provide checksums to end users.
The problem of messaging as it is today is that we missed the opportunity to create a well-accepted federated protocol that can be implemented easily. There were a few contenders like IRC but they never reached a critical mass like SMTP or IMAP did. Maybe Matrix can fix this, but I don't have much hope we'll turn away from WhatsApp anytime soon, 95 % of users don't care enough to change and the lock-in effects are enormous at this point. The only way that this situation could be resolved is through legislation, e.g. the EU forcing WhatsApp to implement the Matrix protocol and make their infrastructure interoperable with third-party providers, but even that seems quite far-fetched right now.
In any case, having a non-profit like the Signal foundation run a messenger is already a vast improvement over a company that sees this mostly as a data mining operation.
The problem of messaging as it is today is that we missed the opportunity to create a well-accepted federated protocol that can be implemented easily. There were a few contenders like IRC but they never reached a critical mass like SMTP or IMAP did. Maybe Matrix can fix this, but I don't have much hope we'll turn away from WhatsApp anytime soon, 95 % of users don't care enough to change and the lock-in effects are enormous at this point. The only way that this situation could be resolved is through legislation, e.g. the EU forcing WhatsApp to implement the Matrix protocol and make their infrastructure interoperable with third-party providers, but even that seems quite far-fetched right now.
In any case, having a non-profit like the Signal foundation run a messenger is already a vast improvement over a company that sees this mostly as a data mining operation.
Signal’s Android client moved to reproducible builds some time ago already.
>what problem E2E encryption actually solves
Pervasive, passive surveillance. If your threat model includes individually targeted exploits, then you'll need to look for other solutions.
Pervasive, passive surveillance. If your threat model includes individually targeted exploits, then you'll need to look for other solutions.
You don't need E2E encryption for that, transport layer encryption will do just fine in that case.
The transport between where and where?
Can anyone closer to development of Signal (or who works on it) comment on why the server code was last updated in April (7 months ago https://github.com/signalapp/Signal-Server)?
Has _all_ development been client side?
Has _all_ development been client side?
I might be mistaken but I think someone wrote here a few days ago that they noticed the Server being updated but that the github repo doesn't reflect those changes.
I think that the GitHub repos are a copy of their internal VCS that aren't necessarily updated frequently.
I'm confused about this piece. If there's true E2E encryption (verified by open source client code and review of released binaries) then why does it matter if the server code is backdoored or not? The whole point of E2E is that you don't need to care about the server being able to ever see the text of your messages because it never can.
It's certainly much better than the norm! But there's also metadata retention, which Signal frequently brags about being good at not doing, but which is unverifiable unless it's you serving the warrant and coming up disappointed.
Copy pasting my comment:
Consider this paragraph from the Signal protocol
> ...For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document.
> If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.
Nobody I know in practice does this authentication. If an active attack is carried out, I'm reasonably sure people would not notice.
Consider this paragraph from the Signal protocol
> ...For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document.
> If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.
Nobody I know in practice does this authentication. If an active attack is carried out, I'm reasonably sure people would not notice.
It might be solvable with an external identity server that keeps the ID + key of users, but then you just move the problem of trust to another party.
Additionally, that ID+key would have to be updated somehow by the user and now you have a new problem: how do you verify that the user is who they say they are? Telling them to digitally sign something is possible, but what if the private key is gone?
The Signal protocol solves what it can solve for now. If cryptography experts have suggestions to improve it, I'm sure they can contribute.
Is there any protocol that solves the issue you're describing? And that has a good app? And that isn't centralized? We're asking for the "eierlegende Wollmilchsau" aka unicorn.
Additionally, that ID+key would have to be updated somehow by the user and now you have a new problem: how do you verify that the user is who they say they are? Telling them to digitally sign something is possible, but what if the private key is gone?
The Signal protocol solves what it can solve for now. If cryptography experts have suggestions to improve it, I'm sure they can contribute.
Is there any protocol that solves the issue you're describing? And that has a good app? And that isn't centralized? We're asking for the "eierlegende Wollmilchsau" aka unicorn.
Matrix has the same problem. It requires out-of-band communication to trust the E2E encryption.
Indeed, EVERY decentralized communications system will have this problem. There's no way to establish trust over a compromised channel without either a centralized pre-trusted agent (like the CA system in TLS) or an out-of-band secure channel (like Signal, Matrix, PGP, etc).
Indeed, EVERY decentralized communications system will have this problem. There's no way to establish trust over a compromised channel without either a centralized pre-trusted agent (like the CA system in TLS) or an out-of-band secure channel (like Signal, Matrix, PGP, etc).
>If an active attack is carried out, I'm reasonably sure people would not notice.
If the attack happened after you have started communicating wouldn't you get a notification that the key of those you're communicating with has changed? An attack would only be invisible if it happened from the first communication. But unless it's very targeted someone somewhere would compare the keys and notice.
If the attack happened after you have started communicating wouldn't you get a notification that the key of those you're communicating with has changed? An attack would only be invisible if it happened from the first communication. But unless it's very targeted someone somewhere would compare the keys and notice.
> An attack would only be invisible if it happened from the first communication.
This is the scenario I'm talking about.
This is the scenario I'm talking about.
I'd argue that if you're currently the target of a government you should take the time to verify the cryptographic signatures at least every so often. Any platform you use they could have gotten to the servers or the owners of the servers. Hell, they could patch the servers in memory so there's never any trace in source code.
I can't see how this is a problem on its own.
If they were eschewing some better option than "don't trust the server", that would be a problem, but is there a better option?
If they were eschewing some better option than "don't trust the server", that would be a problem, but is there a better option?
Yes, the solution is … allow the protocol to let people run their own servers?
It's the Signal app that depends on their server, there isn't anything in the protocol that stops someone from building an app that talks to other servers.
It's kind of fascinating, they have done a pretty good job of laying out their goals, easy contact discovery, forced protocol upgrades, etc, and people come up with all these improvements they could make by just setting aside those goals.
It's kind of fascinating, they have done a pretty good job of laying out their goals, easy contact discovery, forced protocol upgrades, etc, and people come up with all these improvements they could make by just setting aside those goals.
Wouldn't it just take 1 person doing the verification on a new message to catch this though?
Not if it's targeted towards a particular pair of people.
There is some key exchange, pregeneration, and signing smarts involved with the server for all new communications at the initial connection. The net result is either everyone on your contacts was faked or nobody was (or you get a message when only 1 is intercepted on conversation setup).
That being said it's possible for all of Bob's contacts to have been MITM but not all of Carol's so each person does have to check at least one conversation to be sure.
That being said it's possible for all of Bob's contacts to have been MITM but not all of Carol's so each person does have to check at least one conversation to be sure.
Do we have a way to verify that the App Store apps are actually running the open source (as published) code?
Builds on Android have been (mostly) reproducible since 2016: https://signal.org/blog/reproducible-android/
Looks like the situation is more complicated and still unresolved for iOS: https://github.com/signalapp/Signal-iOS/issues/641
Looks like the situation is more complicated and still unresolved for iOS: https://github.com/signalapp/Signal-iOS/issues/641
Interesting! Thanks for the links.
> If there's true E2E encryption ... why does it matter if the server code is backdoored or not?
Meta-data: Log of who called whom, when and for how long. Also, user account details.
Meta-data: Log of who called whom, when and for how long. Also, user account details.
The issues highlighted by the author, about Signal, and indeed nearly any messenger app or platform, are societal issues that we keep trying to fix with technology.
There are promising solutions to decentralizing and anonymizing but there remain to be any real tech solutions to the ultimate de-platforming issue. Signal is at risk of having their hosting or connection removed. What prevents the same thing from happening to decentralized services? ISPs have already shown willingness to censor. A decentralized service is at just as much risk of being blocked in a game of whackamole. Or having the apps needed for access removed from major mobile platforms. Apple already blocks magnet links on Safari for iOS. What stops them from blocking a webapp for one of these services?
We need strong laws and regulations protecting everyone’s right to telecommunication infrastructure and the right to install and run our own code on end user devices to prevent another Parler.
There are promising solutions to decentralizing and anonymizing but there remain to be any real tech solutions to the ultimate de-platforming issue. Signal is at risk of having their hosting or connection removed. What prevents the same thing from happening to decentralized services? ISPs have already shown willingness to censor. A decentralized service is at just as much risk of being blocked in a game of whackamole. Or having the apps needed for access removed from major mobile platforms. Apple already blocks magnet links on Safari for iOS. What stops them from blocking a webapp for one of these services?
We need strong laws and regulations protecting everyone’s right to telecommunication infrastructure and the right to install and run our own code on end user devices to prevent another Parler.
> What prevents the same thing from happening to decentralized services?
Nothing, but at least knocking a server offline doesn't bring down the whole network, which is indeed "better than Signal" on this front.
Nothing, but at least knocking a server offline doesn't bring down the whole network, which is indeed "better than Signal" on this front.
I don't think it's clear that a federated service has better chances against censorship.
Take any federated service: if you ban the servers accounting for 90% of users, you end up in a situation mostly similar to censoring Signal, you need to migrate servers and accounts somehow. This should be easier for a centralized service (Signal) since they control everything. Banning servers that belong to n entities where n > 1 might be a bit more of a hurdle, but if n < 20 it's also not that much harder. Do we really expect that many prominent matrix servers, given how centralized email has ended up being?
P2P on Matrix has been mentioned, and might be more resistant to censorship, but figuring out the UX in this case is pretty much an open problem (e.g. resetting your "address" whenever your reset your main device and lose your data is not acceptable).
Also good to remember regarding centralized services: The Pirate Bay is still up and running. Will there be more pressure on Signal to close than The Pirate Bay?
Take any federated service: if you ban the servers accounting for 90% of users, you end up in a situation mostly similar to censoring Signal, you need to migrate servers and accounts somehow. This should be easier for a centralized service (Signal) since they control everything. Banning servers that belong to n entities where n > 1 might be a bit more of a hurdle, but if n < 20 it's also not that much harder. Do we really expect that many prominent matrix servers, given how centralized email has ended up being?
P2P on Matrix has been mentioned, and might be more resistant to censorship, but figuring out the UX in this case is pretty much an open problem (e.g. resetting your "address" whenever your reset your main device and lose your data is not acceptable).
Also good to remember regarding centralized services: The Pirate Bay is still up and running. Will there be more pressure on Signal to close than The Pirate Bay?
Tech solutions to deplatforming will involve changes to how reward mechanisms work (ie Likes/Views/Clicks/Followers etc). No one needs to get banned but they can be thrown in the drunk tank (so no rewards ie Likes/Views/Clicks/Followers etc) for some period depending on offense type, seriousness, what have you.
Currently getting agreement on Reward mechanisms when no one trusts anyone is complicated. But it will happen eventually after more and more shit hits the fan.
Currently getting agreement on Reward mechanisms when no one trusts anyone is complicated. But it will happen eventually after more and more shit hits the fan.
For the longest time, Signal wouldn’t work without Google Play Services, but Moxie (the founder of Open Whisper Systems and maintainer of Signal) finally fixed this in 2017. There was also a long time when Signal was only available on the Google Play Store.
Why do I make a big deal out of Google Play and Google Play Services? Well, some people might trust Google, the company. But up against nation states, it’s no contest - Google has ties to the NSA, has been served secret subpoenas, and is literally the world’s largest machine designed for harvesting and analyzing private information about their users. Here’s what Google Play Services actually is: a rootkit. Google Play Services lets Google do silent background updates on apps on your phone and give them any permission they want. Having Google Play Services on your phone means your phone is not secure.
Moxie, why haven’t you put Signal on F-Droid yet?
Truly secure systems do not require you to trust the service provider. This is the point of end-to-end encryption. But we have to trust that Moxie is running the server software he says he is. We have to trust that he isn’t writing down a list of people we’ve talked to, when, and how often. We have to trust not only that Moxie is trustworthy, but given that Open Whisper Systems is based in San Francisco we have to trust that he hasn’t received a national security letter, too (by the way, Signal doesn’t have a warrant canary). Moxie can tell us he doesn’t store these things, but he could. Truly secure systems don’t require trust.
Why do I make a big deal out of Google Play and Google Play Services? Well, some people might trust Google, the company. But up against nation states, it’s no contest - Google has ties to the NSA, has been served secret subpoenas, and is literally the world’s largest machine designed for harvesting and analyzing private information about their users. Here’s what Google Play Services actually is: a rootkit. Google Play Services lets Google do silent background updates on apps on your phone and give them any permission they want. Having Google Play Services on your phone means your phone is not secure.
Moxie, why haven’t you put Signal on F-Droid yet?
Truly secure systems do not require you to trust the service provider. This is the point of end-to-end encryption. But we have to trust that Moxie is running the server software he says he is. We have to trust that he isn’t writing down a list of people we’ve talked to, when, and how often. We have to trust not only that Moxie is trustworthy, but given that Open Whisper Systems is based in San Francisco we have to trust that he hasn’t received a national security letter, too (by the way, Signal doesn’t have a warrant canary). Moxie can tell us he doesn’t store these things, but he could. Truly secure systems don’t require trust.
Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, there are no third-party applications which can interact with Signal users in any way. Moxie can write as many blog posts which appeal to wispy ideals and “moving ecosystems” as he wants5, but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
It's not like his motives are secret. He's been straightforward about his stance, however much I disagree with it.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
> Moxie, why haven’t you put Signal on F-Droid yet?
There's no security benefit in having Signal on F-Droid instead of using https://signal.org/android/apk/.
I don't think Signal would say much if F-Droid distributed this APK directly (instead of a recompiled version with a different signature). It's just complicated to set up, which is why (I think) nobody has done it.
> But we have to trust that Moxie is running the server software he says he is.
I don't understand what you're suggesting instead. There's no practical solution to this problem.
> Signal doesn’t have a warrant canary
Warrant canaries are legally untested.
> Truly secure systems don’t require trust.
Can you give an example of a truly secure system? What's your threat model?
There's no security benefit in having Signal on F-Droid instead of using https://signal.org/android/apk/.
I don't think Signal would say much if F-Droid distributed this APK directly (instead of a recompiled version with a different signature). It's just complicated to set up, which is why (I think) nobody has done it.
> But we have to trust that Moxie is running the server software he says he is.
I don't understand what you're suggesting instead. There's no practical solution to this problem.
> Signal doesn’t have a warrant canary
Warrant canaries are legally untested.
> Truly secure systems don’t require trust.
Can you give an example of a truly secure system? What's your threat model?
> There's no security benefit in having Signal on F-Droid instead of
I don't know about Signal specifically but there is absolutely security benefits to hosting apks on F-Droid instead of your own home page.
F-Droid supports reproducible builds, so you can actively check that their build infrastructure is not compromised.
Signal seems to support some kind of reproducible builds on their own. Why that has not been integrated into the F-Droid build process I don't know. It seems like a large enough application to warrant the work.
But I suspect no one has stepped up to do the work, and given that Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change.
I don't know about Signal specifically but there is absolutely security benefits to hosting apks on F-Droid instead of your own home page.
F-Droid supports reproducible builds, so you can actively check that their build infrastructure is not compromised.
Signal seems to support some kind of reproducible builds on their own. Why that has not been integrated into the F-Droid build process I don't know. It seems like a large enough application to warrant the work.
But I suspect no one has stepped up to do the work, and given that Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change.
> Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change.
IIRC his main arguments were really a different signature and delays in updates.
Since these reasons will not exist anymore in the case of reproducible builds (the Signal app could still prompt for updates itself) from Signal being distributed on F-Droid, I don't think we can assume that Signal would not be fine with the APK distributed on F-Droid.
From a quick glance, the main reason left now seems to be that Signal still relies on the Play services libraries at compile-time (not necessarily at runtime), which are proprietary and thus not acceptable for F-Droid. Signal does not want to support a fork with these libraries completely removed.
IIRC his main arguments were really a different signature and delays in updates.
Since these reasons will not exist anymore in the case of reproducible builds (the Signal app could still prompt for updates itself) from Signal being distributed on F-Droid, I don't think we can assume that Signal would not be fine with the APK distributed on F-Droid.
From a quick glance, the main reason left now seems to be that Signal still relies on the Play services libraries at compile-time (not necessarily at runtime), which are proprietary and thus not acceptable for F-Droid. Signal does not want to support a fork with these libraries completely removed.
The benefit of running Signal on F-Droid is its secure update mechanism.
Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid?
Moxie has a complete stranglehold on the Signal system. You are completely at his mercy for all decisions affecting the platform
See:
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
The solution is federation, like email has always been.
There are a couple of ways to solve this problem, which can be used in tandem. We can stop Signal from knowing when we’re talking to each other by using peer-to-peer chats. This has some significant drawbacks, namely that both users have to be online at the same time for their messages to be delivered to each other. You can still fall back to peer-to-server-to-peer when one peer is offline, however. But this isn’t the most important of the two solutions.
The most important change is federation. Federated services are like email, in that Alice can send an email from gmail.com to Bob’s yahoo.com address. I should be able to stand up a Signal server, on my own hardware where I am in control of the logs, and communicate freely with other Signal servers, including Open Whisper’s servers. This distributes the security risks across hundreds of operators in many countries with various data extradition laws. This turns what would today be easy for the United States government to break and makes it much, much more difficult. Federation would also open the possibility for bridging the gap with several other open source secure chat platforms to all talk on the same federated network - which would spurn competition and be a great move for users of all chat platforms.
Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, there are no third-party applications which can interact with Signal users in any way. Moxie can write as many blog posts which appeal to wispy ideals and “moving ecosystems” as he wants5, but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid?
Moxie has a complete stranglehold on the Signal system. You are completely at his mercy for all decisions affecting the platform
See:
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
The solution is federation, like email has always been.
There are a couple of ways to solve this problem, which can be used in tandem. We can stop Signal from knowing when we’re talking to each other by using peer-to-peer chats. This has some significant drawbacks, namely that both users have to be online at the same time for their messages to be delivered to each other. You can still fall back to peer-to-server-to-peer when one peer is offline, however. But this isn’t the most important of the two solutions.
The most important change is federation. Federated services are like email, in that Alice can send an email from gmail.com to Bob’s yahoo.com address. I should be able to stand up a Signal server, on my own hardware where I am in control of the logs, and communicate freely with other Signal servers, including Open Whisper’s servers. This distributes the security risks across hundreds of operators in many countries with various data extradition laws. This turns what would today be easy for the United States government to break and makes it much, much more difficult. Federation would also open the possibility for bridging the gap with several other open source secure chat platforms to all talk on the same federated network - which would spurn competition and be a great move for users of all chat platforms.
Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, there are no third-party applications which can interact with Signal users in any way. Moxie can write as many blog posts which appeal to wispy ideals and “moving ecosystems” as he wants5, but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
> Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid?
I don't think it makes a practical difference.
> both users have to be online at the same time for their messages to be delivered to each other
Not only online but one has to be directly reachable, e.g. ping $IP works. With mobile connections it's rarely the case.
> on my own hardware where I am in control of the logs
That still means the users of your server trust you, you've just moved the problem. It only solves the problem for you as a user.
> This distributes the security risks across hundreds of operators in many countries with various data extradition laws.
I don't understand this argument: if a piece of (meta)data goes through one server and you think it's bad because this server can monitor this piece of data, then having multiple servers with various levels of accountability is arguably worse.
> those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
You are still not discussing why his reasons are bad according to you, so it's hard for people that have found the blog post convincing to change their mind.
I'm also curious as to which interests you're referring to, especially when we're talking about a non-profit that develop FOSS software.
I don't think it makes a practical difference.
> both users have to be online at the same time for their messages to be delivered to each other
Not only online but one has to be directly reachable, e.g. ping $IP works. With mobile connections it's rarely the case.
> on my own hardware where I am in control of the logs
That still means the users of your server trust you, you've just moved the problem. It only solves the problem for you as a user.
> This distributes the security risks across hundreds of operators in many countries with various data extradition laws.
I don't understand this argument: if a piece of (meta)data goes through one server and you think it's bad because this server can monitor this piece of data, then having multiple servers with various levels of accountability is arguably worse.
> those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
You are still not discussing why his reasons are bad according to you, so it's hard for people that have found the blog post convincing to change their mind.
I'm also curious as to which interests you're referring to, especially when we're talking about a non-profit that develop FOSS software.
A federated system design can be made to tolerate temporarily unreachable nodes. See email.
>Another response I usually see is “But Signal is all we have!”. While that is somewhat true — at least by the metric of “secure messengers your granny can use”, there are some promising alternatives who are especially focused on decentralizing E2EE communications.
So the author readily admits that these alternatives aren't actually good enough for the average user.
Newsflash: This IS for the average user! This is for my grandma and my cousins overseas who don't know anything about the internet! They don't know anything about "cryptoshit" or what "E2EE" stands for. Once you actually have something worthwhile that my grandma can use, then maybe you can claim it's better!
So the author readily admits that these alternatives aren't actually good enough for the average user.
Newsflash: This IS for the average user! This is for my grandma and my cousins overseas who don't know anything about the internet! They don't know anything about "cryptoshit" or what "E2EE" stands for. Once you actually have something worthwhile that my grandma can use, then maybe you can claim it's better!
If the average user was fine with the terrible clients which are Skype, Whatsapp and Facebook Messenger why should we hold Element to a higher standard?
Define terrible.
Oh, I’ll grant you the UI of these clients can be terrible. Facebook Messenger takes a shocking amount of resources.
But what’s the job to be done for most people? Chatting with friends. FB Messenger has the network effect built in. You can just message your friends. And send them goofy stickers.
What will get people to transition to an encrypted messenger where they have to duplicate their social network? Privacy? Yeah, OK, I am definitely going to get a friend to download a new app, create a new account, and go through whatever dance is necessary for encryption to ask if we want Mexican or Thai for dinner.
Oh, I’ll grant you the UI of these clients can be terrible. Facebook Messenger takes a shocking amount of resources.
But what’s the job to be done for most people? Chatting with friends. FB Messenger has the network effect built in. You can just message your friends. And send them goofy stickers.
What will get people to transition to an encrypted messenger where they have to duplicate their social network? Privacy? Yeah, OK, I am definitely going to get a friend to download a new app, create a new account, and go through whatever dance is necessary for encryption to ask if we want Mexican or Thai for dinner.
Personally I think element has a ways to go before it reaches the user friendlyness of even skype, the worst of those three.
The iOS app is a the most confusing chat app I've tried, especially if you run your own identity server.
The iOS app is a the most confusing chat app I've tried, especially if you run your own identity server.
The article calls out that the Signal server could be compromised. I always thought one design philosophy of Signal was to ensure the server doesn’t matter from the perspective of privacy.
Would having multiple servers help here, anyway? Once your data leaves your own server, you would then be in untrusted territory assuming the server needed to be trusted.
Would having multiple servers help here, anyway? Once your data leaves your own server, you would then be in untrusted territory assuming the server needed to be trusted.
It's my understanding that the main concern about a compromised Signal server is that metadata of which phone numbers are registered as user IDs could be compromised.
Basically the same threat model the Signal people themselves address when talking about court orders and subpoeanas received by their corporation for "customer" data.
Basically the same threat model the Signal people themselves address when talking about court orders and subpoeanas received by their corporation for "customer" data.
That's not true afaik. Signal days that they don't store phone numbers beyond the initial setup/verification. See here:
> Does Signal send my number to my contacts? Signal does not send your phone number to anyone unless you send them a message or make a call to them. The Signal service does not have any knowledge of your contacts. Data is all owned by your phone. Registration notifications are never transmitted by anyone in any direction at all; these notifications are created by your phone.
> How does Signal know my contact is using Signal? Signal periodically sends truncated cryptographically hashed phone numbers for contact discovery. Names are never transmitted, and the information is not stored on the servers. The server responds with the contacts that are Signal users and then immediately discards this information. Your phone now knows which of your contacts is a Signal user and notifies you if your contact just started using Signal.
https://support.signal.org/hc/en-us/articles/360007061452-Do...
(Btw, I think that first sentence is a bit confusing and should be classified/reworded.)
> Does Signal send my number to my contacts? Signal does not send your phone number to anyone unless you send them a message or make a call to them. The Signal service does not have any knowledge of your contacts. Data is all owned by your phone. Registration notifications are never transmitted by anyone in any direction at all; these notifications are created by your phone.
> How does Signal know my contact is using Signal? Signal periodically sends truncated cryptographically hashed phone numbers for contact discovery. Names are never transmitted, and the information is not stored on the servers. The server responds with the contacts that are Signal users and then immediately discards this information. Your phone now knows which of your contacts is a Signal user and notifies you if your contact just started using Signal.
https://support.signal.org/hc/en-us/articles/360007061452-Do...
(Btw, I think that first sentence is a bit confusing and should be classified/reworded.)
Some of these features are using SGX, which is why people dismiss them. Using SGX is still better than nothing, and there's no better alternative given the simplicity goals of Signal (e.g. selecting manually which of your contacts has Signal is not an option).
> truncated cryptographically hashed phone numbers
These would be equivalent to phone numbers, for all intents and purposes. The number space is trivially small.
This kind of obscurity makes it unnecessarily hard to understand what the argument really is.
These would be equivalent to phone numbers, for all intents and purposes. The number space is trivially small.
This kind of obscurity makes it unnecessarily hard to understand what the argument really is.
My main complaint about Signal is its reliance on SS7/PSTN and ordinary phone numbers to identify a user.
In an era of SS7 hijacks and social-engineering of mobile phone network customer service reps into SIM-hijacking a target's phone service, by no means should we ever rely upon a phone number as a guaranteed method of identifying an end point device's identity.
These are basically the same reasons why other services' "2FA" by SMS is questionable at best.
In an era of SS7 hijacks and social-engineering of mobile phone network customer service reps into SIM-hijacking a target's phone service, by no means should we ever rely upon a phone number as a guaranteed method of identifying an end point device's identity.
These are basically the same reasons why other services' "2FA" by SMS is questionable at best.
There's a "registration lock" feature for exactly this problem. Turn it on and you need your pin to re-register. (It expires after 7 days).
Not perfect by any means, but it seems like a well balanced compromise, given the decision to use phone numbers in the first place.
Not perfect by any means, but it seems like a well balanced compromise, given the decision to use phone numbers in the first place.
Doesn't the protocol detect device changes?
It does, and it warns the other users chatting with the person whose device has changed, but given the tendency of non technical users to click "yes/accept/okay" buttons in the GUI to bypass any error messages that come up on their mobile phone screens, I question how much value it has.
Two experiences: Among highly technical users in my peer group, when somebody upgrades or replaces their phone, if we're chatting with somebody who has a new signal device private key, I'll chat with them a bit by voice to confirm it really is them using a new phone. We've had a number of discussions about how it's apparently impossible to manually move ones' own signal private keys from disk storage on an android device onto a new android device. This works among people I know closely and recognize the sound of their voice.
Among non technical users, they'll just click the equivalent of "okay" and continue chatting without even thinking about what the error message means.
Two experiences: Among highly technical users in my peer group, when somebody upgrades or replaces their phone, if we're chatting with somebody who has a new signal device private key, I'll chat with them a bit by voice to confirm it really is them using a new phone. We've had a number of discussions about how it's apparently impossible to manually move ones' own signal private keys from disk storage on an android device onto a new android device. This works among people I know closely and recognize the sound of their voice.
Among non technical users, they'll just click the equivalent of "okay" and continue chatting without even thinking about what the error message means.
It’s hard enough getting random non tech friends and family to move to Signal. Going even further from mainstream means they will encounter usability issues and they will eventually revert back to WhatsApp. I don’t want any of this. And if “we can do better than Signal,” go make it then and get wide adoption instead of bitching in a blog post about how it’s not as good as some fringe products.
Is suggesting that the status quo could be improved so bad? I wasn't even "bitching", heck I use Signal too.
For companies and groups, organizations that want to replace the functionality of Slack, self-hosted Matrix (using the official Synapse software package) is becoming an increasingly viable option.
https://github.com/matrix-org/synapse/tree/master
https://github.com/matrix-org/synapse/tree/master
It’s great to see some balance about the Signal discussion here at HN. All I could see in the frontpage for several days is how great Signal is but nothing about what’s not so bright. This article brings up the same concerns I always had and I hope we all start being more conscious about it.
"We can do better" is a dodge. It avoids "I can do better" with a kind of royal "we" that implies other people should do the work. The obvious response to "I can do better" is "okay, go ahead". "We can do better" tries to tell me that I should be working on this guy's problem. That I should buy his line about how important "decentralization" is.
There's a place for software criticism. But the best comes in the form of just writing better software, or improving what we've already got. Calling somebody else's project a "shiny turd", on the other hand, isn't even really criticism. It's name calling.
There's a place for software criticism. But the best comes in the form of just writing better software, or improving what we've already got. Calling somebody else's project a "shiny turd", on the other hand, isn't even really criticism. It's name calling.
Being limited to a phone app and requiring phone numbers is severely limiting as well. Matrix is probably the current best-positioned e2e chat app that should be able to encompass more use cases, but it's difficult to convince users to use anything encrypted when alternatives have more network effects and usability.
Network effects always seem to be particularly egregious gatekeepers for social apps, often keeping users on inferior alternatives for years or decades, as coordinating a mass-switch is too difficult (Signal got particularly lucky with a few recent events or it wouldn't have nearly as many users switching to it right now).
Network effects always seem to be particularly egregious gatekeepers for social apps, often keeping users on inferior alternatives for years or decades, as coordinating a mass-switch is too difficult (Signal got particularly lucky with a few recent events or it wouldn't have nearly as many users switching to it right now).
Severely limiting? Please... Signal Desktop can be improved but I use it daily and it works for me™. Also, in many other countries, many people don't even have a PC (outside of work) but they'll definitely have a smartphone. So prioritizing app development is smart imo.
Not everyone wants their phone number to be their primary identifier
Signal will have very hard time competing as a product with WhatsApp.
Their main value proposal is that they aren’t backed by Facebook, but other than that, there’s no real difference to end user.
That’s enough for geeks, but not very compelling argument to break to mainstream. To break into such a highly competitive market, they need more unique features.
Or they can count on Facebook to keep on shooting themselves into foot, which is possible, but historically risky bet (no matter what HN crowd says, they continue to be extremely successful and know how to grow products).
Their main value proposal is that they aren’t backed by Facebook, but other than that, there’s no real difference to end user.
That’s enough for geeks, but not very compelling argument to break to mainstream. To break into such a highly competitive market, they need more unique features.
Or they can count on Facebook to keep on shooting themselves into foot, which is possible, but historically risky bet (no matter what HN crowd says, they continue to be extremely successful and know how to grow products).
Not sure about this - I’ve seen more acquaintances install Signal in the past two weeks than the previous two years.
What (I suspect) will work is something providing enough of an incentive for enough people to install it to then provide a network effect which is self-sustaining.
The recent coverage about WhatsApp/Insta/FB’s egregious data collection (thanks to Apple) plus the high profile recommendations of Signal have had quite the effect; time will tell if it’s enough.
What (I suspect) will work is something providing enough of an incentive for enough people to install it to then provide a network effect which is self-sustaining.
The recent coverage about WhatsApp/Insta/FB’s egregious data collection (thanks to Apple) plus the high profile recommendations of Signal have had quite the effect; time will tell if it’s enough.
They get great PR right now. They should utilize this moment as much as possible, but it won’t last for more than maybe few more weeks (it’s already fading away).
Network effects are hugely important, but they aren’t enough. Even if you have most of your social graph on both signal and WhatsApp, you need to not only change your habits, but also outages and bugs will quickly scare you away. And there’s tons of subtle tweaks that are done to keep you more sticky to one app.
Big tech isn’t usually that scared of other apps trying to do the same things as they do successfully. They’re scared of new paradigms that they can miss the boat on, and you can see that in what acquisitions they do. They don’t pay big bucks for copies of their services, but for new ideas that can be/are taking off.
Network effects are hugely important, but they aren’t enough. Even if you have most of your social graph on both signal and WhatsApp, you need to not only change your habits, but also outages and bugs will quickly scare you away. And there’s tons of subtle tweaks that are done to keep you more sticky to one app.
Big tech isn’t usually that scared of other apps trying to do the same things as they do successfully. They’re scared of new paradigms that they can miss the boat on, and you can see that in what acquisitions they do. They don’t pay big bucks for copies of their services, but for new ideas that can be/are taking off.
> Signal will have very hard time competing as a product with WhatsApp.
You seem to assume that they want to be bigger than WhatsApp, but as a non-profit I don't think that's their goal. Their goal is (broadly) to secure most communication in a privacy-preserving way. If WhatsApp does it because of the pressure from Signal, it's also a win for them (again as a non-profit).
You seem to assume that they want to be bigger than WhatsApp, but as a non-profit I don't think that's their goal. Their goal is (broadly) to secure most communication in a privacy-preserving way. If WhatsApp does it because of the pressure from Signal, it's also a win for them (again as a non-profit).
> A common defense in favor of Signal is, “But it’s all open source!”. Sure is, but on what basis do I trust them? ...
The open source aspect for me means 2 things.
- I can verify the e2e encryption claim.
- I can reproduce the client builds ensuring that what I run matches the source [1]
Is there a detail relating to the server that would invalidate this?
[1] https://github.com/signalapp/Signal-Android/tree/master/repr...
The open source aspect for me means 2 things.
- I can verify the e2e encryption claim.
- I can reproduce the client builds ensuring that what I run matches the source [1]
Is there a detail relating to the server that would invalidate this?
[1] https://github.com/signalapp/Signal-Android/tree/master/repr...
Both of your things depend on the client and if they are true it doesn't actually matter if the server is malicious or not.
I think the best description I've heard of Signal is it's open source "software" not an open source "project".
I think the best description I've heard of Signal is it's open source "software" not an open source "project".
A lot of open source projects are also "open" in the sense community contributions and interoperability, so people often take open source to mean these things as well.
Signal is open source, but hardly open as in the sense above.
Signal is open source, but hardly open as in the sense above.
I wanted to disagree with the headline. Then I read the article and do see their point.
I’ve been a big proponent of Signal for years and donated for the first time during their outage.
But I do think this is a conversation worth having.
I’d also like to understand more about this:
> In fact, the Signal server code [0] hasn’t even been updated since April 2020. You’re telling me it’s undergone no changes?
[0]: https://github.com/signalapp/Signal-Server
I’ve been a big proponent of Signal for years and donated for the first time during their outage.
But I do think this is a conversation worth having.
I’d also like to understand more about this:
> In fact, the Signal server code [0] hasn’t even been updated since April 2020. You’re telling me it’s undergone no changes?
[0]: https://github.com/signalapp/Signal-Server
If all the interesting stuff happens on the client and the server "just" forwards encrypted messages, why would the server need frequent updates?
if you go to the main git page https://github.com/signalapp you can see that changes were made to the server 8 hours ago. So something is happening on the server, the public cant see it. I definitely would like to see whats happening given. I trust them, but we definitely need to see whats on the server code.
I believe the 8 hours ago activity is from someone opening a PR, not some weird trick to update git repositories without being seen.
I think those changes could just be Pull Requests? Not necessarily code merged to master/main.
Unless you’re spotting something that I’m not?
Unless you’re spotting something that I’m not?
the last PR was 9 hours ago https://github.com/signalapp/Signal-Server/pulls
while the main page says update was 8. Thats what threw me off
while the main page says update was 8. Thats what threw me off
I disagree too, I known the people behind signal and signal protocol by far 10 years, I been see their work for a long time in different fields, when I read "We can do better than Signal" It's a natural thought human to find better in all things, but I don't really see more in the article
Hey icy, the issue you raise about Signal not being decentralized, I think, is a valid one.
You should check out a decentralized messaging and social media app I have been working on - Omnii.
Omnii allows each user to manage their encryption keys, and all data exists in a decentralized manner - only on endpoints (users' phones), and not on a backend.
https://omnii.co is our website if you are interested.
You should check out a decentralized messaging and social media app I have been working on - Omnii.
Omnii allows each user to manage their encryption keys, and all data exists in a decentralized manner - only on endpoints (users' phones), and not on a backend.
https://omnii.co is our website if you are interested.
The fact that you don’t offer a technical description of your application, and the fact that “Twisted Apps LLC“ does not have a credible online presence, does not inspire confidence in your security.
Omnii looks exciting. Signed up for the beta in Play store. But can’t find the app afterwards. Does it require specific hardware?
Hey, glad you are intrigued!
If you click the "Download Omnii Beta" button on the website, it should take you to the Google Play Store listing and allow you to download the Beta version of the app.
One restriction at the moment is that the app is closed to the U.S., Canada, Mexico, and India. If you do not reside in one of the listed countries, shoot me an email with the country you live in and I can see if we can open up the Beta to your country.
My email is: [email protected]
If you click the "Download Omnii Beta" button on the website, it should take you to the Google Play Store listing and allow you to download the Beta version of the app.
One restriction at the moment is that the app is closed to the U.S., Canada, Mexico, and India. If you do not reside in one of the listed countries, shoot me an email with the country you live in and I can see if we can open up the Beta to your country.
My email is: [email protected]
Lots of FUD in the opening paragraphs ("no changes to server code since April!!1!"). I stopped reading after that
What's untrue about that? There haven't been any commits to Signal-Server for almost a year.
https://github.com/signalapp/Signal-Server
https://github.com/signalapp/Signal-Server
I'm not saying it's untrue. but that op is saying that something bad is happening at signal without saying what exactly they mean (hence my !!1!-ing) is what I find annoying and I would qualify that as FUD.
It is a bit odd that we don't know whats running on Signals server. We are just trusting them not to do wrong at the moment because they arent WhatsApp.
On the public repo, there have been no changes since April 2020
https://github.com/signalapp/Signal-Server
If you go here https://github.com/signalapp you can see there were changes 8 hours ago.
So yes no public changes have been pushed, but changes are happening. It is fair to ask what changes are being pushed given their push for privacy.
How much do you want to trust here?
https://github.com/signalapp/Signal-Server
If you go here https://github.com/signalapp you can see there were changes 8 hours ago.
So yes no public changes have been pushed, but changes are happening. It is fair to ask what changes are being pushed given their push for privacy.
How much do you want to trust here?
Care to educate those of us who are confused by this?
See my other reply here: https://news.ycombinator.com/item?id=25812853
Thanks, wasn’t sure if you were saying that it was untrue that there were no changes or that it was not an issue that there weren’t.
Even so, I’ve yet to come across a software project in my career that didn’t have a fully stocked backlog of bugs, performance optimisations, security improvements etc.
In most cases if I find a project on GitHub that hasn’t been updated in 6 months, it’s usually a sign that it might be dead or languishing. Not saying that’s the case here, but the question seems valid.
Also not making a value judgement. Signal is free and open source, and the guys are rockstars.
But it does make me wonder if what’s running in production is a 6 month old build of that code, or is there more to it...
Even so, I’ve yet to come across a software project in my career that didn’t have a fully stocked backlog of bugs, performance optimisations, security improvements etc.
In most cases if I find a project on GitHub that hasn’t been updated in 6 months, it’s usually a sign that it might be dead or languishing. Not saying that’s the case here, but the question seems valid.
Also not making a value judgement. Signal is free and open source, and the guys are rockstars.
But it does make me wonder if what’s running in production is a 6 month old build of that code, or is there more to it...
Can you name anything that should have been fixed in Signal Server since April?
Can you name anything that should have been fixed in Signal Server before April? Probably not, but this doesn't look very good https://github.com/signalapp/Signal-Server/graphs/code-frequ...
So one of the things that feels the most damning to me about Signal-like protocols is that you have to inherently trust their server.
Consider this paragraph from the Signal protocol
> ...For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document.
> If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.
I have not known anybody that actually does this. If an active attack does happen on somebody, I'm pretty sure they would not notice.
As far as I understand, a decentralized model solves this problem. Don't trust the server? Run your own instance or have some other way of validating clients (via your own PKI infra or similar).
Consider this paragraph from the Signal protocol
> ...For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document.
> If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.
I have not known anybody that actually does this. If an active attack does happen on somebody, I'm pretty sure they would not notice.
As far as I understand, a decentralized model solves this problem. Don't trust the server? Run your own instance or have some other way of validating clients (via your own PKI infra or similar).
You understand wrong. Nothing solves this problem except verifying fingerprints manually (in person!) or scanning the QR code (again in person!).
This is the same for any piece of crypto. If you've been provided someone else's encryption keys, and they're not either from the person themselves, or from a trustworthy intermediary, then your channel could be getting intercepted.
It's a philosophical/conceptual problem with encryption, not one restricted to signal.
It's a philosophical/conceptual problem with encryption, not one restricted to signal.
Indeed.
Why? I trust that my own server is not backdoored (thus reducing the need for off-channel fingerprint verification), I have no such guarantee about Signal's server.
Because you can never be sure that the other person's server or connection (or your connection) aren't being MitMed.
Yes, but I can get all the parties I want to talk to on my own server (if the need arises).
About your point the connection itself being MITMed, I don't exactly understand how an active attacker sitting on my connection would undermine the connection? Presumably I have a way to verify the identify of my server. Please do elaborate if I'm missing something. Regardless an interesting thought.
About your point the connection itself being MITMed, I don't exactly understand how an active attacker sitting on my connection would undermine the connection? Presumably I have a way to verify the identify of my server. Please do elaborate if I'm missing something. Regardless an interesting thought.
If you're cryptographically checking that the connection you have is to your own server, sure, but I don't know any program that does that sort of thing. I guess if you're using TLS as a transport, the client handles that (if you have a self-signed certificate that you've told the client to trust exclusively).
Yeah, TLS solves that right? So we can agree that a decentralized system effectively removes the need to ever trust any third party system?
Of course not. You didn't write all the code yourself, even if you did make your own CA and removed all other CAs from your computer (or did you? Because they can MitM you if you didn't). You still have to trust the people who wrote the code to have done so correctly and non-maliciously, plus the people who wrote the OS, and the computer, and everything.
It's a much smaller leap to go from "I trust you to have written the code correctly" to "I also trust you to run the server well" than it is to go from "I don't trust anything" to "I trust all these billions of lines of code I didn't write".
It's a much smaller leap to go from "I trust you to have written the code correctly" to "I also trust you to run the server well" than it is to go from "I don't trust anything" to "I trust all these billions of lines of code I didn't write".
TLS is not decentralized in its common form, you just use a certificate signed by a third-party (CA). So you end up trusting this CA. Why are you willing to trust this CA instead of Signal's server?
If you self-sign a certificate instead, how do I check that the signature matches yours?
To get a (proper) secure channel, you need at least an authenticated channel first.
If you self-sign a certificate instead, how do I check that the signature matches yours?
To get a (proper) secure channel, you need at least an authenticated channel first.
Keybase solves this problem.
Maybe we can't for now and that's okay. There are so many solutions to choose from and the only thing that would make it popular would be if the people you want to chat with or on it. There's also a big issue with any of these platforms, MONEY. People want to text, share images and videos and audio. Want to have audio and video calls over data. A proper interface, cross device sync and they want it all fre e. Most people will use free software.
So you know maybe we just can't do better for now.
So you know maybe we just can't do better for now.
Nothing is ever good enough, is it?
No matter what is built you'll have people complaining about any aspect of it they can find. Most of them won't so anything more than that. They won't contribute a single thing, pat themselves on the back and call it a day.
There's not even a hint of constructive feedback in that post. Not even an attempt at resolving any of the identified problems or thinking further about implications of possible changes.
I need a downvote button on HN...
No matter what is built you'll have people complaining about any aspect of it they can find. Most of them won't so anything more than that. They won't contribute a single thing, pat themselves on the back and call it a day.
There's not even a hint of constructive feedback in that post. Not even an attempt at resolving any of the identified problems or thinking further about implications of possible changes.
I need a downvote button on HN...
Signal is not the best option by any means. But it's so much better than most of the other options like Whatsapp or iMessage. It's all about threat models.
I wonder if it's possible with some tricks to build a message box on top of a regular DHT (distributed hash table) as commonly found in many P2P network implementations. There is no need to guarantee that the message is stored for a certain amount of time as long as the protocol knows whether the other party has received it or not: you can just put it into the DHT again as long as it's not received.
The article should be titled "How can we do better than Signal?", because it neither brings nor addresses anything better than Signal. It'd be better as an Ask HN.
The expectation reading it was to find out about a product that is better than Signal. The reply to the assertion after the disappointment will most likely be "Then do it".
The expectation reading it was to find out about a product that is better than Signal. The reply to the assertion after the disappointment will most likely be "Then do it".
We can certainly do better than Signal. The central point of attack is a problem. And now also the fact that they are using AWS, and AWS has demonstrated being willing to deplatform within 24 hours.
However for now Signal is one of the best options we have.
Signal, telegram and matrix (or at least 1 of the 3) should work on cross-app E2E communication.
Instead of creating a new protocol, why not just have a competition between clients using the current protocols?
Instead of creating a new protocol, why not just have a competition between clients using the current protocols?
Matrix has bridges for Telegram and Signal
Matrix tried with Signal but it didnt yield anything https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
Matrix tried with Signal but it didnt yield anything https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
As long as Signal is really open source, I don't see why Matrix couldn't just add connecting to signal servers in the client itself instead of creating bridges or a common protocol. The only thing Moxie can do is to make Signal closed source, or constantly break the signal protocol on purpose and force everybody to upgrade their signal and telegram apps.
Also I tried Matrix, and it started asking questions from me instead of showing my friend list, so it already failed being a competitor to WhatsApp. The only question it should ask is to get permission to access my contact list.
I know that interopability is very hard to do, and having multiple clients in 1 app is boring work (especially with features like voice and video calling), but it would be amazing.
Also I tried Matrix, and it started asking questions from me instead of showing my friend list, so it already failed being a competitor to WhatsApp. The only question it should ask is to get permission to access my contact list.
I know that interopability is very hard to do, and having multiple clients in 1 app is boring work (especially with features like voice and video calling), but it would be amazing.
[deleted]
We can also do better than using insults against a service which isn't perfect - and maybe won't be if it continues its course - but is doing a good thing for the right reasons.
No, you cannot do better than Signal at the moment. You do not have people picking your service of choice en masse. A chat app is only useful if people you want to talk to are on it.
Was happy to play around with Delta Chat today. Very nice progress. That was until one of our friends tried to logon with Gmail on her iPhone. Too much hassle unfortunately.
That single fact that I have to share my phone number to everyone (I want to chat with) in Signal is enough for me to don't even think about installing it.
Why is XMPP not mentioned as an alternative? it's decentralized, fully open source and supports end to end encryption.
And easier to set up a server than Matrix. I suppose it's just not fashionable enough because it's rather old.
I used Conversations and Movim while Signal was down, and was greatly impressed with them.
I used Conversations and Movim while Signal was down, and was greatly impressed with them.
I wish Delta Chat would get more mentions during this period
It is nicely decentralised. Nice UI. Run your own server. Deserves more love!
It is nicely decentralised. Nice UI. Run your own server. Deserves more love!
I You can do it, then do it. Build something on top of IPFS. Decentralize.
Moved from WhatsApp to Threema, so far so good.
tl;dr: With decentralized identities, we could have a messaging system based on the Signal Protocol that does not use central servers at all.
There seem to be a lot of opinions about whether it is possible to do better than Signal, and if so, what would that be like. There also seems to be a lot of opinions that federation is better.
There is something that can be better than Signal, but federation is not it. For one thing, it creates the problem in https://xkcd.com/927/ . For another, as some have said in the comments here, federation can easily lead back to centralization, especially if the biggest servers implement "extensions" that then become used and expected by users.
What would be better than Signal would be to take the Signal Protocol, which is fine as a protocol, and implement the protocol using software that the user runs themselves and that uses completely decentralized identities. I wrote about such a system at https://gavinhoward.com/2020/07/decentralizing-the-internet-... .
The key is that the users must control their data, like the pods that Sir Tim Berners-Lee's Inrupt is pushing. (This would solve a big problem with Signal: the lack of backups.)
However, without some way for each user's "server" to identify the location of another user's "server", this messaging system would not work. That is where decentralized identities come in.
With fully decentralized identities on a blockchain, it is easy to search the blockchain for the current location of the server for the user that a message needs to be sent to. There is no need for federation, no need for a centralized server at all; the messages go directly point-to-point.
Others in these comments have pointed out that decentralized systems are subject to abuse by spam and other things. That is true, but there are ways to mitigate the problem. You can read what my mitigation ideas are at https://gavinhoward.com/2020/07/decentralizing-the-internet-... .
Edit: I forgot to say that it is also important to address convenience. If it is not convenient for users to set up their own servers, then this solution will not work anyway. However, cloud providers would probably love to make it convenient by implementing one-click setups like they have for things like Wordpress.
There seem to be a lot of opinions about whether it is possible to do better than Signal, and if so, what would that be like. There also seems to be a lot of opinions that federation is better.
There is something that can be better than Signal, but federation is not it. For one thing, it creates the problem in https://xkcd.com/927/ . For another, as some have said in the comments here, federation can easily lead back to centralization, especially if the biggest servers implement "extensions" that then become used and expected by users.
What would be better than Signal would be to take the Signal Protocol, which is fine as a protocol, and implement the protocol using software that the user runs themselves and that uses completely decentralized identities. I wrote about such a system at https://gavinhoward.com/2020/07/decentralizing-the-internet-... .
The key is that the users must control their data, like the pods that Sir Tim Berners-Lee's Inrupt is pushing. (This would solve a big problem with Signal: the lack of backups.)
However, without some way for each user's "server" to identify the location of another user's "server", this messaging system would not work. That is where decentralized identities come in.
With fully decentralized identities on a blockchain, it is easy to search the blockchain for the current location of the server for the user that a message needs to be sent to. There is no need for federation, no need for a centralized server at all; the messages go directly point-to-point.
Others in these comments have pointed out that decentralized systems are subject to abuse by spam and other things. That is true, but there are ways to mitigate the problem. You can read what my mitigation ideas are at https://gavinhoward.com/2020/07/decentralizing-the-internet-... .
Edit: I forgot to say that it is also important to address convenience. If it is not convenient for users to set up their own servers, then this solution will not work anyway. However, cloud providers would probably love to make it convenient by implementing one-click setups like they have for things like Wordpress.
Is it possible to do a hand-off? So one cellphone can make a connection to another cell phone? UDP over LTE? I'm guessing a port can't be opened when on a cellular network?
People already have, it’s called wickr
Assuming you trust the client builds (or use a verified build) and verify the public key, all of these arguments go out the window with the exception of exposing your phone number. This situation seems like a prime example of a company (Signal) being so transparent that people need to find fault.