This is largely a leftover from the Backbone.View days and makes less
sense now that the UI is componentized.
Ideally we don't want to call commands on the "views themselves, instead
we should be working on the the models and let the "views" update
themselves automatically.
Also, given that the `jid` attribute on the chat views might change,
especially when rendered declaratively in other frameworks like React,
a view might not be available at times where we previously might have
expected it to be (since it's been repurposed for a different JID).
This wrongly stored value wasn't inlcuded in the published the bundle
because the libsignal store was used, which had the right value for the public key.
Instead, this value was used locally by being passed to the libsignal
session builder to verify signed prekey.
Project summary, including supported XEPs in a machine-readable format,
for automated listings, aggregation of XEP implementation status and
other nice things.
See https://xmpp.org/extensions/xep-0453.html
This list was simply scraped from the README and mangled into XML using
`csv2 | sed | 2xml` and amended with a few other details from e.g.
package.json and links on the website.
The eventual goal is to avoid UI-related stanza processing if the relevant chats
aren't in the DOM.
With the current architecture, chatboxes are created (and the stanzas
related to them processed) even if `#conversejs` isn't in the DOM.
* Initial work on making controlbox an element
* Create a shared base class
* Ceate ChatBoxViews proxy
* Update sass now that certain classes are moved to converse-chats element
- Add test for incoming RAI message
- Only enable RAI if the user is affilated in MUC being left
- Handle error presence indicating a resouce-constraint
- Don't unregister stanza handlers in `leave`, since we still want to
listen to RAI-related stanzas. Instead unregister upon the `destroy`
event.
to determine valid characters to form a boundary before an `@` mention
Also fixed an issue with mentions looking like they're part of URLs, by
first processing mentions separately.
Fixes#1083
Directives are rendered as templates and their bodies are MessageText instances.
We thereby achieve the necessary nesting of directives (and other rich
elements inside directives) by letting each directive
body render itself similarly to how the whole message body is rendered.
