Managing Threads

At their core, Threads provide a secure way for assigned members to exchange encrypted messages.

Threads allow users to communicate using topic-specific communication channels.
Each Context can contain any number of Threads with a unique identifier (threadId) used to distinguish them.
Threads do not need to have unique names or assigned public keys.

Permissions

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

Activity	User	Manager
Sending messages	yes	yes
Editing Thread	no	yes
Deleting messages	only their own	all messages

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:

    /* 
    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)
    */
 
    const BRIDGE_URL = "http://localhost:9111";
    const SOLUTION_ID = "YOUR_SOLUTION_ID";
    const CONTEXT_ID = "YOUR_CONTEXT_ID";
 
    const USER1_ID = "user_1";
    const USER1_PUBLIC_KEY = "PUBLIC_KEY_1";
    const USER1_PRIV = "PRIVATE_KEY_1";
 
    const USER2_ID = "user_2";
    const USER2_PUBLIC_KEY = "PUBLIC_KEY_2";
 
    const USER3_ID = "user_3";
    const USER3_PUBLIC_KEY = "PUBLIC_KEY_3";
 
 
    class App {
        uint8ToStr(arr) {
            return (new TextDecoder()).decode(arr);
        }
 
        strToUint8(text) {
            return (new TextEncoder()).encode(text);
        }
 
        // ...
 
        run() {
            // Initialize Endpoint and its Wasm assets
            await Endpoint.setup("/public");
 
            // initialize Endpoint connection and Threads API
            const connection = await Endpoint.connect(USER1_PRIV, SOLUTION_ID, BRIDGE_URL);
            const threadsApi = await Endpoint.createThreadApi(connection);
 
            // ...
        }
    }
    new App().run();

To create a Thread, you need a name and a list of public key - userID pairs. Due to the fact that each Thread 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 Thread, all the users with management rights will be able to edit the Thread.

Below you can see some examples of creating Threads that function as a chat feature in your application, with access management capabilities similar to those found in other popular collaboration tools.

const thread = Endpoint.connection().thread('THREAD_ID');
const threadInfo = await thread.info();
 
const newUsers = threadInfo.users.map(user => ({
//Your application must provide a way,
//to get user's public key from their userId.
userId: user,
pubKey: 'USER_PUBLIC_KEY'
})
);
 
const newManagers = newUsers.filter(user =>
threadInfo.managers.find(manager => manager == user.userId));
 
const newPrivateMeta = {
title: 'New thread name'
};
 
await thread.update({
users: newUsers,
managers: newManagers,
privateMeta: serializeObject(newPrivateMeta),
version: threadInfo.version
});

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

accessToOldDataForNewUsers - if marked true, the newly added users will be able to access messages sent before they joined the Thread;
force - applies an update, without checking the current version;
generateNewKey - re-encrypts messages in the Thread. It's useful when a user is removed and we want to prevent them from accessing the Thread.

Permissions

Initial Assumptions

Creating Threads

On this page