Canaux
Les canaux intègrent les conversations d’équipe à Libre WebUI : salons publics et
privés, ainsi que messages directs, avec fils de discussion, réactions, épingles,
suivi des éléments non lus, pièces jointes et réponses de @model, le tout sur les
mêmes fondations durables et chiffrées que le chat.
Types de canaux et adhésion
| Type | Qui peut le voir | Qui le rejoint |
|---|---|---|
public | Tout le monde peut le parcourir | Chacun peut le rejoindre lui-même |
private | Les membres uniquement | Le propriétaire invite les membres |
dm | Les deux participants uniquement | Ouvert automatiquement ; toujours deux exactement |
L’adhésion constitue la seule autorité sur le contenu d’un canal : chaque lecture et chaque écriture — y compris le téléchargement des pièces jointes et la livraison d’événements en direct — vérifie d’abord l’adhésion de l’appelant. Les non-membres reçoivent une erreur 404 qui ne révèle pas l’existence du canal. Le rôle d’administrateur global n’accorde délibérément aucun accès au contenu des canaux.
Le créateur d’un canal public ou privé en est le propriétaire. Les propriétaires peuvent le renommer, l’archiver, inviter des membres (canaux privés), retirer des membres, modérer les messages et supprimer le canal. Un propriétaire quitte le canal en le supprimant, jamais en l’abandonnant. Les messages directs sont dédupliqués pour chaque paire : ouvrir un DM avec la même personne mène toujours à la même conversation.
La chronologie
Les messages forment une chronologie persistante et ordonnée, lue dans les deux
sens au moyen de curseurs par clés (created_at plus l’identifiant du message), de
sorte que la pagination n’ignore ni ne duplique aucune entrée.
- Publications idempotentes. Le client fournit l’identité du message ; une requête réessayée aboutit exactement une fois à la même entrée de la chronologie.
- Suppression avec marqueur. La suppression d’un message efface son contenu, mais conserve l’entrée de la chronologie. Ainsi, les fils de discussion ne sont jamais orphelins et l’ordre ne change pas. Les auteurs suppriment leurs propres messages ; les propriétaires du canal peuvent tous les modérer.
- Les modifications sont réservées à l’auteur et portent un marqueur
editedAt. - Les fils de discussion n’ont qu’un niveau. Tout message racine peut accueillir un fil ; les réponses aux réponses sont rejetées. Les messages racines affichent en direct le nombre de réponses.
- Les réactions sont propres à chaque utilisateur et à chaque émoji, et sont comptées sans doublon.
- Les épingles sont gérées par les membres et répertoriées pour chaque canal.
Les noms et descriptions des canaux, ainsi que le contenu des messages, sont chiffrés au repos selon la même frontière que les messages de chat.
État de lecture
Chaque adhésion possède un curseur de lecture monotone. Le serveur calcule le
nombre d’éléments non lus par canal (vos propres messages ne sont jamais considérés
comme non lus) et POST /api/channels/:channelId/read avance le curseur sans jamais
le faire reculer. Un client obsolète ne peut donc pas faire réapparaître des
messages déjà lus.
Livraison en temps réel
Chaque modification de la chronologie est ajoutée au flux d’événements durable
channel:<id> et diffusée via GET /api/channels/:channelId/events (SSE).
L’adhésion est revérifiée avant chaque livraison : lorsqu’un membre est retiré, son
flux en direct est fermé de manière sûre. La chronologie SQL reste l’autorité : un
abonné qui a manqué des événements relit simplement la chronologie. Le registre
sert à la livraison, pas à établir la vérité.
Pièces jointes
Les fichiers sont d’abord téléversés (POST /api/channels/:channelId/attachments),
placés brièvement dans un cache partagé d’associations, puis joints lors de la
publication du message. Une association de téléversement ne peut servir qu’une
fois et expire sans être utilisée au bout de 15 minutes. Les octets du blob
appartiennent à la personne qui l’a téléversé (et comptent dans son quota) ; chaque
demande de téléchargement revérifie l’adhésion au canal.
Réponses de @model
Le compositeur permet d’adresser un message à un modèle. La réponse apparaît immédiatement sous forme de message en attente attribué au modèle, puis une tâche durable la termine en s’exécutant strictement sous l’identité du membre à l’origine de l’appel : accès aux modèles, identifiants du fournisseur et routage sont les siens, jamais ceux du propriétaire du canal ou d’un autre membre. Un membre retiré alors qu’une mention attend dans la file ne peut pas la maintenir : la tâche revérifie son adhésion avant la génération et consigne un échec visible à la place. Les échecs du modèle sont affichés sur la réponse elle-même au lieu de disparaître dans une file.
Les réponses du modèle utilisent la conversation récente du canal (jusqu’à 30 messages) comme contexte. Elles s’exécutent sous forme de complétions uniques : les outils de chat, la récupération de connaissances et la recherche web ne sont pas encore connectés aux mentions de canal.
Limites
| Limite | Valeur |
|---|---|
| Canaux créés par utilisateur | 50 |
| Membres par canal | 200 |
| Messages par canal | 50,000 |
| Longueur d’un message | 8,000 caractères |
| Pièces jointes par message | 5 × 10 MB |
| Réactions par message | 200 |
Frontières
- Les indicateurs de présence et l’état de saisie ne sont pas implémentés.
- L’exportation du contenu et les politiques de conservation des canaux suivent le mécanisme de sauvegarde de l’instance ; il n’existe pas encore d’exportation par canal.
- Les mentions envoient des notifications par le service de notification intégré ; il n’existe pas encore de préférence de notification propre à chaque canal, si ce n’est la possibilité de quitter le canal.