Incoming contact messages, with are represented as their own message
type in WhatsApp, are now handled as bog-standard attachments of the
equivalent contact vCard, which is helpfully provided by WhatsApp
itself.
Failure to convert media is intended to be non-fatal, as original media
may still be usefully displayed to remote contacts; this commit fixes
an oversight in returning the original attachment in failures to convert
media.
This is reduced from 24 hours, and is intended as an experimental fix
for issues seen where contact presences will stop updating after an
approximate 24 hours.
WhatsApp clients are set to accept only a specific set of media files as
image, audio, or video messages, specifically:
- Images must be in JPEG (non-progressive) format.
- Audio messages must be in Opus-encoded Ogg if sent as voice messages,
otherwise may be in MP3 or AAC format if not (though client support
may vary).
- Video messages must be in h264-encoded MP4, with some additional
constraints on color format and profile used.
Several edge-cases exist, e.g. with GIF files needing to be re-encoded
as MP4 in order to be animated (and requiring extra metadata in messages
to be called out as such).
This commit implements a somewhat comprehensive media conversion scheme,
built upon FFmpeg for audio and video, and native Go facilities for
images, based on the source format. Specifically:
- Audio files in `audio/mp4` or `audio/aac` format (corresponding to
formats commonly used in Android and iOS XMPP clients, respectively)
are automatically re-encoded as Opus-encoded voice messages.
- Audio files in `audio/mpeg` (i.e. MP3 files) or `audio/ogg` format
are sent as plain audio files in their own format, with varying client
support assumed.
- Images in `image/png` or `image/webp` format are automatically
re-encoded as JPEG image messages. Conversely, images in `image/gif`
format are re-encoded as MP4 video messages with auto-play enabled.
- Videos in `video/webm` or `video/mp4` format are automatically
re-encoded as MP4 video messages (the latter is re-encoded to ensure
option compatibility).
As stated above, all audio and video conversions require FFmpeg and
FFprobe to be installed, and, if missing, will leave attachments
unchanged (which may result these being sent as binary files). Image
conversions do not rely on any external functionality, however.
Current limits are: 10MiB for images and 20MiB for audio and video
files; above these conversions will fail and original files will be sent
instead.
Future commits may see compatibility improved, or semantics corrected
where these do not match expectations on the WhatsApp side.
Our presence is always initially set to "available" when connecting to
WhatsApp, but can also be set manually by users via the `presence`
ad-hoc command. Irrespective of its value, however, it seems that we're
required to periodically re-send our presence to WhatsApp, as it
otherwise will consider our session inactive and will stop sending
presence information for contacts, among other things.
This commit implements a background refresh task that operates on a
rolling interval of 24±12 hours, each iteration happening somewhere in
that range. It is intended that this interval is low enough to fulfil
requirements set by remote WhatsApp servers, while being high enough to
avoid inundating with requests; future commits may amend this value.
Recent WhatsApp versions have begun allowing for message
correction/editing support; this commit integrates this official support
into pre-existing support for XEP-0308 (Message Correction) in Slidge.
Both incoming and outgoing message corrections are supported. However,
there are currently known issues with corrections made on own messages
in the official WhatsApp client, which are not reflected in XMPP
clients; these will be corrected in future commits.
nicoco
Alex Palaistras