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
GoPy 0.4.8 and beyond introduce breaking changes related types returned
in function calls (e.g. slice element types). Previously, these would be
a pointer handle which would then need to be set into a concrete
instance of the type required by callers; GoPy will now return concrete
instances itself.
Moving to the new semantics requires changes to code, and additional
testing; pinning the version helps us migrate on our own timeline.
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.
Previous iterations of the presence sync timer would `nil` out timers
when our presence isn't set to "available" when they fire, so that we
can pick up after them once we go to that status once again. However,
this was subtly broken as we were reading from the timer in between
those events, which led to (non-fatal) nil dereference errors.
WhatsApp will refuse to have clients show large preview image sizes, and
seems to block the WebSocket connection for an inordinate (infinite?)
amount of time thereafter, leading to essentially a gateway freeze.
This also corrects size limits for other media, which were 1024 times
larger than they should've been.
It seems that WhatsApp requires that we periodically re-refresh contact
presences, even after having our own presence be reflected correctly in
the remote server. This commit re-instates the background sync process
and has contact presences be refreshed every 12±6 hours, but only if
we're currently available.
This commit removes period background synchronization for own presence,
and insteads synchronizes XMPP client presence with WhatsApp directly;
this in turn allows our state on WhatsApp to be more indicative of what
the actual use state is (assuming no use of official WhatsApp clients).
Synchronization of user status messages is also enabled, but only if
these are set to a non-empty value -- reverting to an empty status
message requires intervention via an official WhatsApp client.
Alex Palaistras
nicoco