Mercurial > libervia-backend
view doc/libervia-cli/blocking.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 | 29380ef68dbe |
children |
line wrap: on
line source
.. _libervia-cli_blocking: =========================== blocking: entities blocking =========================== ``blocking`` are commands to block or unblock users by their JIDs (as specified by `XEP-0191`_). You server must implement this XEP to use those commands. A blocking is usually done using bare JID, however, you may specify a resource if you want to block only this resource, or a domain if you want to block a whole domain. Please check `XEP-0191 § JID Matching`_ for details. list ==== List already blocked users. examples -------- Check who has already been blocked:: $ li blocking list block ===== Block one or more entities by specifying their JIDs. You just need to specify the bare JIDs of users that you want to block as positional argument, specify only a domain if you want to block a whole domain. examples -------- Louise wants to block ``spammer@example.com`` and the whole domain ``spammers.example``:: $ li blocking block spammer@example.com spammers.example unblock ======= ``unblock`` works the same way as ``block``. If you want to unblock all blocked users at once, you can use the ``all`` keyword. In this case, you'll have to confirm the action. If you don't want to confirm manually, you can use the ``-f, --force`` flag. examples -------- Pierre wants to unblock the domain ``example.com`` that he has blocked earlier:: $ li blocking unblock example.com Élysée want to unblock all blocked users, without confirmation:: $ li blocking unblock -f all .. _XEP-0191: https://xmpp.org/extensions/xep-0191.html .. _XEP-0191 § JID Matching: https://xmpp.org/extensions/xep-0191.html#matching