Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Hive2Hive discriminates between two different types of messages:
For the direct and fast synchronization between currently online User Clients, so-called notifications are used.
Alice wants to send a notification to Bob.
- Alice gets Bob’s User Public Key from the DHT.
- Then, she reads Bob's User Locations. In this case, only one of Bob's User Clients is online.
- 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.
- 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.