view doc/libervia-cli/message.rst @ 4231:e11b13418ba6

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
author Goffi <goffi@goffi.org>
date Sat, 06 Apr 2024 12:57:23 +0200
parents d6837db456fd
children 073bb1d1a7f8
line wrap: on
line source

.. highlight:: sh

================================
message: chat message management
================================

Message commands let you send chat messages or manage your server message archives.

.. _libervia-cli_message_send:

send
====

Send a message to a contact or a chat room.
``stdin`` is used as message source.
You can encrypt your message using ``--encrypt [ALGORITHM]`` argument, this will create an encrypted session and replace existing one if needed.
You can manage your encrypted session using ``encryption`` command.

examples
--------

Send a message to a contact::

  $ echo 'Salut à Toi!' | li message send louise@example.net

Send a message encrypted with OMEMO::

  $ echo 'pssst, this message is encrypted' | li message send -e omemo louise@example.net

.. note::

  Fingerprints of your destinee must have been accepted before using OMEMO, else message can't be encrypted

Send a ``normal`` message marked as French with a subject::

  $ echo 'Bonjour, je vous écris avec « Libervia »' | li message send -l fr -t normal -S 'Ceci est un message de test'

retract
=======

Retract a message, i.e. mark it as retracted in database, and send a retraction request to
original recipient.

When a message is marked as retracted in database, it won't appear anymore or a hint
(commonly called *tombstone*) will be displayed instead (the behaviour depend of the
frontend that you're using). However, there is an option to archive retracted messages:
``Privacy``/``retract_history``. This option is disabled by default, but if you set it
(e.g. with ``li param set``), the original message will be kept in metadata and may be
displayed if the frontend that you're using allows it.

The ``message_id`` positional argument is the internal ID of the message (not an XMPP ID).
It may be displayed by some frontends.

.. note::

   It is not possible to be sure that a message will be retracted: once something is sent
   through the network, any recipient can keep it, copy it, share it, etc. This is true for
   Libervia/XMPP as for any software, decentralized or not.

   Retract send a retractation **request**, i.e. it asks to the recipient(s) client(s) to
   hide or delete the message, but it's not possible to have a guarantee that nobody kept
   a request.

   The message is also removed from database, except if the option
   ``Privacy``/``retract_history`` is set (see above).

example
-------

Retract message with ID ``1234-5678-9abc-def0``::

  $ li message retract 1234-5678-9abc-def0

mam
===

Query archives using MAM.

This command allows you to check message archive kept on the server (i.e. not the local copy).
You usually want to specify a starting point, and a number of message to retrieve. If too many messages
are available, you'll have to use RSM commands to navigate through the results.

examples
--------

Retrieve messages from last 2 days::

  $ li message mam -S "2 days ago"

Retrieve messages from last 5 hours on Libervia official chat room::

  $ li message mam -S "5 hours ago" -s libervia@chat.jabberfr.org

Retrieve 2 first messages of 2019 on Libervia official chat room::

  $ li message mam -S 2019-01-01 -s libervia@chat.jabberfr.org -m 2