1. 30 May, 2020 3 commits
  2. 29 May, 2020 19 commits
  3. 28 May, 2020 10 commits
  4. 27 May, 2020 6 commits
    • Katharina Fey's avatar
    • Katharina Fey's avatar
      libqaul/messages: adding sender type id concept · 3b0b41e3
      Katharina Fey authored
      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.
    • Katharina Fey's avatar
      alexandria: adding some path probing utilities · 8abb6d14
      Katharina Fey authored
      Very often a simple check whether a path exists or not is sufficient.
      The query iterator additionally needed a way to be debug printed for
      debugging purposes.
    • Katharina Fey's avatar
      service/chat: fixing an issue where local room list was empty · d9fe1528
      Katharina Fey authored
      The problem was that the room list was populated only by the unread
      messages that were divided onto the existing rooms.  A room that had
      no unread messages was being dropped.  Ultimately this meant that
      after creating a room it would be invisible until there was a response
      from the peer that marked it as unread.
      This implementation sorts the unread messages into a quickly parsable
      map first, then iterates all rooms and simply augments the metadata
      where appropriate.
    • Katharina Fey's avatar
      clients/android: adding assets symlink · 9284ae98
      Katharina Fey authored
    • Katharina Fey's avatar
      tests: updating test setup · f6299ba9
      Katharina Fey authored
  5. 26 May, 2020 2 commits