Using 2 hex characters [0-9a-f] will give us 16 * 16 = 256 root folders which
seems more manageable than 4096 (16^3). Assuming a user has 10,000 attachments,
they should roughly distribute at ~40 per folder with prefix length 2 rather
than ~2.5 per folder with a prefix of 3.
Using hashes, we get the benefit of deduplication but if a user receives two
messages with the same attachment, deleting one would delete it for both since
they are only stored once. To avoid the complexity of tracking number of
references, we simply generate random file names similar to iMessage on MacOS
(?) and Signal Android.
Some of our users submit direct PRs against our translations. This update to our PR template is meant to encourage them to contribute translations via Transifex.
Prompted by this user PR: https://github.com/signalapp/Signal-Desktop/pull/2156
Fixed: White block at bottom of conversation panel in iOS theme
(#2144 and #2153)
Fixed: Would attempt to rotate signed prekey every five seconds,
forever, after app discovers it is unlinked
(1c6d91b59c)
Dev:
- Introduce IndexedDB index on `messages` store tracking
`schemaVersion` (#2128)
- Preparation for encrypted backups
(cea42bde7d)
- Updates to structure of exported data - messages.zip, flat list of
attachments (6d8f4b7b6e)
Backup creates, in a target directory:
- An attachments folder, with all attachments, each named for their
parent message's id - a GUID. If there is more than one attachment
in a given message, each attachment beyond the first will end with
'-N', zero-indexed.
- A file named messages.zip. It contains exactly what went to disk in
the original export code, but zipped up.
Export is now only 'light,' and in this new messages.zip format.
Import supports both the new format and the old format. If the target
directory has a messages.zip file, we'll treat it as the new format.
Next up: Encrypting attachments and the messages.zip!
Daniel Gasienica
Navdeep Singh
Vincent
Scott Nonnenberg