matty/peertube-plugin-livechat
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Terms&Conditions (#18) WIP:

Browse Source 
* technical documentation
* update user documentation
This commit is contained in:
John Livingston 2024-06-25 13:14:13 +02:00
parent 27c10a0324
commit c0c835df11
No known key found for this signature in database
GPG Key ID: B17B5640CE66CDBC
2 changed files with 75 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
support/documentation/content/en/documentation/user/streamers/terms.md
View File

@ -40,3 +40,8 @@ You can change the terms content at any time, it will be instantly updated for a
Users can hide the terms & conditions.
When doing so, terms won't be shown again, unless you change the content.
{{% notice info %}}
If your Peertube instance allows joining chat with [XMPP clients](https://livingston.frama.io/peertube-plugin-livechat/documentation/admin/advanced/xmpp_clients/), users using such clients will see the terms as chat messages, comming from a "Peertube" account.
When you update terms, they will receive a new message with the update terms content.
{{% /notice %}}

70
support/documentation/content/en/technical/terms.md Normal file
View File

@ -0,0 +1,70 @@
---
title: "Terms&Conditions"
description: "Terms&Conditions implementation"
weight: 65
chapter: false
livechatnotranslation: true
---
You can set terms & conditions on the instance level (called "global terms"), or at the streamers' channels level (called "muc terms", as it is related to muc rooms).
## Backend
The `mod_muc_peertubelivechat_terms` prosody modules handles the terms configuration.
It has a configuration option for the global terms.
It also adds muc terms in the room data.
When a new occupant session is opened, this modules sends him messages containing the global and muc terms (if set).
Here is an example of sent messages:
```xml
<message xmlns="jabber:client" id="_iRSEs061gi5GBjF7zGh7f-M" type="groupchat" to="root@p1.localhost/QH1H89H1" from="8df24108-6e70-4fc8-b1cc-f2db7fcdd535@room.p1.localhost/Peertube">
<body>The global terms.</body>
<x-livechat-terms type="global" />
<delay xmlns="urn:xmpp:delay" stamp="2024-06-25T11:02:25Z" />
<stanza-id by="8df24108-6e70-4fc8-b1cc-f2db7fcdd535@room.p1.localhost" xmlns="urn:xmpp:sid:0" id="InoL5fonvOoR8X9gOlAYsz_N" />
</message>
<message xmlns="jabber:client" id="_iRSEs061gi5GBjF7zGh7f-M" type="groupchat" to="root@p1.localhost/QH1H89H1" from="8df24108-6e70-4fc8-b1cc-f2db7fcdd535@room.p1.localhost/Peertube">
<body>The muc terms.</body>
<x-livechat-terms type="muc" />
<delay xmlns="urn:xmpp:delay" stamp="2024-06-25T11:02:25Z" />
<stanza-id by="8df24108-6e70-4fc8-b1cc-f2db7fcdd535@room.p1.localhost" xmlns="urn:xmpp:sid:0" id="InoL5fonvOoR8X9gOlAYsz_N" />
</message>
```
Notice the `x-livechat-terms` tag.
Standard XMPP clients will show these messages as standard message.
Message are sent from a "service nickname": this occupant does not exist.
The service nickname is an option of the module (livechat use "Peertube", hard coded for now).
This nickname is reserved, no-one can spoof it (the module will bounce any request to use this nickname).
We must do so, because without nickname, some XMPP clients won't show the messages (tested with Gajim).
We also add a `delay` tag, to trick the moderation bot (see comments in code).
This also ensure clients will not drop the message because there is no occupant with this name.
When muc terms are updated, the new terms will be broadcasted.
## Frontend
For standard XMPP clients, terms will be shown as delayed messages.
For the livechat frontend, there is a `livechat-converse-terms` Converse plugin that will intercept these messages, and prevent them to be shown in the chat history.
It will also create infobox at the top of the chat to display the terms content.
If muc terms are updated, the new terms will be shown.
Users can hide the terms.
To remember that a user has already hidden the terms, we store the content in localStorage.
We will only show terms again if the content in this localStorage changes.
We do so for both global terms and muc terms, in two separate localStorage keys.
The keys in localstorage does not depends on the room JID or the origin peertube instance.
This means that message will be shown again:
* if terms are modified
* if the user switch to another channel
* if the user switch to a video from a different peertube instance