View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011289 | GNUnet | messenger service | public | 2026-03-24 13:36 | 2026-03-24 13:47 |
| Reporter | thejackimonster | Assigned To | thejackimonster | ||
| Priority | high | Severity | feature | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 1.0.0 | ||||
| Summary | 0011289: Offline message delivery in messenger service | ||||
| Description | In current state messages will only be delivered from peer to peer inside the same chat room if both peers are online and connected to each other (via direct CADET connection or indirect connection with other online peers in between). That is a huge issue for availability to implement a proper text messaging service (as most users are used to). Especially private chat rooms between only two people or small groups should expect to have unreliable connections, potentially never achieving a direct connection of all peers being online. So how would they still operate? - Offline message delivery. In GNUnet this would need to be implemented via a decentralized and redundant storage (likely the DHT) for encrypted messages that can be retrieved by members of a chat room specifically but their content (and most of its metadata) can not be accessed by third parties to guarantee the same security properties as expected. So ideally a user would require the room's shared key (`K`) which only members know and a hash from a previous message (`H`) in that given room. With that the user would be able to receive all messages sent by other members from that storage (DHT) and decrypt them, processing these messages as if the user had received them via a direct connection to a peer from that room. Implementing this with the DHT service would require an address (`A`) for an entry and a secret ('S') to encrypt the content of that entry. The idea is that each member of the chat room can derive `A` from `K` and `H` and they can derive `S` from `K` and `H` but for all `A` and `S` applies `A is not equal to S`. Also `A` can't be derived from `S` and `S` can't be derived from `A`. The goal is that `K` can not be derived from `A` as well (so a one-way function should be used to derive `A` from `K` and `H`). Like this there wouldn't be one central point of access to analyze message traffic of a specific chat room. Neither can be searched for a chat room with specific message traffic. Also the content of messages keeps being private. | ||||
| Additional Information | It is to note that timestamps of entries can still be analyzed to match or filter certain entries. This may reveal metadata to third parties. Because of that it is recommended to give entries a timestamp to expire. So peers will remove them eventually. This duration should be long enough for practical offline delivery but as short as possible (likely about 24 hours). To reveal less metadata message content should be padded and publication of such entries should be delayed with pseudo-random offset to the actual timestamp of its messages. That way less information about the original message can be guessed correctly to potentially break the encryption. Additionally one entry may contain multiple messages and peer's have the task to append missing messages to such entries for others to receive. This is related to the directed message graph in the messenger service which allows multiple messages pointing towards the same previous message via its hash. Each message in such an entry is required to have `H` as its previous hash or it will be dropped by a peer (during update process of that entry and during access). In case decryption of messages from an entry fails using `S`, these messages will be dropped as well and the entry will be ignored. Since `S` is potentially being used for multiple entries, there should be a random nonce for each individual entry (or entry update). | ||||
| Tags | No tags attached. | ||||
|
|
I should also add that it would be highly inefficient to search for records in the DHT, calculating `A` (and `S`) for each and every known message inside a chat room. So to improve that a peer could keep a list of hashes in memory from all the latest messages confirmed by other members in that room to have received. Because these messages would most likely be the ones being used for the hashes in new messages by them pointing towards as previous message. Additionally for large chat rooms instead of going through all of these hashes, checking for potential entries, the service could only select a subset with logarithmic amount of the original list (potentially a different subset for every peer to rely on). That way the amount of processing is reduced but statistically each peer would still help merging the overall message graph over time. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-03-24 13:36 | thejackimonster | New Issue | |
| 2026-03-24 13:36 | thejackimonster | Status | new => assigned |
| 2026-03-24 13:36 | thejackimonster | Assigned To | => thejackimonster |
| 2026-03-24 13:47 | thejackimonster | Note Added: 0028245 |
