Status messages are sent with every presence update by some XMPP
clients, which would previously result in corresponding changes being
made on the WhatsApp side, where no effective change in status has been
made since.
This commit implements naive caching for presence status in order to
avoid most double-sets, but which however will clear across restarts.
Status messages and Broadcasts require special handling on the Slidge
side, especially where read receipts are concerned. However, if not
handled specifically, these will currently default to being handled
as (strange) group-chats, which might be responsible for crashes etc.
This commit has these message types be explicitly unhandled until we
introduce support for handling these properly.
It may happen that a participant who hasn't shared
their "push name" with us is mentioned in a chat by
another participant.
Before this fix, this would result in replacing the mention
with an empty string.
Setting the subject in rooms that don't have one
resulted in an empty subject with a timestamp of
'0001-01-01T00:00:00Z', which in turned raise warnings
in gajim's logs.
This commit changes the behaviour setting a subject
and a subject date only if they are given by WA's
servers.
This commit implements history synchronization/back-fill on first login,
as allowed by WhatsApp. Currently, only history for group-chats/MUCs is
allowed, as 1:1 history synchronization is not operational without core
changes/support/privileges for the user's MAM.
In addition, even though on-demand backfills have been implemented, they
are considered to be inert/of limited use until persistent message
storage is implemented, as the `session.muc_sent_msg_ids` storage
currently utilized is in-memory only, and WhatsApp requires full message
metadata for on-demand history synchronization.
This helps improve quality, and appears to be well-supported by official
WhatsApp clients. In addition, a bug concerning the handling of ALAC
files has been fixed (which would previously not send through correctly,
owing to WhatsApp's lack of handling for these).
Includes a fix for the role of admin and
owner to "moderator", or else gajim wouldn't
display the option to actually moderate a
message.
Implements: https://todo.sr.ht/~nicoco/slidge-whatsapp/21
Previously, we would rely on the client-reported MIME type, unless this
was empty or invalid, in making the determination of whether we
should (or not) convert a given attachment to a better-supported format.
However, client support for MIME type reporting is sporadic,
error-prone, and known-to-be-buggy in some cases (e.g. Conversations
reporting MP4 voice recordings as `audio/mpeg`).
This commit moves to using auto-detected MIME types for attachment
conversions, and adds some additional matching for known edge-cases.
In general, attachments will now have their MIME type, as presented to
WhatsApp, changed *only* if conversion takes place; the only exception
is when an empty or invalid MIME type was self-reported.
This commit introduces a new ad-hoc command, `logout`, which disconnects
from WhatsApp without unlinking our authentication credentials (i.e.
what is generally understood to be meant when saying "log out").
Searching by phone number will check for a contact on WhatsApp, and if
existing, automatically add that contact to the roster. However, contact
names are not resolved until after they've been added to the roster and
been communicated with.
This fixes issues related to breaking changes in latest versions of
GoPy, which will now return concrete instances of corresponding classes
in iterators; previously, only a "pointer" would be returned, which
would've then needed to be set as the handle for a newly created
instance of a relevant class.
Closes: #17
Setting your avatar in XMPP will now propagate to WhatsApp, but not the
other way around; even so, most XMPP clients will update the avatar anew
on new connections, which should help ensure persistent synchronization
even in the face of remote changes to the WhatsApp profile.
Incoming and outgoing attachments (and preview images) will typically be
transported between the Python-Go boundary as raw, in-memory byte
representations; however, this has been the source of issues in the
past, since our Go-Python glue layer does not handle translating byte
slices in a performant enough way.
Thus, we have relied on transporting attachments as URLs, local paths,
and raw byte slices interchangeably, using whichever method has been
more appropriate for the use-case. Similarly, we have typically used
in-memory byte slices and pipes for our media conversion layer between
Go and FFmpeg, in order to avoid spurious writes to disk.
Unfortunately, FFmpeg does not handle conversion of media files using
pipes in all cases, and more specifically, in the case of MP4 container
formats, which usually require the entire buffer to be available and
cannot handle conversions from streamed sources (such as pipes).
This commit consolidates use of local, temporary file paths for the
purposes of both attachment and media conversion handling, which (may)
simplify the implementation, but may also lead to increased latency, as
files need to be read from and written to when crossing Go-Python and
FFmpeg boundaries.
Future improvements to GoPy and our FFmpeg implementation might have us
revisit and revert back to raw byte slices.
WhatsApp allows secondary, "linked" devices to pair with the main device
via either QR code, or more recently, via one-time code. Both methods
are equivalent in their outcomes, but one-time code pairing might be
easier to use for users that use the same device for both WhatsApp and
XMPP, as scanning a QR code temporarily requires a second device (or
printer). Conversely, one-time codes can be received and used by the
same device.
This commit implements this form of one-time code pairing via a new
`pair-phone` command, to be used as a ad-hoc command against the
Slidge component; this form of pairing requires entering the phone
number used by the main device, and returns a small one-time code that
can be used in the "Link Device" dialog on the main device.
This does not, and will not, replace QR code pairing -- both methods
will continue to be available on Slidge so long as they're available
upstream.
nicoco
Alex Palaistras