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

.. _libervia-cli_pubsub_node_subscriptions:

========================================================
pubsub/node/affiliations: nodes subscriptions management
========================================================

``subscriptions`` is a subcommand handling the subscription to a node.

Those commands can only be used by an owner of the node.

get
===

Retrieve subscriptions to a node.

If ``--public`` is used, only public subscriptions are retrieved (if target service
supports `XEP-0465 Public Pubsub Subscriptions`). Public subscriptions are accessible to
anybody, thus you can use this on a node even if you are not an owner of it (and thus
would not normally be allowed to retrieve subscriptions).

.. _XEP-0465 Public Pubsub Subscriptions: https://xmpp.org/extensions/inbox/pubsub-public-subscriptions.html

example
-------

Get subscription from ``some_node``::

  $ li pubsub node subscriptions get -n some_node

Retrieve public subscribers to the blog of Louise::

  $ li pubsub node subscriptions get --public -s louise@example.org -n urn:xmpp:microblog:0

set
===

Set subscriptions to a node. Subscriptions are specified with ``-S JID [SUSBSCRIPTION]
[JID [SUSBSCRIPTION] ...], --subscription JID [SUSBSCRIPTION] [JID [SUSBSCRIPTION] ...]``
where ``JID`` is the jid of the entity to change subscription state, and ``SUBSCRIPTION``
is a subscription state (on of ``subscribed``, ``pending``, ``none``) as specified in
`XEP-0060 Subscription State`_. If ``SUBSCRIPTION`` is not specified, it default to
``subscribed``.

.. _XEP-0060 Subscription State: https://xmpp.org/extensions/xep-0060.html#substates

example
-------

Subscribe Louise with her new address at ``louise@example.org`` and remove her
subscription from old ``louise@example.com``::

  $ li pubsub node subscriptions set -n some_node -S louise@example.org subscribed louise@example.com none