Aucun serveur central : le système d'information d'une constellation Astroport.ONE est tissé de clefs publiques. Chaque clef ouvre une couche : réseau, identité, messages, services, monnaie — et se déploie dans l'espace (la grille géographique) et dans le temps (les cycles de la station).
Un MULTIPASS naît d'un couple secret SALT + PEPPER (le « DISCO », reconstitué par partage de secret SSSS). De lui dérivent, par la même graine, les trois clefs publiques que le reste du système va relier entre elles. La swarm.key de la constellation agit comme un sel commun : elle donne le UPLANETNAME qui entre dans la dérivation du portefeuille Ğ1.
La même clef NOSTR sert aussi de login au cloud personnel : FaceCloud (l'interface ucloud.html, avec l'analyse de visages) et le montage WebDAV sous /dav. Une requête signée NIP-98 suffit à ouvrir son coffre, chiffré en AES-256-GCM avant d'être confié à IPFS ; pour les clients DAV qui ne savent pas signer, un jeton dav_token sert de mot de passe Basic Auth.
LA STATION : même principe — sa clef SSH ed25519 dérive vers son IPFSNODEID (ssh_to_g1ipfs.py). Quand les deux coïncident, la station est au niveau Y : ce lien prouve que l'accès SSH annoncé appartient bien à cette machine.
Cinq plans empilés, alignés à la verticale : une même station occupe la même position sur chaque plan, et sa chaîne de clefs les traverse tous. L'axe vertical est la profondeur fonctionnelle, le plan horizontal est l'espace géographique. Lancez le temps : la quatrième dimension fait vivre les cycles réels des scripts (heure, nuit de 20h12, semaine de paiement). Faites pivoter la scène à la souris, ou isolez une couche avec la légende.
STATIONS FICTIVES (DÉMO) · LES ÉVÉNEMENTS ET LES CYCLES REPRODUISENT CEUX DES SCRIPTS : _12345.sh, NOSTRCARD.refresh.sh, 20h12.process.sh
Cliquez une couche pour l'isoler et lire les clefs qui la composent.
| CLEF | D'OÙ ELLE VIENT | CE QU'ELLE OUVRE |
|---|---|---|
| swarm.key | Secret partagé de la constellation (PSK libp2p, 32 octets). Non publique. | Réseau IPFS privé et UPLANETNAME. En mode ORIGIN : 000…000, espace d'accueil ouvert. |
| IPFSNODEID | PeerID libp2p de la station. | Balise IPNS (12345.json, _MySwarm.moats), tunnels /x/<service>-ID. |
| Y-Level (SSH) | Clef SSH ed25519 → Ğ1 → IPFS. | Prouve qu'une clef SSH annoncée appartient à la station ; condition pour être ajoutée aux authorized_keys des capitaines. |
| NODEHEX · NODEG1PUB | Clefs NOSTR et Ğ1 de la station. | Événements signés par la station, portefeuille du nœud. |
| MULTIPASS | Email + DISCO (SALT/PEPPER). | HEX NOSTR, G1PUBNOSTR (Ğ1), NOSTRNS (IPNS), login FaceCloud/DAV. Porte les ẐEN détenus (OPEX) et paie la redevance hebdomadaire. |
| ZenCard | Créée depuis le MULTIPASS et son GPS. | Carte ẐEN (.g1pub) du joueur : mémorise l'historique des ẐEN contribués (CAPEX). |
| Capitaine | CAPTAINEMAIL → captainHEX, CAPTAING1PUB. | Reçoit la PAF (CAPTAIN_DEDICATED), suit les MULTIPASS en NOSTR, transmet la swarm.key aux nouveaux. |
| Portefeuilles coopératifs | UPLANETNAME.<rôle> | TREASURY, RND, ASSETS, CAPITAL, IMPOT, AMORTISSEMENT, SOCIETY, INTRUSION : la règle des 3×1/3. |
| UMAP · SECTOR · REGION | Cellules géographiques de 0,01°, 0,1° et 1°. | Une clef NOSTR par cellule : ancrage territorial des données. Les messages aimés y remontent de la UMAP au SECTOR (≥ 3 likes) puis à la REGION (≥ 12 likes). |
Les coordonnées GPS d'un MULTIPASS le rangent dans trois cellules emboîtées. Chaque niveau est un plan de la 3D, et on monte d'échelle de bas en haut : du voisinage (UMAP) au secteur, puis à la région. Chaque cellule possède sa propre clef publique, et le contenu aimé remonte : à partir de 3 likes un message entre dans le journal du SECTOR, à partir de 12 likes dans celui de la REGION. La qualité fait monter, sans modération centrale.
Rien n'est temps réel permanent : l'essaim respire par cycles. Neuf jours de vie d'une station, avec chaque cycle à sa place. Chaque trait vertical fin est une heure ; le curseur parcourt la fenêtre.
_12345.sh scanne les pairs IPFS, rafraîchit les balises, lance le backfill NOSTR (jamais deux fois en moins de 50 min) et NOSTRCARD.refresh.sh. Si ce dernier tourne encore au cycle suivant, le Capitaine est prévenu : la station est saturée.
Traitement quotidien : nettoyage de ~/.zen/tmp (donc des fichiers secrets temporaires), rafraîchissement des joueurs, backfill --days 1. Une balise de plus de 12 h est considérée morte et retirée du swarm.
Tous les 7 jours depuis sa naissance, le MULTIPASS paie sa redevance (NCARD) au portefeuille du Capitaine. La liste de relais (kind 10002) et le suivi du Capitaine (kind 3) sont republiés.
Deux clefs, deux mémoires. La ZenCard garde l'historique des ẐEN contribués à la coopérative : le capital engagé (CAPEX). Le MULTIPASS porte les ẐEN détenus, ceux qui servent à vivre dans l'essaim : le fonctionnement courant (OPEX), à commencer par sa redevance hebdomadaire. Entre les deux, un pont avec OpenCollective.
Chaque ẐEN contribué à la coopérative reste inscrit dans l'historique de la ZenCard. C'est la mémoire de ce que chacun a mis au pot commun.
Les ẐEN du MULTIPASS se dépensent : redevance hebdomadaire au Capitaine, likes (1 ẐEN = 1 like), services de l'essaim. Un solde trop bas déclenche un avertissement avant toute conséquence.
Le pont n'est pas lié à un collectif unique : le slug et la correspondance des paliers avec les catégories (satellite, constellation, labo, cloud) sont configurables. Une autre coopérative peut brancher son propre collectif.
Une nouvelle machine installée par la communauté démarre en ORIGIN, l'espace d'accueil d'UPlanet (swarm.key à zéros). Elle devient membre d'une constellation ẐEN le jour où un Capitaine l'y invite en lui transmettant la clef de l'essaim.
La machine s'installe en ORIGIN, crée son MULTIPASS et publie sa balise IPNS (12345.json).
Les stations du swarm voient apparaître la balise. Les 12345.json venus d'un pair sont non fiables : chaque station vérifie son _MySwarm.moats (is_astroport_node), y compris pour les stations annoncées de proche en proche.
Le Capitaine reçoit un email : hostname, capitaine de la machine, mode ORIGIN, Power-Score, services partagés. Une seule notification par station.
Le Capitaine rencontre le propriétaire (NOSTR ou email) et évalue la machine et son capitaine : puissance, fiabilité, PAF négociée et contrôlée avec PowerJoular.
La swarm.key de la constellation est transmise. Le nouvel arrivant lance zen_join.beta.sh : ses comptes ORIGIN sont nettoyés, la clef ẐEN installée, ses portefeuilles coopératifs initialisés.
Sa station rejoint le réseau privé, ses événements sont synchronisés, ses services partagés par tunnels /x/. Son capitaine peut, à son tour, être vouché par ses pairs.
Un pair du swarm ne doit pas pouvoir se faire passer pour un capitaine fondateur. Les événements kind 3 (suivis), 30800 (DID) et 30850 (santé économique) sont donc toujours importés avec vérification de signature, même quand la synchronisation tourne en mode rapide. Ces événements décident quelles clefs SSH sont acceptées : confiance à deux sauts, depuis les capitaines fondateurs, avec quorum et réciprocité au deuxième saut.