We previously processed attachments in `handleDataMessage` which is mostly a synchronous
function, except for the saving of the model. Moving the processing into the already async
`onMessageReceived` improves code clarity.
Instead of keeping track of last normalization (processing) date, we now keep track of
an internal processing version that will help us understand what kind of processing has
already been completed for a given attachment. This will let us retroactively upgrade
existing attachments.
As we add more processing steps, we can build a processing pipeline that can convert any
attachment processing version into a higher one, e.g. 4 -> 5 -> 6 -> 7.
This module exposes `loadImage` with a `Promise` based interface and pre-
populates `orientation: true` option to auto-orient input. Returns data URL
as string.
The module uses a named export as refactoring references of modules with
`default` (`module.exports`) export references can be error-prone.
See: https://basarat.gitbooks.io/typescript/docs/tips/defaultIsBad.html
Synchronizes our protocol buffers with `libsignal-service-java` project.
**Changes**
- [x] **BREAKING:** Rename `package` from `textsecure` to `signalservice`.
⚠️~~Workaround: Rename back to `textsecure`.~~
Changed all protobuf `package` names across our project.
- [x] Rename `java_` metadata.
- [x] Move `NullMessage`, `ReceiptMessage`, and `Verified`.
- [x] Rename `Contacts.isComplete` to `Contacts.complete`. Confirmed to be
unreferenced in our project.
- [x] Rename `Settings` to `Configuration` (`textsecure.protobuf.Settings` seems
to be unused)
- [x] Rename `libtextsecure` `MessageReceiver` `settings` event to
`configuration`.
- [x] Rename `ReceiptMessage.timestamps` to `ReceiptMessage.timestamp`.
- [x] Add `AttachmentPointer` `width` and `height`.
- [x] Renamed `IncomingPushMessageSignal.proto` to `SignalService.proto` to
match server.
---
commit 2b6aa19bf9
Author: Daniel Gasienica <daniel@gasienica.ch>
Date: Wed Feb 14 19:41:24 2018 -0500
Rename protobuf `package`: `textsecure` --> `signalservice`
Brings us closer to `libsignal-service-java`.
commit 91612880a5
Author: Daniel Gasienica <daniel@gasienica.ch>
Date: Wed Feb 14 19:19:35 2018 -0500
Rename `SyncMessage.Settings` to `SyncMessage.Configuration`
commit 848eb95599
Author: Daniel Gasienica <daniel@gasienica.ch>
Date: Tue Feb 13 20:16:43 2018 -0500
Rename `ReadReceipt` `timestamps` --> `timestamp`
commit 39859e64b4
Author: Daniel Gasienica <daniel@gasienica.ch>
Date: Wed Feb 14 18:43:42 2018 -0500
Rename `IncomingPushMessageSignal.proto` to `SignalService.proto`
This matches the `libsignal-service-java` filename.
commit fd4bfd76af
Author: Daniel Gasienica <daniel@gasienica.ch>
Date: Tue Feb 13 16:24:36 2018 -0500
Revert protobuf `package` to `textsecure`
This was a breaking change and would need to be introduced with additional
changes.
commit 9f618fa917
Author: Daniel Gasienica <daniel@gasienica.ch>
Date: Tue Feb 13 16:09:55 2018 -0500
Sync service protocol buffers with Java project
Snapshot: 4684a49b2e/protobuf/SignalService.proto
* Log SyncMessage destination, even if it's a group
* Remove disappearing message even if deleted during fetch
This change fixes a potential race condition with disappearing message
removal from the UI. If the UI is in the middle of making a database
request for messages to display, then we need to wait for that to
complete before removing the newly-deleted expired message.
This commit adds a badge to the tray icon that displays the number of
unread messages, if there is any. It is implemented by providing
alternative versions of the icon, that replace the default image when a
message is received.
The badge is rendered graphically as a red circle containing the number
of unread messages. Since a different icon file is needed for each
possible number of unread messages, but this number is clearly
unbounded, only the numbers from 1 to 9 are provided. If there are 10 or
more unread messages, a single badge (depicted as "9+") is used.
Resolves#1917
* api.js: HttpError now preserves more of original error info
* Allow invalid conversation to be added to ConversationController
If a number we don't believe is valid comes in as part of a group, we
fall apart. We event prevent display of that conversation. Because we
have 'isValid()' protections in place for the places we create contacts
from user input in desktop (the search bar), we can temporarily add an
invalid contact to our collection (not saving it to the database) to
unblock this group scenario.
Still investigating what kind of phone number is valid in a mobile app
but not valid for us.
* Finish the debuggable error support
* Fix logging in the case of an invalid number
