Good luck, ping me when I can be a tester.

Will it be something similar to OMEMO?

https://conversations.im/omemo/

Why not taking Signal and implementing some useful privacy features on top instead? Like usernames and fdroid builds.

Signal ?

@endor Agreed. The only thing keeping me from adopting Signal ( and hesitatingly continue using Telegram ) is the fact that I need to share my phone number to connect with someone on Signal whereas that is not the case on Telegram. You can connect with anyone with a username without sharing your phone number on Telegram.

@Jilano it's device Id-based, maybe, if you sell your phone some1 can hach into your conversations. (But not sure aboit this.)

Guys, Signal seems a bit confusing. It is not decentralized and it changes clients' keys after reinstallation of the app whereas my idea is to make impossible to connect to same people by loosing encryption keys. Public key change is very dangerous and the cons of using Signal over Telegram is that Signal notifies its end user about key change

@martikyan you're kinda mixing things up there. Notifying a user that their contact changed keys is a good thing: if they actually changed keys voluntarily (eg if they suspect a compromise) then you'll avoid sending new messages to their old (potentially compromised) key; if they didn't voluntarily/knowingly change keys, then they've likely been comprimised again - same story.

From there, it's easy to see why changing keys after a reinstall is a good idea.

As for hacking into someone's conversations: can't do that unless you manage to get their keys or re-register their phone number on a different device. To prevent the latter, you can set up a registration password, so that nobody can re-register your number anywhere else without it.

"My idea is to make it impossible to connect to the same people by losing encryption keys"
Please rewrite that sentence, it makes no sense.

Dear @endor "changing key voluntarily" - what does this mean? Signals servers are open source, but we can't be 100% sure that exactly that code is deployed to serve. That passwords and phone numbers are problematic. Using that kind of mechanism, you can't be 100% sure that if you write to some1 a message, the destination is the same person always.

@endor if we exchange public keys trough some company's servers, how can we be sure that the server passes the same pubkey to the other client?

@martikyan if you're that paranoid, go ahead and host your own server.

I think what you're looking for is de-centralization. And there's matrix.org for that ( JICYMI ).

There's also wire.com, but I'm not sure whether anyone actually runs their own wire server, even though the code is open source ( https://github.com/wireapp ). Or maybe, it's just not popular enough that people actually tried self-hosting their own wire-server.

@martikyan we can check key fingerprints out-of-band

@shine the main issue with running your own Wire server is that there's no federation with others (afaik).
Typical server deployments are targrted toward enterprise customers (like a large company/group with hundereds/thoudands of employees). Otherwise, you're just gonna be talking to yourself.
(Yes, I've been considering doing it myself)

Don’t we have a shitloads of these already ?

@shine yeah, I am aware of matrix protocol, but it solves the decentralization problem only. I couldn't find a messenger that suits me. Also, if I host the Signal myself, I will know surely that it is what the source code is and only me. 😅

Guys, there is a protocol Tox, I want to create this kind of thing. The problems here is it leaks your IP to your "friends" and you have to be online to receive messages. You could try using Tox with Tor, but it would be much more complex. It's already complex.

Sounds similar to Keybase