Architecture

Statut : contrat de fondation pour 0.1.x.

Jeu Luanti, pas fork moteur

Le dépôt est installé comme un game nommé sanctuary_luanti. Luanti reste une dépendance externe. Cette séparation permet de suivre les versions de sécurité du moteur et de distribuer Sanctuary par les mécanismes ordinaires de Luanti.

Un fork du moteur ne peut être proposé qu'avec :

une limitation reproductible de l'API publique ;
l'absence d'une solution sûre par mod, menu ou service compagnon ;
un patch minimal discuté avec l'amont ;
un budget de maintenance multi-plateforme et de suivi sécurité.

Modules

La fondation contient un seul mod :

sanctuary_core — progression, étapes, jalons, événements et healthcheck.

Les futurs domaines (sanctuary_world, sanctuary_life, sanctuary_atlas, sanctuary_travel, etc.) ne seront extraits que lorsqu'ils auront une donnée propre, une API publique et des tests indépendants. Aucun mod ne doit écrire directement dans les métadonnées privées d'un autre.

Données persistantes

La première donnée joueur utilise les métadonnées Luanti :

sanctuary:progression_version
sanctuary:stat_<id>
sanctuary:stage
sanctuary:stardust

Règles :

version entière croissante ;
valeurs bornées par le serveur ;
migration monotone ;
conservation des clés inconnues ;
snapshot en lecture seule pour l'interface ;
aucune confiance dans un prix, rang ou résultat envoyé par un client.

Les données collectives utiliseront le ModStorage du monde avec un journal de migration distinct.

Trois échelles de voyage

1. Lieux d'un même monde Luanti

Luanti expose un espace de carte par monde, sans dimensions natives équivalentes à celles de Minecraft. Les premières ères peuvent donc être des régions séparées dans le même espace, reliées par des portails et des arrivées validées côté serveur. Cette voie permet un prototype jouable sans modifier le moteur.

2. Mondes d'une même installation

Deux sauvegardes restent deux mondes distincts. Le jeu peut présenter leur existence et préparer un handoff, mais ne doit pas copier directement leurs bases SQLite. Un transfert passe par un format d'export versionné puis une politique d'import explicite.

3. Serveurs fédérés

Luanti ne fournit pas d'identité centralisée : chaque serveur authentifie ses propres comptes. Le serveur de jeu ne dispose pas non plus d'un mécanisme général pour déplacer silencieusement un client vers un autre serveur.

Le premier portail fédéré sera donc honnête sur cette frontière :

découverte d'un manifeste public de destination ;
vérification de l'identité du monde et de sa compatibilité ;
consentement visible du joueur ;
émission éventuelle d'un billet de passage court et signé ;
reconnexion explicite vers l'adresse choisie ;
validation locale par le serveur d'arrivée.

Le prototype ne transporte ni inventaire, ni monnaie, ni privilèges. Il peut transporter un reçu minimal : monde d'origine, jalon public, instant d'émission, expiration et nonce anti-rejeu. La destination décide seule de ce qu'elle en fait.

Manifeste de monde envisagé

Format de travail, non stabilisé :

{
  "schema": "sanctuary.place.v1",
  "id": "did:web:example.org:worlds:orchard",
  "name": "Le Verger",
  "endpoint": { "host": "play.example.org", "port": 30000 },
  "game": { "id": "sanctuary_luanti", "compatibility": "0.1" },
  "public_key": "...",
  "routes": []
}

Avant implémentation, il faudra décider la canonicalisation, les signatures, la rotation des clés, l'expiration, la révocation et le modèle de menace. Aucun accès HTTP non sandboxé ne doit être activé par défaut dans un mod de jeu.

Préservation

Une release distribuable devra fournir :

un export cohérent du monde à l'arrêt ;
un manifeste de versions du moteur, du jeu et des schémas ;
des checksums ;
une procédure de restauration testée ;
une séparation entre données publiques, privées et secrets ;
une politique de rétention décidée par l'administrateur du lieu.

4.1 KiB Raw Permalink Blame History