Messaging - Hive2Hive/Hive2Hive GitHub Wiki

Hive2Hive discriminates between two different types of messages:

Both types of messages are encrypted and authenticated.


Notifications

For the direct and fast synchronization between currently online User Clients, so-called notifications are used.

Example

Alice wants to send a notification to Bob.

Notification Mechanism

  1. Alice gets Bob’s User Public Key from the DHT.
  2. Then, she reads Bob's User Locations. In this case, only one of Bob's User Clients is online.
  3. Alice encrypts the notification with Bob’s User Encryption Public Key, signs it with her own User Authentication Private Key and sends it to Bob’s user client.
  4. After the authentication verification with Alice's User Authentication Public Key, Bob decrypts the notification with his User Encryption Private Key.

User Profile Tasks

It may happen that no client of a given user is online. Thus, the user's User Locations list is empty and cannot be used to fetch contact information. For such scenarios, Hive2Hive uses so called user profile tasks to achieve an indirect communication.

When a sending user (A) wants a receiving user (B) to modify her private User Profile, but the receiving user currently has no online client, the sending user cannot send a message. Instead, the sender can put a user profile task to a specific other peer (C).

Deriving the Location Key of this other peer (C) in the receivers (B) stead can be achieved by hashing the User ID.

As soon as the receiving user (B) logs in to the network, it checks, fetches and processes the task queue stored on peer (C).

The peer responsible for a user's user profile tasks (C) stores all tasks in an ordered queue. The order needs to be conserved because there might be some dependencies between consecutive tasks. Hive2Hive achieves this ordering in the DHT by using Content Keys: The current timestamp, instead of a constant, is encoded and used as content key. This way, it can easily be reconstructed.