Managing KVDBs

At their core, KVDBs provide a secure way for assigned members to exchange encrypted entries.

KVDBs allow users to access key-value databases.
Each Context can contain any number of KVDBs with a unique identifier (kvdbId) used to distinguish them.
KVDBs do not need to have unique names or assigned public keys.

Permissions

KVDBs differentiate two types of users - Managers and Regular Users. The table below shows the differences in their permissions:

Activity	User	Manager
Sending entries	yes	yes
Editing KVDB	no	yes
Deleting entries	only their own	all entries

The values above are the default policy values defined by PrivMX. To read more about Policies and learn how to modify them, go to Policies.

Initial Assumptions

The initial assumptions for all the code examples below are as follows:

    #include <privmx/endpoint/core/Connection.hpp>
    #include <privmx/endpoint/kvdb/KvdbApi.hpp>
    #include <privmx/endpoint/core/Buffer.hpp>
	
	using namespace privmx::endpoint;
    // ...

	/* 
	All the values below like BRIDGE_URL, SOLUTION_ID, CONTEXT_ID 
	should be replaced by the ones corresponding to your Bridge Server instance.
	
	The private keys here are for demonstration purposes only. 
	Normally, they should be kept separately by each user and stored in a safe place,
	or generated from a password (see the derivePrivateKey() method in the Crypto API)
	*/

	std::string BRIDGE_URL {"http://localhost:9111"};
	std::string SOLUTION_ID {"YOUR_SOLUTION_ID"};
	std::string CONTEXT_ID {"YOUR_CONTEXT_ID"};

	std::string USER1_ID {"user_1"};
	std::string USER1_PUBLIC_KEY {"PUBLIC_KEY_1"};
	std::string USER1_PRIV {"PRIVATE_KEY_1"};

	std::string USER2_ID {"user_2"};
	std::string USER2_PUBLIC_KEY {"PUBLIC_KEY_2"};

	std::string USER3_ID {"user_3"};
	std::string USER3_PUBLIC_KEY {"PUBLIC_KEY_3"};

    // initialize Endpoint connection and KVDBs API
	auto connection {core::Connection::connect(USER1_PRIV, SOLUTION_ID, BRIDGE_URL)};
	auto kvdbsApi {kvdb::KvdbApi::create(connection)};

	// users and managers
	std::vector<core::UserWithPubKey> kvdbUsers;
	kvdbUsers.push_back({.userId = USER1_ID, .pubKey = USER1_PUBLIC_KEY});
	kvdbUsers.push_back({.userId = USER2_ID, .pubKey = USER2_PUBLIC_KEY});
	kvdbUsers.push_back({.userId = USER3_ID, .pubKey = USER3_PUBLIC_KEY});

	std::vector<core::UserWithPubKey> kvdbManagers;
	kvdbManagers.push_back({.userId = USER1_ID, .pubKey = USER1_PUBLIC_KEY});

To create a KVDB, you need a name and a list of public key - userID pairs. Due to the fact that each KVDB is inside a Context, all the public keys have to be registered inside the given Context. You can do it using PrivMX Bridge API.

After creating a KVDB, all the users with management rights will be able to edit the KVDB.

Below you can see some examples of creating KVDBs that function as a database feature in your application, with access management capabilities.

auto kvdbId {kvdbApi.createKvdb(
	CONTEXT_ID, 
	kvdbUsers, 
	kvdbManagers, 
	core::Buffer::from("some kvdb's public meta-data"), 
	core::Buffer::from("some kvdb's private meta-data")
)};
auto kvdb = kvdbsApi.getKvdb(kvdbId);
kvdbsApi.updateKvdb(
    kvdbId,
    kvdbUsers,
    kvdbManagers,
	kvdb.publicMeta,
    core::Buffer::form("some other kvdb's private meta-data"),
    kvdb.version,
	false,
	false
);

Three additional options are available when changing the list of users inside a KVDB:

force - applies an update, without checking the current version;
generateNewKey - generate new symmetric encryption key for KVDB. It's useful when a user is removed and you want to prevent them from accessing any new data in the KVDB.

Permissions

Initial Assumptions

Creating KVDBs

On this page