plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation: Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@, Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to work on another version and provided me with this link: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my implementation. This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167 plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it normally does. This is because WebRTC has several implementations (browser for web interface, GStreamer for others), and file/data must be handled directly by the frontend. This is particularly important for web frontends, as the file is not sent from the backend but from the end-user's browser device. Among the changes, there are: - XEP-0343 implementation. - `file_send` bridge method now use serialised dict as output. - New `BaseTransportHandler.is_usable` method which get content data and returns a boolean (default to `True`) to tell if this transport can actually be used in this context (when we are initiator). Used in webRTC case to see if call data are available. - Support of `application` media type, and everything necessary to handle data channels. - Better confirmation message, with file name, size and description when available. - When file is accepted in preflight, it is specified in following `action_new` signal for actual file transfer. This way, frontend can avoid the display or 2 confirmation messages. - XEP-0166: when not specified, default `content` name is now its index number instead of a UUID. This follows the behaviour of browsers. - XEP-0353: better handling of events such as call taken by another device. - various other updates. rel 441

===============================
avatar: retrieve/upload avatars
===============================

Avatars are images associated to an XMPP entity. Several XMPP extensions are in use, Libervia
tries to hide the technical details so avatar are as easy as possible to manipulate for
end-user.

get
===

Retrieve the avatar of the given entity. Entity jid is specified as positional argument.

If an avatar is found, a path to its cached file is printed. Please note that this is the
cache used by all Libervia ecosystem, **do not modify the cached image**. You may use it for
read-only access, or copy it if you want to modify the image.

You may use the ``-s, --show`` argument to display the found avatar. The software used to
display the image can be specified in Libervia configuration (cf. :ref:`configuration`), in the
``[li]`` section: the ``image_cmd`` setting let you specify the path to the software. If
``image_cmd`` is not used, ``li`` will try some common software, and if none is found, it
will try to open the image in a browser (which may sometimes result in using the default
image software of the platform).

When available, cached avatar is returned by defaut. If you want to ignore the cache, use
the ``--no-cache`` option (of course this can result in more network requests).

example
-------

Get the avatar of ``louise@example.org`` and display it::

  $ li avatar get --show louise@example.org


set
===

Upload and set the given avatar for the profile. The only required argument is the path to
the image to use as avatar.

example
-------

Set the avatar of the default profile::

  $ li avatar set ~/photos/some_photo.jpg