When OMEMO isn't possible, render it as grey.
This change makes OMEMO for MUCs easier, since there I anticipate that
OMEMO support might change dynamically based on who enters/exits the
room.
updates #1180
We distinguish between UniView and MultiView instances.
UniView means that only one chat is visible, even though there might be multiple ongoing chats.
MultiView means that multiple chats may be visible simultaneously.
This reverts commit 7af73c3471.
Doesn't look like the right approach for adding support for XEP-0156.
Work on that will continue in a branch in the meantime.
Namely:
- Only match messages which start with exactly "/me ".
- Simplify the match, checking a string instead of a complex regex.
- Always remove the first four characters in the case of a match, to not
leave an extra leading space.
So that we first render dynamic content (e.g. images) before inserting
it into the chat.
Also, add the `show_images_inline` setting (which is the cause of this
whole change).
Updated tests to handle this new change and start using async/await
instead of promise callbacks.
Previously we checked only if the last message was a join message from
the same person.
Now instead we check the last n messages that are join or leave
notifications.
`toLocaleString` now returns element attributes in alphabetical order
(for better cross-browser consistency).
Also, `toLocaleString` is now used in favor of `outerHTML` because
browsers aren't consistent with one another in their output.
- Move `getDefaultNickName` to the model and rename to `getDefaultNick`
- Let `checkForReservedNick` return a promise and save `nick` once received
- Updated `openAndEnterChatRoom` to wait appropriately and remove presence-wrapper
- Update tests to wait appropriately
- Remove presence-wrapper in `getRoomFeatures`
When receiving a PreKeySignalMessage, then a prekey has been chosen and
should now be removed from the list of available prekeys in the bundle,
so that a different device doesn't choose it as well.
AFAICT, libsignal removes the prekey, so it's then up to us to
regenerate it and republish our bundle.
updates #497
Before these changes, prekeys were stored in two places, one place that
converse-omemo accessed and one that libsignal accessed and when
libsignal deleted a prekey the other store wasn't updated.
Now we let the methods called by libsignal store/remove prekeys (and the
signed_prekey) in the same place as used by the code in converse-omemo.
Instead of setting `active` to `false`, we remove the device entirely
(unless its the current device).
Doing it this way means more fetching of bundles for devices that
disappear and then reappear from a user's devicelist.
However, there might be caching invalidation concerns with just reusing
a cached bundle for a device id that disappeared and then reappears.
Additionally this change simplifies the showing of a contact's device
fingerprints in the modal, since we don't have to take active/inactive
into consideration.
updates #497
The `_converse.session` store gets cleared after logout, but we want the
`trusted` flag to persist after logout.
Also update the documentation no that the `storage` config option has
been removed in favor of `trusted`.
So that it persists across page loads. Otherwise storage falls back to
the default, causing records to be in both local- and sessionStorage.
Additionally, update singleton models to have the 'id' available as a getter.
Otherwise multiple records gets stored in browserStorage, causing random
results being returned.
under non-OMEMO circumstances. Otherwise, when messages are fetched in
bulk via MAM, then a message referring to a previous one (e.g.
a correction) may be processed before the message being referred to has
been created.
