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
38
39
40
41
42
43
44
45
46
47
48
49
50
|
# 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.
# 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 by length
## 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.
## UDT
Combine opendht with udt. Use opendht to find other peers and udt for communication.
## New node download
Use a merkle tree and when requesting new nodes when connecting, send X latest hashes and other peers can send you where you have missing data and send you it.
If all X hashes are wrong, send older hashes.
However if we are only using opendht to find other peers, we might as well use https://github.com/DavidKeller/kademlia or https://github.com/ytakano/libcage
## Safe multi-threading SQL handling
Create SQL classes with mutex for performing prepared statements. Currently the database can crasah if DatabaseStorage methods are accessed at the same time
from multiple threads
## Find a way to deal with u64 in sqlite
Used by timestamp and action counter
## Packet sorting
When you get packets from remote peers, you might get NodeAddData before Node, in that case the packets should not be discarded but there should be
a flag for NodeAddData to handle such situations
|
