Zoom acqui-hired the team in 2020: https://blog.zoom.us/zoom-acquires-keybase-and-announces-goa...

* fully open source (including the server) and self hostable

* has a business model of charging for a hosted version

* designed so that you don't need to trust your server

* audited by Cure53

* fine-grained access control

* identity proofs with controllable visibility

* encrypted applications like calendar, chat, social media, text editor, video streamer, PDF viewer, kanban

* custom apps - you can write your own apps for it (HTML5), which run in a sandbox which you can grant various permissions

* designed with quantum resistance in mind

You can read more in our tech book (https://book.peergos.org) or source (https://github.com/peergos/peergos)

Disclaimer: co-founder here

This is great for distributing encrypted keychains/configuration files and the such across various platforms (where many apps are not cloud-aware but are happy interacting with the filesystem). So far the "mount" approach seems to have also performed considerably better than syncing-based services (dropbox, G drive, OneDrive etc.) which from time to time have resulted in hard to untangle merge errors.

Peergos looks promising but it also looks to be a web-only service, so not exactly a replacement yet. Would be nice to see an option for local native mounting. Preferably via a native app with a FUSE-like mount point, but I'd also probably be OK with something like WebDAV maybe.

You can also migrate server unilaterally and keep your social graph without needing to tell everyone, all links to your stuff continue to work afterwards.

I would pay $/mo for a Keybase reboot with the goal of building a sustainable business like Signal did instead of taking VC money for a shot at the moon. Until someone does that, Keybase continues to work as a messaging app with usernames instead of phone numbers.

Keybase still works and for a simple messaging app does the job better than Signal or any other messaging app that requires a phone number. This is a total disaster.

> but nothing they were doing of late with Lumens was that exciting anyway (trying to become a crypto wallet like everyone and their mothers).

Just like Signal did, with their own private crypto wallet and cryptocurrency that they have been working suspiciously in the background for a year after being questioned.

https://github.com/keybase/client/graphs/contributors

This is great advice if your goal is to send messages to yourself. In the real world, though, a messaging app that you're the only one using is about as useful as a bag of ice in a snowstorm. People don't need "like signal but with usernames," they need "signal with usernames (or email addresses or...)" so they can communicate with people who use signal.

You don't get to look over at Signal and say "wow what a great user base I need to be a part of that" and then draw the conclusion that "Signal needs to support my idealogical aversion to using a phone number". You're missing the possibility that Signing is the way it is because it requires users to verify their phone number.

If you can't use a phone number but need to talk to people who do, securely, then you need to convince them to use a product that accommodates your niche. Why can't you use PGP and email, or Keybase, or <insert one of the 10s of other products that let you send encrypted messages>?

Sure, signal could add support for usernames. But how do you know there'd be anyone left after they did for you to talk to? Maybe it's not what Signal's users need.

Anyway, if Signal found a way to support usernames that didn't compromise on all the reasons I use signal and also didn't open the network up for tons of spam and low quality content, I don't think I'd complain. But that's a big IF.

I've found, and I think more than me have, that the overlap between having an immediate need for security and wanting to share you phone number is surprisingly small. And even just a subset of those people are on Signal.

It's just never been very useful for me when other services are.

It's not really my problem if it's hard. That's for them to figure out. Until they do I will continue to be an unhappy user of their product, and no amount of people on the internet willing to defend their choices as if they were their own is going to change that.

Using phone numbers is a compromise taken in order to enable a UX that actually wins users. Have we forgotten what that word means?

The answer is I give them my email or username. They give me theirs. We connect.

Using phone contact lists shortcuts this process, but the exchange still had to happen at some point. Is it really so hard to believe some users might choose to do it again? Or, god forbid, with someone they'd rather not give a phone number to?

I genuinely believe there is a lot of commentary on this thread from people who have never designed a secure system. You never get 100% security and 100% privacy. Even if you only use public keys, web3 style, you're still a traceable public key--by definition not private. Okay everyone uses a fresh key for every action. Well now you have a problem figuring out who anybody is and whether you should trust them. Either trust isn't self-sovereign or it is. And we've learned time and time again that self-sovereign trust systems are akin to anarchy. Signal leverages the verifiable short identifiers available to a mobile phone, at the expense of 100% perfect anonymity when asking the question "has this phone number used signal". Literally everything beyond that point is 100% secure and as private as two public keys corresponding can be.

1. As a signal user, I don't want to see the threat model weakened so that we can include email anons, personally.

2. Even if we did, I don't understand how doing so in any way solves the privacy issue. How is email any more private than phone? If an email provider got phished people would be yelling the same thing "how could signal be so stupid to use email, don't you know it's insecure". Email providers can still be compelled into shenanigans, too.

3. Signal as a product has to facilitate a key exchange. I'm pretty sure you can checkout their source code and run their protocol and solve the key exchange portion differently if you so desire. You could have "signal without phone numbers or email" tomorrow if you wanted. As long as your users are willing to copy and paste public keys into their messenger, that is.

To sum up: the key exchange and distribution is the entire problem. And Signal presents an adequate solution: bind phone numbers to asymmetric crypto, add perfect forward secrecy and give people secure messaging. Surely it's not for everyone, but this incident in my eyes only further validated that this premise is solid.

Gosh that's quite the conclusion. I hope my employer never finds out about this discovery of my competency based on some comments on a message board.

I think you've very much lost the thread of what I'm saying here, because at no point have I suggested anything about 100% security or 100% privacy. It would actually be pretty weird for me to be advocating for that while also asserting that you're making maximalist arguments.

I also never said email is inherently more private than phone. I assert that it's a different privacy tradeoff, and one that I'm more comfortable with for various reasons. I could get into those if you want but I don't think they're relevant. (1) is the more interesting question in the end. (3) is just "it's open source you can fix it yourself!" which is .. not very useful on any level. Yes, I can go make my own signal-based platform and talk to precisely no one over it. No I'm not interested in doing that. I've been to the social network rodeo and have the mental scars to prove it.

So ok, assuming we go with email addresses as the alternative mechanism, and the email addresses still require verification same as the phone numbers, and you still have to mutually have each other on our contact lists to communicate through signal: How, specifically, has the threat model been weakened?

I agree Signal could add email addresses specifically, if verified and it wouldn't affect the threat model outside of introducing the network to more spam-able identifiers. Like I've said, if they figured out how to do that without degrading the quality of the experience today I doubt I'd be up in arms. I'm working on adding more email addresses to my contacts book, slowly. It probably makes more sense today than it did when Signal was born.

It's not about what Signal can and can't do, though. Signal needed a readily available offline locally owned and operated contacts book with to make their product vision work. So they used the one everyone has on their phone and it worked. They upgraded the security of everyone sending sms and mms. I think there's a way to celebrate that while asking for email address support without getting into the ream of "zomg Signal sux because they use gross phone numbers what idiots would design a system like that what a fucking mess of a royal debacle attn. whistle blowers and abortion seekers: signal is not for you". That type of response is what I'm railing against by simply reminding people that Signal is a successful product that does indeed work as advertised and that it doesn't exist in a vacuum.

They've been working on it for years. Their solution is that they have to take client-side ownership of your contacts list, keep it associated with your "account" and sync it across your devices so that when you correspond with someone by username, it becomes available to you everywhere. They have to be your contact book. I can find nothing on how they plan to verify usernames, perhaps in the traditional style with email.

So yeah, absolutely not some trivial change that they just don't want to do because fuck the few people that don't have a phone number (or don't want to use it). They're working toward supporting usernames and at every turn keep getting reamed by HN because, in their effort to solve a problem that only exists on HN, they have to deploy a solution that means you have to trust them in a teeny tiny way you didn't previously IF you set a weak pin on your account. It's mind boggling. It must be so disheartening to see that type of response.

But, that's my point. Signal can't add short names without changing the fundamental trust model which appealed to everybody initially. No amount of hiding a password as a pin, will change that. I really hope they don't kill their product along the way...

(Also man WTF they're running Raft on SGX enclaves just so they can rate limit attempts to brute force users' weak pins. While super cool, technically, what an incredible waste of resources just to try and make weak passwords okay. Probably the most backwards thing I've seen a security company attempt like ever. Just tell your users if they want a username they need a strong password. Or just generate the entropy for them and only allow the username option to people who also want to take custody of their new 32-bytes of entropy and have a signal-managed synced contact book.)

If their goal is to shift responsbility to the user, that solution works. If their goal is to provide secure communications to the general public, that solution doesn't work. As you probably know, strong passwords are widely recognized as a failed security technology for the general public.

Also, what happens when the user forgets their strong password? Dataloss is not an acceptable outcome for general end users whose priority usually is not ultimate security, but usability. Thus (as I understand it) Signal allows weak passwords ('PINs') that stay with the client, and adds 'invisible' entropy which is backed up to server-side SGX (because the user doesn't know the entropy, it must be backed up off-phone in case the phone is lost). It's a great, no-tradeoff solution IMHO: If SGX is compromised, the user is no worse off than if the supplemental entropy didn't exist at all - they have their (weak) password. If you don't want to depend on the 'supplemental entropy', use a strong password and then Signal's entropy and SGX security become irrelevant.

> Or just generate the entropy for them and only allow the username option to people who also want to take custody of their new 32-bytes of entropy and have a signal-managed synced contact book.

AFAICT, Signal is not interested in implementing features that are valuable only to geeks and that everyone else ignores, and those kinds of features don't seem to fit their mission.

I don't understand why your takeaway from the fact that they're implementing it is that the people saying they want or need it are irrational and only exist on hn instead of "hmm, maybe I'm wrong and this is a legitimate feature request".

Anyways, let me assure you that the people who get "reamed" are in fact anyone who even causally mentions they want this feature who get a bunch of very dedicated people telling them how utterly wrong they are, no one should ever want that and anyways it's impossible actually.

Trust me.

The strong response you encounter is people trying to communicate that it isn't that simple for them. That it means enough of a shift in Signal's model that they're really worried about the change to the product if Signal implemented it, not least because it changes the very thing that drew them to the product in the first place. And unfortunately, it seems the worries are not unfounded. I genuinely don't think many of the people asking for usernames would want them if the proposition was clear: "you can have them but you have to trust us with your contacts book and personal information". It's the catch22: in order to have the privacy of a username, you must give up the privacy you'd win. For some people, they trust Signal with that responsibility more than their carrier (like a VPN) and it's a good tradeoff.

Me? What was compelling about Signal is that it was my contacts book and encrypted communication. No accounts/profiles, no passwords, no proprietary software, no invasive product analytics, just a global DB associating phone numbers with pubkeys. That was my pipe dream but I also acknowledge I'm not the center of the world either: in the same way you begrudgingly use Signal with a phone number, it's also not the end of the world for me if we have yet another company out there where I need to maintain a profile and stick a password in my password manager and login periodically. But sadly, if Signal gets to that point, it ultimately means the "Signal experiment" portion of the product's life will have come to an end. <- This, more than anything else, is why the suggestions to go use one of the products that already provide the experience you're looking for is apropos and not dismissive. We don't want the experiment to end. The entire point of championing Signal in the first place was idea that we could collectively participate in a product that didn't do what everyone else on the internet did and send off all your data to their servers the minute you opened their app.

What you’re arguing for is the recovery mechanism to get back online when you lose your private key, which is totally unrelated and could be solved independently for people who choose to give a phone number vs those using an email or some other arbitrary identifier.

2. Let me make this clear: an imperative component of signal's product is that the identifier used is verifiable, and that the only thing they store for a period of time is that users in-fact did verify their number. Everyone arguing for typed in identifiers is missing this point. That wouldn't be Signal. That's the core of what I'm saying. That would be something else where people claim short identifiers and then have to share them with each other via some other channel which I'd have to independently verify, etc.

3. Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. I use Keybase, feel free to hit me up there if you need a messaging platform with socially verified short identifiers. My proof is in my profile. If you want an unverified short id, email works great, I respond to that too. Point being there are existing options for "type in a short id and send it a message".

> Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into.

So it turns out Signal is building support for usernames and their solution is indeed rather involved. In order to achieve usernames they've:

1. added a contacts book and profile

2. added a passpin by introducing Intel as a trusted actor. the pin you enter when using signal is actually your Signal account password

3. presumably adding support for usernames and <TBD> username-based verification

They've been working on this for years. They're not just sitting on their hands. So my point seems to stand: it's not just "add a username field and let people type shit in we have input fields amirite". It's a massive overhaul of their fundamental architecture. And sadly it's not happening very publicly because the stuff they're doing to make it happen is also not okay according to the other half of the security community. Carriers? Not okay? Well how about usernames? Oh, you're using 4 digit pins as passwords and SGX to throttle login attempts? Well that's not okay either SGX has been pwned a billion times. Lose/lose for Signal. I pity them, honestly. It sucks.

I'm not personally enraged or anything. I think the SGX stuff is actually a pretty cool compromise. But, alas, it's still a compromise in order to make usernames equally feasible as phone numbers. Either way you're compromising. And that's what this thread is about: to make security accessible you can't live in an ivory tower and demand perfection. You have to get down in the field and make compromises in order to build a successful product that people will actually use.

“Oh, signal is relaxing that constraint. I was still right and signal employees are wrong for doing this.”

They've run into all the issues and nuances elucidated in this thread. They have been receiving pretty intense feedback from people who have stopped using their product because of the concessions made. They've clammed up in response and are losing even more people because they are not clearly articulating the changes to their users (many of whom would be fine with it if communicated transparently and respectfully). They have people who desperately want usernames but also not if it means what Signal is proposing and admit "okay, you heard my request and tried, but hmm let's not do that I don't like this PIN UX and it's not what I wanted when I said I want usernames". And they even saw their product forked the minute it became clear what they were doing: https://getsession.org (blogs start Dec, 2019 which is around the time Signal started messing around with secure value recovery stuff, at least publicly).

Also I'm not advocating for anything to be kept server side, nor do I see any reason why other identifiers couldn't be kept client side. An address book is just a list of identifiers, it's not magical just because it's phone numbers and already on my phone.

We've had this conversation before though. I remain unconvinced.

This is exactly what makes it "your problem".

Signal worked out a way to provide E2E messaging that practically everybody who cares and all their friends use. You can choose to accept their phone number requirement compromise and take advantage of that huge and growing network of users, or you can go your own way and somehow convince "the people you need to talk to" to also use some alternative that more closely meets your specific needs.

> I remain unconvinced.

I get that. I understand and even partly agree with your stance. But the pragmatist in me is way happier with having a significant portion of the people in my contact list also on Signal and having a zero effort was to have an E2E encrypted chat with them. I am old enough to have gone to PGP keyparties in the late 90s. I have verified private keys for a handful of friends with some combination of privacy/security/paranoia outlooks. I can't remember the last time I sent or decrypted a PGP message (that wasn't a computer generated alert). Person to person encryption key exchange has been tried and has never gained anything like a ubiquitous network. Signal isn't perfect, but it's got very close to that, which makes it day to day usable and extremely useful. At least for me and all my friends and most of my business contacts. YMMV.

No, it’s still signal’s problem too. There is no reason to bootlick here.

> Signal isn't perfect, but it's got very close to that,

It’s really far from it. Being tied to SMS and phone numbers is a nearly fatal flaw.

This is one of the most boring repeated conversations that occurs on HN. It's incessant. Avoiding these incessant superficial conversations is, in fact, part of the premise of HN.

> So surely then there has to be some technical limitation because what other legitimate reason is there?

It's like people aren't reading the whole thread and just responding to specific comments they don't like. The premise of Signal, or at least what's made it practically useable, is that the short identifiers are immediately available and verifiable on a mobile device. When I first reach out to someone on Signal I know the person I'm reaching out to is the owner of the identifier I used unless their phone carrier is actively compromised when I exchange the first message. To Signal's users, this is an acceptable compromise. On top of that, I don't need to do a key exchange dance every time I want to talk to a new person because I have a contacts list of their phone numbers, which Signal has verified and bound to their keys.

Signal is really pretty simple: trade key exchange parties for the phone numbers already acquired though countless years of past parties and have locally grown crypto sans intrusive cloud services. And, do it explicitly not-for-profit so there's no possible motivation to abuse this contract with users in service of shareholders.

Obviously Signal could implement whatever random people felt the need for at any given moment. But they don't and it doesn't seem like whining about it is changing anything. If you don't like that then go use one of the many alternatives or build a replacement. I'm honestly surprised nobody's built one at this point. Literally spin up a signal server, make a build of their mobile app, and let users paste in pubkeys instead of phone numbers when starting a message. See how many people use your product. Or just change the phone number db to a shortname db and remove the verification step.

Yes, these conversations are exhausting. What's even more exhausting is the perpetual outrage from "hardcore" "security" "nuts" and absurd anons driveling on about why all the practical solutions that work for users are nonsense and how they could be made "better" but who balk at actually building the solution they think the world deserves. It's a tale as old as time in the security community, sadly.

It's funny, Moxie actually did something about it and it still isn't good enough. Signal is probably the closest thing to a PGP+email replacement we've ever had. What more do people want?

> When I first reach out to someone on Signal I know the person I'm reaching out to is the owner of the identifier I used unless their phone carrier is actively compromised when I exchange the first message.

Compromising is in this case rather common in sim swapping and spoofing (you can barely even call it spoofing). Phone numbers are not useful as some sort of continued point of trust. And I doubt Signal uses it like that under the hood.

> What more do people want?

Before you complain about other people maybe you should give other people the courtesy of reading what they wrote first. I have already said what I want, a public id I can publish on for example GitHub without the implications of publishing a phone number. Implications which anyone with a relevant opinion should already understand.

But, none of this even matters if you turn on registration lock. Sim swapping attack thwarted.

I've read your request worded in different ways many times and what people keep doing is pointing a finger at phone numbers, yelling "they're insecure", and then pointing at usernames and saying "look, it can be better". Nobody has actually argued how it could be better, just that phones suck. I don't find that a compelling argument, sorry.

Usernames/email are no less susceptible to whatever service you use to register them getting jacked. There is literally zero security difference and emails are easier to spam. Usernames just don't have KYC baggage that phones do in the US. But honestly as Signal has shown time and time again, all that law enforcement can get from Signal is that a given phone number registered with Signal. Because they have impeccable application layer crypto which is what actually matters.

Okay so what if Signal uses a username/password DB and doesn't allow email reset. That removes the 3rd party from the equation and now Signal takes the burden of being the central authority for usernames. And, while possible, it entirely inverts the whole premise of Signal in the first place.

Good news for you, that's not just my argument, it's actually happening. Signal is trying to add support for usernames by forcing everyone to add a pin. It's not clear at all that this pin is now the password to a signal account that is used to sync your contacts data and profile. That's not a problem in and of itself because it's all theoretically good crypto. The problem is that it isn't good crypto. It's a 4 digit pin for the majority of users. Signal knows this is in a bind trying to slip things in that they know would piss off half their users because it's shit security just in order to make usernames possible. And they're getting called out for it.

aside: It's not passwords per-say that are bad (even though they are because people and UX). It's that Signal is telling everyone "hey add this quick pin" and people don't realize that's actually a password for your whole account and that the whole model is changing underneath them. If you know and set a strong passpin, you're fine.

Anyway, the catcher is this: instead of having to deal with what it means to have passwords and get users up to speed, they developed some technically really cool but batshit insane system to throttle pin attempts so that the burden of trust gets moved from your carrier to Intel and they can wash their hands of how insanely bad a 4 digit pin is in terms of entropy. So you want usernames because you don't trust your carrier? Did you know that would come at the cost of trusting Intel instead? They don't really have a great track record recently...

My entire point is not that people are stupid for asking for usernames or something. It's that they don't come "for free" as everyone seems to think. If you want traditional username/password, then the world changes so that Signal becomes a cloud service you must trust to maintain a new global contacts book of usernames just for use on Signal. Signal didn't like that and that's definitely a problem for all the people who use Signal because they don't have their fingers in that cookie jar. So they punted and are moving the trust point to Intel.

They've been working on this for years.

And again, signal is the only thing that can talk to people on signal so "use something else" is not helpful.

Do you have an alternative suggestion? Is there an app and platform you'd rather use over Signal? Maybe Wickr? Matrix? (AN0M? <smirk>)

My take is there's a very small "unmet need" that frustrates such a small number of people that everybody who's tried to usurp Signal has effectively failed.

Signal has literally become "SMS but secure" for everybody I know.

> signal is the only thing that can talk to people on signal

That's untrue. There is nobody in my signal messages that I cannot talk to over the phone, via SMS, and almost everybody I can talk to via email (with a vanishingly small number of those for whom I have trusted PGP keys).

A agree with your premise that it'd be really nice to piggyback Signal's contact graph without having to do the work and make the compromises Signal have done to create that graph. But that's a totally unreasonable expectation.

(And FWIW, I think Signal totally lucked out early on by being in the right place at the right time to build their contact graph. My network of friends/colleagues exploded back when WhatsApp fucked up their messaging/policy a few years back, and practically overnight my "normal" and non privacy focussed or recreationally paranoid friends all rage quit Facebook messaging and encouraged each other to move to Signal. There was a super obvious step change in who my available Signal contacts became back then, and I'm not convinced Signal would be what it is today without that fuckup by Facebook back then.)

And I never said everyone I need to talk to is on it. I have like 6 different messaging apps and accounts because nothing has everyone. And I'm pretty conservative about which ones I'll use compared to most people I know.

I would rather use signal than most of those, other than the fact that I also frequently need to communicate with people who have no business knowing my phone number.

I've never regarded a phone number as something extraordinarily personal. The amount of spammers that happen across my phone number is ridiculous. It's nice when you interact with a real human using your phone number (unless it's a recruiter ffs), so the more I give it to the more likely that is to happen. I guess I just don't understand what's personally revealing about a phone number. I give my phone number to mundane things all the time so people can communicate with me. The "need to know" bar for my phone number is pretty low. It plays about the same role as an email address in my life.

Disclaimer: I'm one of the ex-Keybase, now Zoom people. I'm definitely in a bubble. The non-Keybase people I talk with are my consultancy's employees + a couple clients.

Keybase's security model is excellent in protecting you from attacks like the one described in the OP. If you can't sign your device with another one, you can only recover a username if:

- it's not in [lockdown mode](https://book.keybase.io/docs/lockdown)

- it has a verified email / phone number

- you either click a reset link in the email / SMS _or_ know the password

- _and_ the user fails to cancel the reset over many days of warnings.

And if you manage to go through all that trouble, all your contacts will get blasted with warnings about your identity. Fun!

Matrix, right now, is a lot more amenable to the kinds of messaging that people on HN tend to want to do than Signal is. The problematic thing is that HN people tend to believe that their workflows are (1) the most important and (2) the ones with the most sophisticated threat models. Neither are true; (2) is very un-true.

For, like, talking to team members about a shared dev project, I'd always use Matrix in preference to Signal --- of course, for that kind of work, what I'd really do is just use Slack or Discord. Which gets at something about what HN wants from Signal.

https://github.com/keybase/client/graphs/code-frequency

https://github.com/keybase/client/graphs/contributors

Zoom is a looooong way from having the sort of trust that Signal/WhisperSystems have in my mind.

(Which is a pity, I really liked the idea of Keybase.)

All of these feature requests require less knowledgeable users to do new things or weigh alternative options which involves time spent developing onboarding. Having "one way," an opinionated way, to do a particular type of thing is a very useful engineering value especially if you have limited engineering resources. Simplicity is an extremely underrated feature.

Being 80% perfect for 20% of the work is laudable.

What's even better about Signal is that Facebook's competitive data is the list of people you know. Facebook wins every time a person adds a friend without adding their contact info to their phone. That means Facebook is the source of truth for who you know and Facebook is the intermediary for communicating with someone else. That's why, in retrospect, whatsapp was an obvious competitor worth spending a lot of money acquiring. WhatsApp drove people to use their phones contact list as the source of truth for you who communicate with, not Facebook's friend list.

It's not a drop in for the behavior (talk to other people who use Facebook owned services in a way where Facebook can read all of your conversations), it's a drop in for interface (communicate with others who use the app in the same way you communicated with others using WhatsApp).

I just spent time looking at matrix.

  google "matrix"
  oh right, name space collision with popular 90s movie
  google "matrix app"
  oh, this is some library or something, not an app
  searching the page for client. "Maybe under matrix live?"
  see clients button in sub menu
  see 10 plus options I don't recognize the name of and immediately lose interest

  search "matrix" on app store
  see apps with 2 stars or less than 10 reviews, nothing official.

100 bespoke solutions to the same problem (10 different desktop clients) is an engineering nightmare and it robs a service of "economies of scale" enabled improvements.

I don't want to read a wall of text to understand something and neither does my mom. We want to search a keyword (or "best chat app"), download an app, and use it for its purpose. That might not be optimal, but you won't see wide spread adoption without it. If you tell me "matrix is best for chat" and I can't search for matrix on google, one click download a client, and be chatting with another person who did the same with minimal setup, it's not just a non starter as far as getting widespread adoption, but it's very far from "drop in." I don't personally have a single friend who has asked me to use matrix/a matrix client, or told me how awesome matrix is. Matrix supporters should ask themselves why the main place you ever see Matrix mentioned on hacker news is in posts about Signal.

Protocols don't win customers, user interfaces do. The average end user wants to download an app and use it without having to understand what "federation" or what the security implications of something is or who owns what data. They want their most knowledgeable friend (or reddit/hn) to tell them what to use and then use it and trust that they know what they are talking about.

I'm pretty confident that as long as this page: https://matrix.org/clients/ looks like that, matrix will never see widespread adoption and it will never be the obvious choice except among the people who prefer to move their documents around with rsync and know what IRC is.

Matrix being a brand for a protocol rather than a full chat app is another self harm. The customer for a protocol is software engineers. The customer for a chat app is all humans with a phone.

People search for "email clients. Try searching for "Matrix clients". Element is the best thus far, IMO.

"Widespread adoption" includes the EU's military, healthcare and government, so I wouldn't be so certain you'll end up being right. It's hit 60m publicly addressable accounts, which doesn't include any private servers or any kind of healthcare, gov or military: https://news.itsfoss.com/matrix-sixty-million-users/

EU is forcing interoperability standards. I have a gut feeling that you will look silly in five years time, but I'll buy you a very nice craft beer if I'm wrong. Hit me up on the bet in 5 years time: me@hammyhavoc.com

You were discussing "drop-in replacements", I gave you a drop-in replacement that still maintains interoperability with WhatsApp et al, which Signal does not. Classic shifting of the goalposts.

If the messages are still sent via Facebook servers, that is not a WhatsApp replacement, it's an alternative WhatsApp Client, it's still at it's core "performing" WhatsApp. It is not a WhatsApp replacement, but a WhatsApp client replacement. I moved to signal specifically to sever my relationship with Facebook because I don't trust Facebook. Not communicating with Facebook is the feature that made signal appealing and made me want to replace WhatsApp (not the client, but the service as a whole) with something else.

I think conflating the idea of replacing "WhatsApp the service" and replacing "the WhatsApp Client" is the crux of our talking past each other and why my focus is on how it's UI compatible and ignoring the idea of protocol compatibility.

> You're on HN, it's nerdville, expect more interest in the protocol than clients.

We are on HN, and it's nerdville, it's true. It is the place where the very same comment (rsync files around) I am using to criticize the hubris of nerds (myself included) was made. (https://news.ycombinator.com/item?id=8863). Plug and Play (referenced in the HN link) is a winning idea. The crux of my statements here is how amazingly plug and play signal is, specifically for WhatsApp users.

> This is as daft as Googling "email" and expecting a de facto client.

I am saying this in good faith and I hope you take it as a good faith comment and not an aggression, but have you googled "email"? I understand the point you were making and I think it applies to a lot of other protocols, but googling "email" returns gmail 1st and 2nd, then outlook 3rd. Wikipedia is the 4th result...

> Try searching for "Matrix clients". Element is the best thus far, IMO.

I hate to respond so directly to this too, but have you googled "matrix clients" because I did, and I am pretty confident the results don't prove the point you wish to be proven. The number 1 result is the matrix website matrix client page I had already found by searching "matrix app". The second and third results are top 10 lists. The 4th result which you have to scroll down to see is Element. How do top 10 lists outperform clients themselves? That paints a pretty bleak picture for the difference in quality between the best app and the worst app.

Engineers have a way of being arrogant when they think the thing they have is technically superior or have a grand vision. Betamax was better right? Being protocol first over customer first, to me, is a form of hubris. The customer experience is what wins, everything else is just an implementation detail for the vast majority of people, even engineers.

> Widespread adoption" includes the EU's military, healthcare and government, so I wouldn't be so certain you'll end up being right. It's hit 60m publicly addressable accounts, which doesn't include any private servers or any kind of healthcare, gov or military: https://news.itsfoss.com/matrix-sixty-million-users/

This is definitely interesting and something I find worth considering. I certainly have an American-centric view. Clearly it's in every countries best interest not to have all their communication going through foreign servers, so the idea of Europe migrating to their own chat, much like Korea chose Kakao, doesn't surprise me. I kind of suspect that the idea of federating chat before the balkanizing of it might be too forward thinking/pre-mature.

> EU is forcing interoperability standards.

It will be interesting to see if American fights this or embraces it.

> I have a gut feeling that you will look silly in five years time

I would not be surprised to see Element, for example, become the most popular client and obvious choice. All the comments, FAQ's, etc, already seem to acknowledge Element is the right choice, but the structures that make it easy to download (google ranking result, links from the main matrix page, people saying "use Element," not "use Matrix") are not yet in place. When Element eclipses Matrix or Matrix starts being talked about outside the context of chat apps I'll start to take matrix seriously. Certainly my criticisms are not based on immutable flaws, but what I think are strategic blunders.

As a final note this is directly from the matrix website:

  Empowering the end-user
    The user should be able to choose the server and clients they use
    The user should be able to control how private their communication is
    The user should know precisely where their data is stored

`sum(dilemma) + sum(onboarding/required knowledge) <= resistance`. anything for which `reward < resistance` will probably not succeed. That's my calculus. Minimize choice, minimize required knowledge/onboarding, maximize reward. That is a winning combo. I don't think matrix is optimizing for that. I guess we'll see if I have to find the flaw in my reasoning or not in 5 years.

The only reason this doesn’t happen yet is that Matrix clients like Element are still too geeky, and joe public doesn’t care about the advantages of open decentralised e2ee comms. Our plan to fix that is to transform Element’s UX; hide the decentralisation complexities, and let it punch its own weight againdt the centralised alternatives - https://matrix.org/blog/2022/08/15/the-matrix-summer-special... has more details.

The user would still need to understand it’s talking on an open network though, because that’s what it is. But they don’t need to care that much about it.

Googling "matrix client" leads you to the matrix website clients page rather than Element or the domain of the most popular client. I have to scroll downward before I even see Element. Element showing up after 2 "best 10 matrix apps" articles is an ecosystem failure and to me communicates immaturity.

When I see signs of immaturity, I immediately assume weak/untested security. I want to know other people are trusting something before I trust it. Signs of immaturity also make me cautious about making recommendations to someone else because I don't want to become someone else's tech support.

FWIW, if you google either e-mail or SMS, there are client(s) in the first 3 results for both.

genuine question from someone oblivious to messaging advances in the last decade.

Cryptographers praise Signal because the protocol makes sense and because it's not run by someone as data-hungry as Meta or Alphabet (though I think it's hosted on AWS).

Threema is a good alternative if you want username/password, but has less users (probably since it's a paid app) and less neat security properties (not even forward secrecy).

I agree Signal is not perfect and has never played the Open Source game very well (even under Moxie reports from the community were largely ignored) and the MobileCoin move is weird. I also have not followed the direction the project has taken since Moxie left. However, the _entire_ code is open source (which iirc is not the case with Telegram) and the protocol makes sense (and has been extensively studied), and there is a lot of eyes on the development. I remember code changes that suggested a pivot to not using phone numbers as identifiers (i.e. maybe requiring them for registration but not showing it to everyone you talk to).

I wonder whether MLS will go anywhere and actual projects will adopt it. Last time I checked it did require consensus on message ordering, which seems to make it less well-suited for non-centralized protocols like Matrix, but we'll see.

Services like Signal, Whatsapp, Keybase, or iMessage that provide e2e encryption for all chats, group or otherwise, (albeit with differing levels of implementation security) have chosen to do so at the expense of things like mobility of chat history across devices and the ability to easily discover and join new group chats and instead focus on a less organized, more ad-hoc form of messaging that's a rather different use case than Telegram's.

I'd argue it hasn't. Signal still has no way of backing up your chat history (with photos, etc). Lose your phone and it's all gone forever. The PIN that the app annoyingly tells you to set up does not serve as an encryption key for your backups. There are no backups.

Once again, if your phone dies (this happened to me recently), all your data in Signal is gone forever. And there is no way to prevent that.

In this day and age, I consider this unacceptable. That is not a "useable security product".

On the other hand, I consider this a feature.

I'm not saying you are wrong, but I am saying different people have different ideas and requirements about how they want things like this to work.

For me, most of my Signal chats have disappearing messages enabled, to intentionally ensure there is no long term archive of conversations (assuming you trust the other people to not be screenshotting everything). It gets you into the habit of storing message that may be useful later (mostly for me stuff like event details or addresses), with the benefit of making everybody in the conversation a little more inclined to treat it all as ephemeral and be somewhat more candid then you might be in SMS or email. Not _quite_ as candid as face to face in private, but closer.

There's a widely used and agreed on signal for most of my group chats, where setting disappearing messages to 5 minutes is understood to mean "juicy gossip or legal grey area chat is about to follow" and setting it back to 8 hours or 1 week means "OK, we're done with that discussion, back to regular chat".

Agreed. But I can't convince people and family to use Signal if I know that one day they will inevitably lose the pictures of their loved ones. Because that's how most people use communicator apps.

opens Signal, scrolls for weeks

You could show them where the Save button is — that's how "most" people use messaging apps. Even "friends and family".

Not a proper solution but a hacky workaround possibility.

Save messages and media you want to keep outside of your encrypted chats...

cool, but entire carriers being compromised has never been a concern. it's state agencies forcing carriers to compromise individuals.

>I don't understand why everyone wants Signal to be something it's not

we don't. we just warn people against using it. it's not a privacy tool, it's a larp toy like a commercial VPN.

As far as I'm away, Signal is used by plenty of people who may be targeted by state agencies. Has there been even one "High value target apprehended because Signal" headline?

There have been a few "high value target apprehended because AN0M" headlines, and if you keep an eye out for it way more headlines/articles where you go "Yeah, that's totally another AN0M bust they just haven't publicly attributed it".

I also suspect (but have nothing more than suspicion to go on here) that companies like NSO can probably exploit phones deeply enough that they can exfiltrate screenshots of Signal. But that they do so at such high prices that it is rarely used and even more rarely hinted at publicly.