README.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# 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.
## 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
## Fake packets
To prevent duplication of packets, the hash of packets should be stored and each request should check against the hash list if it has not already been received
## Functionality for dependant applications
This database is used for chat application, and in chat applications you may want to have the ability to invite users to a channel using an invite link.
Functionality for an invite link that is only available for a certain amount of time can be added by generating an invite packet as an admin user with timestamp
and the user that should be added can be excluded from the signed packet, allowing any user to be added to channel while the invite link is valid.
The invite link could be converted to hex string to make it shareable and also generate QR-code using it to make it easy to join with mobile device.