- The "New or updated group chat" message is very spammy, and not even that
useful for being notified about a new chat you might have missed out on. We
no longer send that, but we do send something when you get a message for an
unknown groupchat.
- Presence subscription requests are now only sent if you have a chat open with
someone, because I got tired of receiving randomers' presence subscription
requests...
- Presence is now only ever sent in response to a presence probe, or when a user
updates their status or profile picture. You won't get presence from all
whatsapp contacts when the bridge connects any more.
- Getting hit with a massive backtrace is slightly overwhelming. It also is a
potential privacy issue, seeing as phone numbers (etc.) might be printed as
part of the call stack...
- Sometimes, the bridge can get wedged in a state where doing DB operations
returns SQLITE_MISUSE errors.
- I don't really know what causes this, but I'm hoping unconditionally resetting
the statements before they get used will ameliorate the problem?
- Additionally, the reset statements now aren't wrapped in an IGNORE-ERRORS,
meaning we might get error tracebacks that point to the actual problem now.
- This commit contains initial support for uploading and sending images natively
-- i.e. a WhatsApp image upload, instead of sending through a bare link.
- All images supported by the OPTICL library are supported; this is because WA
needs us to generate a jpeg thumbnail for the image (which can probably be
made smaller)
- Importantly, this functionality is currently a trivial DoS vector: simply send
a large file (or an infinite file, like time.gif) and it ALL gets downloaded
and buffered into RAM...!
- At least this is limited to users who have actually registered with the
bridge.
- Failing to send the image in any way results in an XMPP error getting reported
back to the sender.
- Also, the initial registration QR code upload thing now happens in another
thread.
- I don't think sending the user a crapton of presence when they send us some is
actually a good thing (and it's not doing any favours for my mobile data plan)
- Instead, let's let the user's server send us presence probes and reply to
those (?)
- The new PUT-WHATSAPP-MEDIA-FILE can encrypt and upload a blob of file data to
WhatsApp, and returns everything we'd need to make a protobuf message out of
that.
- However, important functionality is still absent: whatscl needs to gain some
support for sending protobuf messages for file uploads, and we'd also need to
integrate with some image/video libraries in order to do related processing
tasks.
- For example, uploading an image requires producing a JPEG thumbnail for it,
as well as figuring out its size.
- Uploading audio would require conversion to Opus.
- Maybe we could attempt to integrate with ffmpeg or something? This is likely
to get tricky.
- 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.)
- The "by" attribute of the <stanza-id/> element wasn't being set correctly (it
was just set to the localpart instead of the full JID, which is out of spec).
- This meant that Conversations (at least) wouldn't trust it, and would try to
use the origin-id instead, which couldn't be looked up when a chat marker was
sent to the bridge.
- This fixes that.
- (and adds another space to the put-url debug info)
- So the entity caps stuff didn't actually work, because we don't implement
XEP-0030 properly and don't honour the "node" attribute on the query.
- To hack around this, we misimplement XEP-0030 some more, and always return the
bridged user disco info list, even if they ask for the bare JID instead of the
full JID. That way, the caps stuff works as it should.
- The bridge should now support XEP-0115 Entity Capabilities, which actually
brings us into compliance with XEP-0085 Chat State Notifications (there were
clients, like Miranda NG, that wouldn't send to us without us actually doing
this XEP and advertising support in disco#info).
- We now handle the :disconnect message from whatscl, which lets us properly
deal with the connection being removed from the app or replaced with another
session. (Before, this would drop the connection, it'd loop and retry, and
then hit a status code error on login; this way is slightly cleaner and also
prevents the bridge getting into a war with another bridge.)
- The :ws-open whatscl event never existed. The bridge was doing just fine
not executing its handler, so it's just been removed. Future work might
improve the amount of spam sent to the user about the bridge state.
- We can now differentiate fatal login errors from other types of errors. For
non-fatal errors, we just send an informational warning message.
(Login errors kill the connection as before.)
- The child nodes of a given node can include both text nodes and
actual XML element nodes. Trying to pass a text node to something
like DOM:TAG-NAME signals an error condition.
- To avoid this, use DOM:ELEMENT-P and the CHILD-ELEMENTS helper
function to filter lists of nodes down to elements where elements
are expected.
- The user_contacts table contained an incorrect UNIQUE constraint
on wa_jid that meant only one user of the bridge could have any
given whatsapp user in their contacts.
- This is fixed in fixup_1.sql, which should be applied over schema.sql.
- Using tazjin's buildLisp.nix (you need the TVL Monorepo installed
as <depot>), we have a derivation for whatsxmpp and its million
dependencies.
- The derivation currently just assumes whatscl is in ../whatscl,
but we'll fix that eventually.
- Also there are tons of buildLisp derivations in here, and even
two instances where we had to vendor stuff in order to get it to
work with nix (usually because it had some data file).
- But yay, we can build via docker and it's not utter trash!
