- 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.)
