The livechat plugin includes a [Task Application](/peertube-plugin-livechat/documentation/user/streamers/tasks).
The present document describes how this is implemented.
## Basics
This features relies on [XEP-0060: Publish-Subscribe](https://xmpp.org/extensions/xep-0060.html).
This XEP provide a way to store and retrieve items, and to receive push notifications when an item is created/deleted/modified.
There is a Prosody Module, [mod_pubsub_peertubelivechat](https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/prosody-modules/mod_pubsub_peertubelivechat), to implement some specific use of the pubsub mechanism.
The "livechat-tasks" node contains two type of objects: Task and TaskList (XML Namespaces: `urn:peertube-plugin-livechat:tasklist` and `urn:peertube-plugin-livechat:task`). Tasks have an attribute containing their task list id.
On the front-end, we have the [livechat-converse-tasks](https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/conversejs/custom/plugins/tasks) plugin for ConverseJS.
## Workflow
Here is the basic workflow used to subscribe to tasks/task-lists, and receive existing items.
* the browsers connect to the chat, and ConverseJS uses the [XMPP discovery](https://xmpp.org/extensions/xep-0045.html#disco-roominfo) to get the room features.
* mod_pubsub_peertubelivechat declares two features: `urn:peertube-plugin-livechat:tasklist` and `urn:peertube-plugin-livechat:task`.
* the browsers detect these feature, and checks that the user has admin or owner affiliation on the MUC component.
* if not, won't display the Task Application, and stops here.
* if yes, we will continue:
* display the Task Application.
* Create a new [PubSubManager](https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/conversejs/custom/shared/lib/pubsub-manager.js) object, that will subscribe to the pubsub node.
* The backend receives the subscription request, test user rights (must be owner/admin on the MUC), and adds the user to the subscribers.
* Note: a user with multiple browsers tabs will send multiple subscription requests, but this is not an issue.
* If the node did not exist, the backend automatically created it, and use the MUC name to create a first task-list with that name.
* Once subscribed, the frontend will request all current entries.
* The backend tests rights, and send all node entries.
* On the frontend, the PubSubManager handles the response by dispatching received items to the correct frontend component.
Note: on the backend side, we subscribe all users with the "publisher" affiliation level.
This allows them to publish items, but not change the node configuration.
Here is the worflow to create/modify/delete items:
* the frontend send a publish request.
* backend checks rights.
* backend sends notifications to all subscribers, including the current users.
* On the front-end PubSubManager receives the notification, and dispatch it to the relevant component.