- WARNING to operators: You MUST run fixup_2.sql in order to use this and newer
versions of the bridge.
- Archiving and full chat history fetches are now a configuration setting (and
default to off).
- Users now have to enable archiving manually by talking to the admin user, and
are warned about the potential privacy implications.
- Users can now completely remove themselves from the bridge, deleting all data.
- Bridge administrators can now be specified by adding an entry to the
'administrators' SQL table with your JID. These can force-unregister specific
users.
- Groupchats now support XEP-0313 Message Archive Management (MAM)!
- This uses the history stored in the sqlite database, as implemented in the
previous commits.
- The QUERY-ARCHIVE megafunction builds up a SQL query to get stuff out of the
database, in accordance with provided MAM + RSM parameters.
- Notably, various hacks are in here that need to be fixed.
- IQ 'set's are now processed, which means we needed to add a stub impl of
Schrödinger's Chat so people don't drop out of MUCs all of a sudden.
(Well, it just responds to every ping indiscriminately...)
- Oh also the new presence subscription stuff from earlier is borked.
- WARNING: This change is hilariously unsuitable for public instances. Don't run
this code in such an environment yet!
- Groupchat messages are now stored in the sqlite3 database, with the intent
to allow retrieval via MAM at a later date.
FIXME: You can't opt out of this though, which is a huge GDPR hole.
- You can also request ALL of your group chat history from whatsapp be fetched
and stored in the database (!!). This is a VERY resource-intensive operation,
as it involves spawning a metric crapton of threads, uploading a metric
crapton of historical media to the configured upload server, and writing a
metric crapton of messages into the database.
- At some point, the ability to invoke this will be severely limited to only
approved users. That point has not yet come, though.
- Additionally, the chat history request will abort if the connection it's
associated with dies. (You can just retry it, though.)
- Instead of taking a WhatsApp message and sending an XMPP one directly, we now
generate an XMPP-MESSAGE object, and have functions to deliver said object
and make said object from a WhatsApp message.
- This paves the way to storing said XMPP-MESSAGEs in a database, so we can
actually do message history / MAM. Yay!
- We now handle the :chat-modified event from whatscl, and re-fetch group
metadata when we receive it.
- Of course, this doesn't actually help for resources which are in the MUC at
update time; they'll need to reconnect until we have code to handle message
stubs properly.
- Chat metadata reception now generates a message to the user, both for ease of
debugging, and also to let them know that something happened to a groupchat
they're in which they would otherwise not be aware of at all. (A handy link is
also provided, if you missed the invite and want to join a MUC you're not in.)
- The new `refresh-chats` admin command forces a refresh of all group metadata
in one big go. (Also, the help text now displays the current version.)
