Added IDEAS.txt and added checks to 2 net_crypto functions.

core/net_crypto.c

@@ -154,6 +154,10 @@ void random_nonce(uint8_t * nonce)
 //return length of recieved data if successful
 int read_cryptpacket(int crypt_connection_id, uint8_t * data)
 {
+    if(crypt_connection_id < 0 || crypt_connection_id >= MAX_CRYPTO_CONNECTIONS)
+    {
+        return 0;   
+    }
     if(crypto_connections[crypt_connection_id].status != 3)
     {
         return 0;
@@ -184,6 +188,10 @@ int read_cryptpacket(int crypt_connection_id, uint8_t * data)
 //return 1 if data was put into the queue
 int write_cryptpacket(int crypt_connection_id, uint8_t * data, uint32_t length)
 {
+    if(crypt_connection_id < 0 || crypt_connection_id >= MAX_CRYPTO_CONNECTIONS)
+    {
+        return 0;   
+    }
     if(length - crypto_box_BOXZEROBYTES + crypto_box_ZEROBYTES > MAX_DATA_SIZE - 1)
     {
         return 0;

docs/IDEAS.txt

@@ -0,0 +1,27 @@
+A couple of ideas posted in the threads.
+
+#############
+    Prescence (online/offline)
+     - A user's id being present with a valid signature in the DHT implies they have been online recently. A ping to the user would confirm this, as well as notifying them that you are online. If both friends in a pair actively search for the other then disruption due to lag in inserting records will be mimimised
+     
+    Username (nick) changes
+     - When a user wants to change their nick they are free to do so, the nick is not cryptographically significant. The nick change could be shared in-band with the chat (ie, each message in the format "username - message") or out of band, perhaps in the dht values or in the ping messgaes.
+     
+    File send
+     - I see a file being sent as ultimately the same as an audio stream or a video stream being sent, they could use the same protocol parts. The client would handle what to do with the data whether it is a stream of media data or a stream of b64'd file. both would require explicit verification from the other participant. This would also allow sharing of streamed files, eg incomplete downloads.
+
+##############
+
+- ability to log in with username and password
+    possible implementation: store keys in a server and use user/pass to retrieve keys from server transparently
+- looking up people and adding as contacts, etc by name or username
+    possible implementation: store pubkey-hash/info correspondences in a public directory, integrate access into client
+- portable contact list/profile/other account data
+    just store it along with keys in aforementioned server; cost of storage could rise... potential problem
+- POSSIBLY interfacing with regular phones. probably not possible, but plebs might complain (THIS IS EXPENSIVE (hence 'probably not possible')) <3
+
+IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso
+
+
+##############
+