Mercurial > libervia-backend
view doc/libervia-cli/pubsub_secret.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 | 4b8776eb6826 |
| children |
line wrap: on
line source
.. _libervia-cli_pubsub_secret: =================================================== pubsub/secret: share, revoke or rotate node secrets =================================================== ``secret`` group commands to handle pubsub e2ee shared secrets. You can check :ref:`pubsub-encryption` to have overview on how it works. share ===== Share node secrets with an entity. This make the encrypted pubsub node fully accessible to the recipient. By default, all node secrets are shared with the recipients, this is normally the desired behaviour as you most of time want the recipient to have full access to the node. However, it may be possible to share only some keys by using ``-k ID, --key ID`` argument. example ------- Louise want to give access to her private blog to pierre:: $ li pubsub share secret -n private_blog pierre@example.net revoke ====== Mark a shared secret as revoked, which means that no new items must be create using this secret. The secret is still available to decrypt older items. By default, the revocation notification is sent to all people known to have the latest shared secret, this is the recommended way to use this command. However, you may send the revocation notification only to some entities by using ``-r JID, --recipient JID`` as many times as necessary. It is usually better to use the rotate command below, which automatically revoke all existing keys and create a new one, sending suitable notifications. example ------- Louise wants to revoke a shared secret used in her private blog:: $ li pubsub secret revoke -n private_blog k4XBRW9rkYQeGN5fiqoK4R rotate ====== Revoke all shared secrets of a node, and create a new one. Suitable revocation and secret sharing notifications are sent. By default, notifications are sent to all people known to have the latest shared secret. This is generally what is desirable, unless one or more people who previously had access to should now be excluded from access to the new items. In this case, you may use the ``-r JID, --recipient JID`` argument as many times as necessary to specify who should receive the notifications and new secret. example ------- Louise wants to rotate shared secrets of her private blog:: $ li pubsub secret rotate -n private_blog list ==== List all known shared secrets of a node. By default, the private key is not returned, to prevent it from being accidentally displayed on the screen. If you want to see them too, increase the verbosity with the ``--verbose, -v`` argument. example ------- Louise wants to see all secrets used in her private blog:: $ li pubsub secret list -n private_blog