Closed jD91mZM2 closed 6 years ago
So, the cli really doesn't work well with this unless you force ncurses. Then, if you click on a user, you will be moved to a channel (being the chat with that guy) where if you haven't ever set it up, show like: Enter his public key. Your public key is "blabla". If the guy enters it, you say "Awaiting handshake" or something and again that public key. If handshake is completed, save the keys and remember that it can communicate.
Good idea, but we need a command for it too. Also, is this too complicated? I don't know, just asking
For cli it is. this needs a visual representation that the command line interface just cannot provide really.. But you could try like /join (or even better /msg) user and it will do everything I just described in my previous message!
I mean for the server and such. It now needs user channels as well as normal channels. Unless we send messages without storing them. Personally I like that idea, as it makes it really secure. The message is sent, over SSH, plus being encrypted with RSA. Plus the fact that the official server doesn't even store them, so the server owner can't even go and read them without writing code for logging or something
Really nice, but question: Does the client store them? Or does it work like a session thing: saved in the ram until you close the program?
Yeah, session thing. That might be annoying though, I don't know. Generally unnamed (soon to be, though!) is meant to be like discord servers. Doesn't have a system for DMs, and if it does it would have to rely through a server.
Not annyoing at all I say... I mean IRC doesn't even store channel messages. This is much better. And somebody could say this could lead to even more security!
Should we support editing private messages? Should #10 also use the same command as sending a PM?
EDIT: I just realized that could be confusing.
What is the menu for this? Same as a channel menu, or just some popup like "somebody private messaged you: potato"?
No editing.. This should be like only "received message" packet. Only.
What is the menu for this? Same as a channel menu, or just some popup like "somebody private messaged you: potato"?
The menu is the user menu, you know. So, basically just like the channel menu
Ah damn, that makes things complicated :stuck_out_tongue:
Well, it is needed. Discord has it!
Yes but Discord isn't written to be a single-server application.
EDIT: I'm not trying to get away, I am fully ready to code this. I just do wanna ask if it's not better to show a Minecraft-styled "User wispered to you". Reason behind this is because I don't have to override the message send code, store cache on all private messages, et.c. Also you could get private messages no matter which channel you are in (or if none).
Ok, that sounds good to me.. Although if I remember correctly IRC works like I described before. Anyways, whatever you may choose is a good option. Having PMs is important.
Vote: Easy way or the hard way? Vote with :+1: or :-1:.
Calling all forces because I can't decide @tbodt @inferiormartin @Mnpn03 @bela333
Threema puts a QR code on the screen of your phone, and anyone who wants to send you messages has to scan it.
Signal sends the public keys to the server, if you want to know for sure you're talking to the right person, you have to open a screen that shows the public key for both parties in both text and QR code form, and you can make sure it shows the same thing.
@tbodt this isn't about how it works, it's about how the UI looks. If you meant the QR thing, that's a cool idea. Still leaves the question open: How does the actual messaging look like.
I just realized something. Since the public key isn't secret, can't I just send that to the other person, and that other person sends their public key back (encrypted or not, doesn't actually matter all that much)? The only chance of finding the private key from the public key would take forever
Not sure what that meant lego... Anyways @tbodt please vote.
Which part of the message? @ELChris414
EDIT: I just realized the "easy way" has another plus. In another comment I mentioned DA DANK MEEMZ being ran only by certain people, and then I thought what about if it would DM everybody who is online and have opted in... So like "DA DANK MEEMZ whisper to you: \<link>". Maybe even displaying images with termplay kek
Second.
Oh, that was sort of unrelated to the question but not really: A few encryption algorithms are using two "keys" instead of one to encrypt/decrypt the message. Each key does one thing. For example RSA is using public and private keys, because it's "asymmetrical encryption". Public keys encrypt, private key decrypts. That's why they got their name. It doesn't matter if somebody gets your public key and encrypts a bunch of messages, because they can't be decrypted with it. But the private (sometimes called "secret") key is secret, because you don't want others decrypting your messages. Makes sense?
I know so far.
New question: Should there be a separate private key per recipient? Like should decrypting messages from @ELChris414 be done with the same key as from @tbodt? I mean, more keys would probably mean slower, and it would be more difficult to replace if one leaks. But different ones means @ELChris414 can't just give his public key to @tbodt and tbodt can suddenly send me messages...
I thought that was clear, of course different private keys. OF COURSE man.
EDIT: A computer should have its own public/private pair. So, you don't need to send a different public key for each person in different servers.
@ELChris414 What? Getting mixed messages here. Did you think I meant everybody on the server should have the same private key? LOL! No, I meant per recipient. Which your edit seems to be for.
Then how does my public key allow tbodt to message you? Our public keys SHOULD be different. Every user must have a public key (in my previous comment also I said it should be system wide but that's another story).
Ok so a complete new keypair per conversation, ok.
Actually, should keys just be exchanged automatically? I mean, they're only public keys either way. Not that secret.
EDIT: Actually, then the server owner could send messages, unless we also sign the message.
@ELChris414 @tbodt
Well that will just work like IRC, but safer. Maybe a config option whether you automatically send your public key or not.
Because I wouldn't want any dude in any server to have the right to DM me.
EDIT: The way it could work is this. Someone makes a request to DM. You accept it and automatically you send your public key.
An idea:
/setupkeys <user id>
generates a new key pair, displays the public key and asks you for your recipient's public key.
/msg <user id> <message>
encrypts and sends a message to the user (assuming keys are set up).
The other user also sets up their keys.
If you get a PM from somebody you haven't set up keys for, it either doesn't display it, or it displays something like "\<user> privately messaged you something, but your keys aren't set up."
how does someone send you a PM if you don't have a key?
ok so when you run synac for the first time it generates a key, uploads it to the server, then you can just /msg user message and it asks the server for the key. if you want to guarantee you're talking to the right person you can manually compare the key. but there are problems.
actually, just use FFI to talk to https://github.com/WhisperSystems/libsignal-protocol-c. you'll get something really good.
Uhh the reason I'm using E2E is because I don't trust the server. And you can PM somebody without a key is if you reset program data, you or the sender edited your/their database, or the sender is using another client which doesn't E2E encrypt shit
I said signal
What does signal do which pure RSA doesn't?
solves all the problems
What problems?
why do we have this issue if there are no problems
We are discussing how the interface should look. Signal doesn't make a UI for you, does it?
Ok, so you should try the latest version. Then discuss how you think the UI could be improved.
So, got to try it, very nicely implemented! But, a way to see your own messages will be very welcome.
Good idea! Thanks!
One thing to consider is that encrypted messages can only be seen by somebody with the right private key. So perhaps this should merge with #10 and become some sort of
/msg
system anyway. Like if you message a bot it sends that command, while if you message a user it gets encrypted with whatever public key you choose.