4zm / dandelion-message-service Goto Github PK

Should we add any restrictions on message contents?

We could e.g. strip html / js to avoid attacks if that data is presented in a browser, but is this really desired?

Modify the protocol so that clients can request messages that have particular senders or receivers only.

This might be useful to reduce traffic in case a database gets filled with spam. It will however also make the entire distribution model fail if all clients behave completely egoistically.

There is no notion of time (or even a partial order) in the distributed message DB. Introduce a timestamp field in the messages that clients can choose to fill out to give a hint to GUI's. Note: the time of different computers will differ so there is still no strict partial order.

Today all data is abandoned if a transaction is interrupted. Don't do that. Make the transaction more robust and save all valid data.

When receiving data the client should perform some form of validation of incoming data and terminate the connection if things look funky.

Use the cryptographically safe random generator in the pycrypto library (Crypto.Random) rather than the python built in.

I'm planning on writing and commiting a new README.md for fancy formatting.

A good way to learn some github, markdown and issuetracking.

http://github.github.com/github-flavored-markdown/

On connection failure with known (transient) servers, try to sync less frequent before finally eliminating them from the known servers list.

Implement two connection modes. One permanent (connect - sync - wait -sync - ... ) and one transient (connect - sync - disconnect).

Update the protocol with new commands for the permanent connection type: TURN, WAIT, ALIVE CHECK

Update the protocol document.

Implement in a way that:
A) Re-uses the same code for a single direction sync in all cases
B) Is oblivious of the underlying data transfer mechanism (tcp/ip, bluetooth, etc.)
C) Introduces a minimum amount of state in the client server connection.
D) Is resilient to denial of service by resource (connection & thread) exhaustion.

Support use of local IPv6 address and sync with remote IPv6 server.

Check data structures and library calls.

Implement message data transform and padding prior to RSA encryption to make it secure.

Use the RSAES-OAEP padding schema from PKCS#1 or something like that.

Currently private identities (private key components) are stored in the data base as plain data. That's no real security at all.

Add a symetric crypto step that uses a password + salt to encrypt the key components.

Add an additional discovery mechanism: IPv6 LAN discovery (ping6 -c4 -I eth0 ff02::1)

Encrypt the sender identity in messages that have a receiver. Currently, only the message text is encrypted.

Parallelize the synchronization process (spawn multiple clients to sync with different data bases).

An impl. would probably use a small thread pool (2-10 threads).

Note: Must document thread safety constraints of different modules.