libqaul/messages: adding sender type id concept
In previous iterations of the libqaul API there was the concept of a group hard-coded into the message type. Because this was somewhat restrictive, and because it didn't actually matter to most services who a message was sent to, this was removed. Each message was only identifiable via it's service, sender, tags or message ID. The message ID was assigned during send-off. This caused a problem however. Considering that some services would implement their own, more specific group concepts on top of libqaul, it might happen that the same message payload was sent off multiple times, to different people. But the fact that they were sent to different people was an implementation details the service might now care about! This could lead to data duplication in the backing store, as now every payload was being stored multiple times for different message IDs. To solve this, we are re-adding a more restrictive group concept into libqaul: ID types! When sending a message, a service needs to specify whether the message ID should be unique, or if it should be bound to some constraint. What this means is that for multi-recipient dispatches, a service can set the id_type to group (via the helpful `create_group()` function), at which point the data payload would only be stored in the database ONCE, but sent of normally just the same. However now we ran into some other problems. Ratman (the decentralised router) used the message ID of a service message to label it's frame sequences for re-transmission hashes, and more. Sending the same payload to many recipients, would actually result in different payloads, because all messages going through Ratman are encrypted: the ciphertext would differ. The solution to this was simple: the message ID is now part of the encrypted envelope (which also means that an attacker can't grasp group relationships just by looking at the packet headers), and Ratman generates a new message ID for each frame sequence. While we have no tests for these scenarios yet, it is easy to imagine a scenario in which this would have been a problem (i.e. any group). In the future we will want to add some tests that fail before this commit and don't after this commit. The consumers of libqaul (namely libqaul-rpc, the services, and the low-level binding test clients) have all been updated to the new API.
Showing