quest'n'click 4.5.0 · r1

Construite pour quest'n'click 4.5.0, révision r1. Si elle est publiée, et laquelle est la courante, est dit par publication.json.

Confidentialité

English · Type : référence · Public : joueur · Contexte : navigateur du joueur · Statut : prête · S'applique depuis : 4.1.16

Ce qu’un jeu quest'n'click, son Bridge Reality et ses connecteurs gardent sur un joueur, où, combien de temps, et comment l’effacer. Vrai depuis la 4.1.16 (les runs de speedrun gardés dans le stockage SQL du Bridge) ; le reste dit depuis quand.

Qui répond de quoi

Le logiciel garde peu de choses, et cette page dit exactement lesquelles, pour que celui qui fait tourner un jeu puisse le dire à ses joueurs. L’opérateur qui fait tourner un Bridge et ses connecteurs est celui qui répond de ces données devant les joueurs. Le site qui sert un jeu (GitHub Pages, Clever Cloud, tout hébergeur) a ses propres journaux de serveur, qui sont ceux de l’hébergeur, pas du moteur.

Un jeu sans Reality (reality dans son contenu), sans mondes Remix du jour ou mystère et sans classements en ligne ne garde rien en dehors de l’appareil du joueur : le moteur n’a ni mesure d’audience, ni pistage, ni compte, et il ne récupère que ses propres fichiers depuis le site qui le sert.

Sur l’appareil du joueur

Effacer : Unlink this game dans le menu de pause (le libellé anglais par défaut ; un jeu peut le traduire) révoque le lien sur le Bridge ; effacer les données du site dans le navigateur retire le reste (Recommencer n’efface que la sauvegarde automatique, pas les emplacements ni les records).

Limite · device-storage-browser-rules C’est le navigateur qui décide de la durée de vie des données d’un site : effacer les données du site, la navigation privée, ou Safari qui retire un site pas ouvert depuis sept jours efface sauvegardes et records avec tout le reste.

Sur le Bridge

Un Bridge (le serveur Reality d’un jeu) garde, par joueur : le playerId, le SHA-256 de sa capacité, son expiration ; par signal : son identifiant, sa séquence, son nom, sa source, la clé de dédoublonnage du connecteur (un SHA-256 pour les connecteurs fournis), l’empreinte de ce que le connecteur a vu (evidenceHash), l’enveloppe signée, le contenu du signal tel qu’accepté (pour le signer de nouveau après une rotation de clé), et les heures. Jamais un jeton ni un email. Un code d’appairage vit dix minutes par défaut. Le journal du Bridge est fait de lignes JSON qui nomment des événements et des identifiants pseudonymes, sans secret.

L’endroit dépend du stockage choisi par l’opérateur :

StockageOùCombien de temps
SQLite (profil local, celui de npm run bridge par défaut)un fichier, mode 0600Chaque signal est gardé : un stockage SQL n’a pas encore de rétention
Postgres (profil distributed, expérimental)la base de l’opérateurPareil : pas encore de rétention
Le journal en lignes JSON (une configuration écrite avant la 4.1.10)journal.jsonl à côté de la configuration du BridgeJusqu’à ce que compact --retention-days=<N> (90 par défaut) retire les signaux acquittés plus vieux que N jours ; le dernier signal d’un joueur reste

Une sauvegarde du Bridge contient les mêmes données que le stockage d’où elle vient.

Classements de speedrun

Un Bridge avec des classements garde chaque run envoyé dans son stockage SQL : le jeu, la catégorie, la graine et les entrées du run, le verdict, et un pseudonyme (2 à 32 lettres, chiffres, espaces, _ . - ; un email est refusé). Les pseudonymes ne sont pas authentifiés, et le Bridge ne connaît aucune identité derrière eux. L’enveloppe du run est jetée une fois son verdict enregistré. Un classement garde un run 90 jours par défaut (retentionDays), et le supprime sur demande avec le jeton donné à l’envoi (DELETE /v1/runs/<id> avec x-delete-token). La limite de débit reconnaît un client par un HMAC de son adresse, jamais l’adresse. Les jetons des mondes du jour et mystère sont gardés dans le même stockage pendant retentionDays (30 par défaut).

Connecteurs

Ce qui sort de n’importe quel connecteur vers le Bridge : le nom du signal, le joueur, la source, la clé de dédoublonnage, l’heure, et le SHA-256 du contenu vu par le connecteur (evidenceHash) ; jamais le contenu, le message, la ligne tapée ni le badge.

La page de chaque connecteur dit comment le faire tourner : Email, Telnet, SSH, Open Badges.

Journaux et métriques

Chaque connecteur journalise des lignes JSON d’événements, d’identifiants (playerId, noms de signaux, codes de refus) et de compteurs. Une chaîne qui ressemble à du contenu (une espace, un @, une barre oblique) est écrite [redacted] ; les tests vérifient qu’aucune adresse, aucun texte ni aucun secret des données de test n’atteint un journal. Les métriques (/metrics) sont des compteurs en mémoire. La durée de vie des journaux est celle de la rotation choisie par l’opérateur ; ils ne contiennent aucun contenu à effacer, et un playerId y est pseudonyme.

Effacer les données d’un joueur, partout

  1. Sur le Bridge : GET /v1/admin/players/<id> (avec le jeton de l’opérateur) exporte tout ce qui est gardé sur le joueur ; DELETE /v1/admin/players/<id> le retire (le lien, les signaux, les acquittements) et ferme ses flux en direct. Un locataire entier : tenant export et tenant delete --yes (la ligne de commande du Bridge).
  2. Dans une boîte IMAP : supprimez les messages marqués du joueur, s’il y en a (ceux acceptés sont déjà partis avec keepDays: 0).
  3. Dans la configuration SSH : retirez la clé déclarée du joueur, s’il y en a une, et redémarrez le connecteur.
  4. En mémoire (liens d’expéditeur, mots de reprise) : redémarrer les connecteurs oublie tout.
  5. Un run de classement : supprimé avec son jeton de suppression ; sinon il part après retentionDays.
  6. Sur l’appareil : le joueur efface la sauvegarde ou les données du site.

Limite · backups-keep-deleted Effacer un joueur le retire du stockage en service, pas des sauvegardes faites avant : la durée de vie des sauvegardes est le choix de l’opérateur.

Références


Modifier la source de cette page · Signaler une erreur