- No need to create a new storage mechanism, just use `persistent`.
- Store SCRAM keys per JID
- Upon succesfull login, store the current session JID, so that we know who to fetch SCRAM keys for
- Only store SCRAM keys when the device is trusted
Fixes#3001
since they can see real JIDs, even if the room is semi-anonymous.
Also made changes regarding programming style and conventions:
- Pass in `this` to the template
Recently I've started simplifying the `render` method by just
passing `this` into the template and letting the template calculate
what it needs from that.
- Don't use `bind()`
It's slow and arrow functions can be used instead.
- Don't use an i18n string inside a tagged template literal
Due to limitations with `xgettext` which cannot parse properly
inside tagged template literals
- Use snake-case for variables
If set to a positive integer, the chat history will be kept to that size
by removing older messages.
This happens as new messages come in (as long as the chat isn't scrolled up)
and when the user scrolls down.
Also add the `pruning_behavior` setting
- Use the bare JID as indexedDB dataStore
- Collapse localStorage and indexedDB stores into one `persistent` store.
- When testing, only clear test data
- Split between `login` auth and the rest (`external`, `anonymous`, `prebind`)
- It doesn't make sense to pass along credentials when not using `login` auth so avoid that flow.
- It's not necessary to pass the `reconnecting` flag to `attemptNonPreboundSession`
- New plugin `converse-smacks`
- New config option `enable_smacks`
- Rename session cache id from `converse.bosh-session` to `converse.session`
- Refactor logout and login as consistently used api methods
- Refactor session cache to store per JID
Fixes#316
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.
Include entity capabilities hash in outgoing presences
Also, started some work on using jsdoc for rendering API documentation.
Ideally that would go into a separate commit but that would take ages to
untangle.
