djgaven588 / icc Goto Github PK

Encryption is very important if you want to send information which shouldn't be seen by those outside of your conversation, so why isn't it supported yet?

All clients should at least acknowledge encryption requests from servers, allowing them to safely fail before an encrypted message arrives if they aren't compatible.

All servers are not required to implement anything related to encryption other than a "Doesn't support encryption" message. A client will be able to determine the type of encryption being used based on the first message the server sends. The first message will determine the method used for encryption. A server which uses RSA to send a AES key will respond with something like "RSA->AES". One which uses the password for the server for encryption will respond with something like "PASS", implementation for this not planned ATM.

This will be a useful feature when complete, but will need to be planned properly to make sure compatibility will not be an issue.

An example implementation would look like this:
-Client connects to server
-Server responds with "RSA->AES", followed by the RSA public key.
-If the client doesn't support it, disconnect and notify the client
-If the client does support it, continue
-Client responds with their public RSA key, and saves the server provided one
-Server responds with AES key and removes all information related to RSA
-Client removes all information related to RSA, and uses AES to continue normally

The server code should be better at allowing functionality to be modified. You should be allowed to do everything from change how new connections are established, to modifying how login is handled.

The server will still need to be compatible with the client though, so any changes should still work with the client.

An example could be that you want to request the password for the server, then request the username and password of the individual user. This adds the ability for a server to have user authentication setup.

Note: Passwords should avoid being sent over the network, and instead a one time authorization code from another source (Phone, Email, ect.) should be used. There is no encryption currently, so this is the safest way to handle it at this time.

To show off some things a server can do, there should be more demos which can show them off. These might be built into existing examples, as they will still require the base functionality from them to work.

Here are some examples of what could be done:
-Discord integration, allow communication between a Discord and ICC server. This would be handled by a Discord bot integrated into the server
-Channels, being able to separate servers into chunks would be a good feature. This would just add something like "#general " to the beginning of a message and the client would handle everything from there.
-Message history, loading the history of a chat would be nice in some situations. This might be a command on some servers instead of base functionality as it isn't exactly something all clients would work too well with. Specifically, console clients might have issues with large amounts of messages because it just doesn't display well.
-And more! There is SO MUCH functionality that could be added to demonstrate advanced features you could make.

Telepathy hides some functionality that will be required for building a client. This is in the sending and receiving code.

Possible future feature:
Use web sockets to allow compatibility over all platforms.