# odhtdb
Decentralized key-value database using OpenDHT for decentralized communication.
## End-to-end encryption
Data is signed using ed25519, encrypted using xchacha20-poly1305 ietf and hashed using Blake2b.
See src/Encryption.cpp, src/Signature.cpp and src/Hash.cpp.
Also check Scheme.md for packet construction.
# Limits
Only 65kb of data can be used for each `add`. You can add more data by using `add` several times.
User and group name can't be longer than 255 characters.

# TODO
## Data limit
Allow more than 65kb of data to be added at once
## Node banning
Ban nodes that spam put or get (malicious nodes). If data is routed, then the router node should first ban the malicious node so the router node is not banned if it's not malicious.
But how can we know if data was routed? does opendht expose this to other nodes in some way?

Another method could be for nodes to be required to generate a key pair that takes long time to generate and sign messages with them.
If we are spammed with the same key pair, we can ban messages that comes from that key pair. The malicious node would require to generate a new key pair
which would take some time (we can make key generation take 60 seconds).
## Error handling
Currently operations are executed without knowing if they succeed or not. Operations should be modified to perhaps return std::future or use a callback function which is called with the operation result.
## Safely store private keys
Use Argon2 to store private keys
## Authorization
Verify the user that uses 'add' operation belongs to a group with write access to the key. If authorization fails, store the request
for a period of time since the request can be received before we have got the request to add user to the group with write access for the key.
This can happen because we dont verify all peers get the data so by the time one peer gets the data, they could have got other data from us
(depends on network routing, network speed etc). Out of order requests also allows the network to operate faster.
Operations are parsed in order for the receiving peer using operation timestamp.
## Padding
Packets should have padding in the encrypted data to prevent peers without encryption key to analyze content