odhtdb

Decentralized key-value database using sibs-pubsub for decentralized communication. CRDT is used to replicate data across nodes. It is designed to use less bandwidth over speed.

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.

Password

Data is stored encrypted on disk by using the hash of the user password. The password is hashed using Argon2i.

Limits

Only 800kb of data can be used for each add. You can add more data by using add several times.

TODO

Data limit

Allow more than 800kb 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.

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

Resend packet

If you get disconnected before data is sent or you send data when everybody else is offline, then resend the data when you reconnect (dhtKey.getResendOldDataKey)