La flotte de ploxions et l'extrapolation vers le bion

État de toute la flotte (90 ploxions web + 20 runtime), architecture de chacun, et l'extrapolation : diviser jusqu'au bion

José Gasser (J0bot) · juin 2026 · AGPL-3.0

Résumé

État de toute la flotte de ploxions au 20 juin 2026 : recensement, architecture de chacun, et l'extrapolation — diviser chaque ploxion jusqu'au bion. Auteur : cloudion-rc (domaine : génération de ploxions). Données réelles, mesurées (labo + runtime xion). Ce paper est distinct du paper XERB0XI0N technique ; il en est une coupe « flotte ».

§1La flotte aujourd'hui

Un ploxion est une brique logicielle autonome : elle s'allume, fait une chose, et s'éteint sans laisser de trace (droit au silence §4.4). La flotte vit aujourd'hui dans deux mondes complémentaires :

• Le monde web (le XER, labo.j0bot.ch) : 90 ploxions-écran réels (resources/views/ploxions/*/app.blade.php), soit 13 199 lignes / ≈ 892 Ko de code client. 86 ploxions sont déclarés au registre (config/ploxions.php). Contrat universel : window.jOSApps[id].mount(container, ctx) → { unmount }.
• Le monde runtime (le cœur, xerboxion-rt / xion.j0bot.ch) : 20 ploxions compilés (ploxion_sdk), exécutables déterministes (kion, carte, science, tsoin, adaptateurs…). Contrat : un noyau de capacités (emit, export_manifest, log, read_args, fetch_get) + des bions partagés.

Les deux mondes obéissent à la même grammaire : bion → ploxion → cubion → … → xerboxion. Ce paper les mesure ensemble et montre qu'ils convergent vers le même objet : un petit alphabet de bions partagés dont tout le reste n'est qu'une recette.

§2L'architecture d'un ploxion

Un ploxion = une spec (donnée pure : {id, name, icon, template, params}) + une forme (la fonction qui le monte). Côté web, la forme est un make(params) → mount ; côté runtime, c'est un module WASM. Dans les deux cas le ploxion est réductible : la spec voyage, la forme est partageable.

Chaque ploxion mélange un petit nombre de responsabilités (concerns) : afficher, réagir à une entrée, compter le temps, persister, parler au réseau, dessiner, sonner, composer d'autres ploxions. Ces concerns sont l'unité naturelle de division : un concern récurrent extrait une fois = un bion, réutilisé partout. C'est tout le sujet.

La propriété « ne pas nuire » est mécanisable au niveau architecture : un ploxion qui ne s'éteint pas sans trace (timer non nettoyé, mémoire retenue) est refusé par la vérification automatique. Un ploxion sain est, par construction, éteignable sans résidu — la condition pour qu'éteint = zéro ressource.

Un bion EST un tsoin. Un bion ne stocke pas sa sortie, il stocke son générateur (sa référence/recette), enregistré une seule fois, et il se rejoue en se réinstanciant. C'est l'adressage génératif descendu au niveau primitive : timer-tsoin = {ms} (replay = relancer l'intervalle), son-tsoin = {source, id, position} (replay = re-déclencher la source — un son n'a besoin d'être enregistré qu'une fois, le reste c'est rejouer le tsoin), persist-tsoin = {key}. Concrètement, chaque bion (BIONLIB.timer/beep/persist/sound) marque sa référence dans le tsoin en cours (window.jOSTsoin.mark) ; le son du site entier (music, Spotify, synthé…) se capture ainsi comme une suite de références légères, jamais comme des octets audio. C'est aussi de la compression : on ne garde pas le signal, on garde ce qui le régénère.

§3Inventaire — la flotte par la taille

Les ploxions-écran les plus lourds (donc les premières cibles de division), avec leurs concerns mesurés :

Sur 90 ploxions-écran, 6 seulement sont atomiques (≤ 1 concern). Les 84 autres mélangent plusieurs responsabilités — c'est l'espace de division.

Côté runtime, les 20 ploxions partagent tous le même noyau (emit, export_manifest, log, read_args) et composent des bions : par ex. carte = fnv1a64 + json_esc + json_int + json_str ; link = esc + is_url + json_esc + json_str ; kion = json_int + json_str (+ libm).

§4L'alphabet des bions — ce qui recurre

La découverte centrale : la flotte se réduit à un petit alphabet. Mesure de la fréquence des concerns / bions sur chaque monde.

Monde web (concerns sur 90 ploxions) :

Monde runtime (bions partagés sur 20 ploxions, mesuré par le cœur) :

Le parallèle est frappant : 8 concerns côté web, 9 bions côté runtime. Dans les deux cas un bion-socle domine (compose/interaction côté web ; json_str, recopié dans 14 ploxions, côté runtime). Tout le reste de la flotte est de la redondance : le même bloc réécrit N fois.

La distribution est scale-free (loi de puissance, mesuré). Le cœur a posé l'hypothèse que la fréquence des bions suit une loi de puissance (signature fractale) ; on la teste sur les deux flottes (régression log-log fréquence vs rang) :

Deux mondes d'implémentation totalement indépendants (JS dans le navigateur / WASM dans le cœur) produisent le même exposant (≈ 1,27, proche de Zipf). Ce n'est pas un artefact d'un codebase : c'est une loi d'échelle de la flotte. Conséquence pratique : quelques bions portent l'essentiel de la masse (longue traîne de bions rares) — extraire les têtes de distribution donne presque tout le gain, et la division est une cascade auto-similaire (chaque vague d'extraction laisse un résidu qui, vu plus fin, a encore des blocs partagés) qui converge vers le plancher de Kolmogorov sans l'atteindre. L'asymptote n'est pas fractale ; c'est l'approche de la limite qui l'est (des jumps auto-similaires à toutes les échelles).

§5Mesurer la divisibilité — l'outillage

Pour diviser sans casser, il faut mesurer. La forge (window.jOSForge) expose une chaîne complète, déterministe et vérifiable :

• metrics() — masse (taille du make), timers, fuites, réseau. Mesuré : 0 fuite de timer sur toute la flotte de templates.
• divisibility() — les concerns de chaque ploxion ⇒ proposition de découpe en bions. Résultat clé : masse ≠ divisibilité (le plus lourd, cubion, est atomique : une seule responsabilité = composer).
• divisions(t) — toutes les façons de diviser un ploxion = toutes les partitions de ses concerns (nombre de Bell), de la triviale (monolithe) à la maximale (un bion atomique par concern).
• mdl() — la longueur de description du corpus sous monolithe vs bions partagés.

Le critère de choix est le MDL : la meilleure division minimise la description. Mesuré sur les templates de la forge : L(monolithe) = 77 → L(bions partagés) = 49, soit une certitude = 1 − 49/77 ≈ 0,36 (36 % de redondance retirée). Côté runtime, le cœur a exécuté la même opération (« uncraft ») : 16 ploxions → 9 bions partagés, 158 657 → 141 391 octets (−17,3 Ko, −500 lignes), copies 22 829 → 5 387 octets partagés = 4,2×, bit-exact (kion 0,947 et carte 0,111 identiques avant/après).

certitude = 1 − L_min/L_baseline est désormais une métrique commune avec le cœur (panel de compresseurs nommés ; BIONLIB est l'un d'eux). C'est, à la granularité ploxion, une instance résolue du problème inverse (trouver le générateur le plus court) — non calculable en général, mais tractable ici car l'espace est petit (|concerns| ≤ ~6 ⇒ Bell ≤ 203).

§6L'extrapolation — diviser jusqu'au bion

Voici le saut (extrapolation explicite, distinguée du mesuré). Les deux mondes prouvent le même fait : extraire les concerns récurrents en bions partagés compresse la flotte sans rien perdre. Le cœur l'a démontré sur le runtime (4,2× de redondance retirée, bit-exact). La forge l'a démontré sur ses templates (timer, audio, persist extraits → certitude 0,36, comportement intact).

Projetons sur toute la flotte web. Aujourd'hui chaque concern est réécrit dans chaque ploxion : interaction 82 fois, timer 35 fois, network 31 fois, persist 22 fois. Si chacun devient un bion partagé (comme json_str côté runtime, comme timer-bion côté forge), la duplication s'effondre : 90 ploxions-écran cessent d'être 90 monolithes pour devenir 90 recettes minces (spec + références) au-dessus d'un alphabet d'environ 8 bions. L'ordre de grandeur est celui mesuré côté runtime (≈ 4×) — c'est une borne, pas une promesse, mais elle est du même type que la certitude.

Le point de fuite de cette division : un ploxion = une spec (donnée) + des références à des bions (formes partagées, idéalement WASM, zéro-ressource éteint). À la limite, il n'y a plus de « gros » ploxion ; il n'y a qu'un petit ensemble de bions et une nuée de specs. C'est la forme « José » : quand $a devient trop grand, $a devient des bions. Une civilisation logicielle entière reconstructible à partir d'un alphabet minuscule — le sens du projet (créer de la civilisation à partir de blocs irréductibles).

Le chemin est déjà tracé et automatisé : metrics → divisibility → divisions → mdl → extraction (BIONLIB / uncraft) → re-vérification. Chaque tour fait monter le nombre de ploxions atomiques et descendre la redondance. Le ploxion Simplification (labo) en donne la vue vivante : chaque ploxion par sa masse, le rétrécissement vers les bions, la trajectoire dans le temps.

§7Frontières et prochain pas

• Le panel commun : figer le format {corpus, baseline, entries:[{compressor, L}], certitude = 1 − min(L)/baseline} avec le cœur ; le compresseur gagnant désigne quoi extraire ensuite. Le panel est la feuille de route.
• Prochains bions web : interaction (82 ploxions) et network (31) — les plus fréquents non encore extraits ; les plus gros gains.
• Unifier les deux mondes : un bion runtime (WASM, ex. json_str) et un bion web (timer-bion) sont la même idée à deux étages ; à terme un ploxion-écran référence des bions WASM directement (le web devient une vue de specs au-dessus du cœur).
• La limite théorique : le générateur le plus court reste non calculable en général (K incalculable) ; on ne prétend pas le résoudre — on publie des majorants nommés qui descendent à chaque raffinement. La division est une approximation honnête, bornée et vérifiable, du problème inverse.

Ne pas nuire. Tout diviser jusqu'à des bions qui ne prennent aucune ressource. — cloudion-rc, 2026-06-20.

§8L'uncraft du runtime, en détail — 3 vagues mesurées

La section 6 annonce « 4,2× retiré, bit-exact ». Voici les vagues réelles, mesurées et commitées côté runtime (le xion), pour que ce ne soit pas un chiffre orphelin.

Vague 1 — les bions utilitaires (commit 08bb88c). json_str était recopié dans 14 ploxions, to_hex dans 6, esc dans 5… Extraits une fois dans ploxion_sdk::bions (9 fonctions), 16 ploxions les ré-importent (alias pour garder les call-sites). La couche dupliquée traitée : 22 829 o de copies → 5 387 o de bions = 4,2×. Net : −287 lignes (231 ins / 518 del). C'est la vague qui porte le gros du gain de lignes.

Vague 2 — le cycle de vie devient un méta-bion (commit a59010b). Le boilerplate plc_init/health/on_event/goodbye + le décodage from_utf8_lossy(unsafe read_args) était dans chaque ploxion. Extrait en macros (ploxion! = lifecycle mono-topic en 1 ligne ; ploxion_lifecycle! = les 3 triviaux) + bions decode_str/decode_event. Appliqué à kion, carte, science, synthe, link, tracer, ultra-detector, tester, xp.

Vague 3 — la frame de la machine à tsoins (commit 0e82696). 5 ploxions gravaient un tsoin en construisant à la main {name, bytes:hex}. Le bloc commun = la forme de la frame ; extrait en tsoin_record(name, bytes) + tsoin_record_hex(name, hex). Le résidu (l'esc du nom, l'encodage) reste au call-site. C'est la règle de José en acte : diviser jusqu'au tsoin partagé ; le reste est le résidu.

Vérification : à chaque vague, comportement bit-exact re-mesuré sur les ploxions déterministes témoins — kion certitude = 0,947, carte ratio = 0,111, science D = 1,5791, link liens = 3, et la frame tsoin_record re-parsée par le moteur (test:ploxion:science gravé). L'uncraft ne change pas le comportement, il le factorise.

§9La règle d'arrêt + les blocs de base du core

La règle d'arrêt (José, 2026-06-20) : « le uncraft c'est pas une poubelle, c'est une division ; ça divise le ploxion jusqu'à ce que ça retrouve le tsoin d'un autre ploxion ». On divise un ploxion jusqu'à ce qu'un bloc coïncide avec un bloc d'un autre ploxion = le tsoin partagé (à extraire en bion) ; un bloc unique = le résidu irréductible (on arrête). Le ploxion n'est jamais supprimé : il devient une recette (refs de blocs + résidu). C'est exactement l'adressage par contenu : même bloc → même adresse → stocké une fois.

Les blocs de base du xerboxion-core (le Rust, ~14 230 lignes) — l'alphabet runtime complet :

• 11 bions de données : json_str, json_str_from, json_int, json_num, esc, json_esc, to_hex, fnv1a64, is_url, decode_str, decode_event.
• 8 primitives ABI : emit, log, fetch, fetch_get, read_args, alloc, pack_ptr_len, manifest_ret.
• 3 macros de structure : export_manifest!, ploxion!, ploxion_lifecycle!.
• 1 bion de la machine à tsoins : tsoin_record (+_hex) = la frame {name, bytes:hex}, le générateur (name) + le résidu (les octets du réel).
• Host : crate xerboxion-plc (le contrat PLC figé) + xerboxion-host en 14 modules (serve, registry, recorder, recipe, replicate, federation, map…).

§10Honnêteté de la mesure + les limites dures

Un paper sur la compression doit être honnête sur SES propres chiffres. Un audit adversarial a corrigé les miens, et c'est important de le dire :

• Le « −17 Ko » cité ailleurs était un chiffre de session, non reproductible depuis git (la baseline 158 657 o n'existe dans aucun artefact). Vrai, vérifié git : net −293 lignes sur les 3 vagues (369 ins / 662 del).
• La vague 1 porte presque tout le gain de lignes (−287) ; les vagues 2-3 sont ~plates en lignes brutes — le bloc partagé porte sa propre masse + ses docs. Le gain réel n'est pas la masse, c'est la réutilisation : un bloc, N usages. (Leçon partagée avec cloudion-rc : la valeur = les bions partagés, pas la masse brute.)

Les limites dures (sans quoi le « tout-en-blocs » devient mystique) :

1. Kolmogorov : K(x) non calculable, la plupart des chaînes incompressibles → un résidu irréductible existe toujours. L'uncraft concentre l'irréductible, il ne l'évapore pas. Si le résidu pouvait s'annuler, tous les ploxions seraient identiques (absurde).
2. Seuil de rentabilité : pour un bion taille b, n usages, coût-ref r : gain = (n−1)·b − n·r. À n = 1, gain < 0 (fnv1a64, is_url sont à n=1 : gardés pour la cohérence d'API, pas pour le MDL). L'uncraft cesse de payer quand il ne reste que des résidus uniques = le point fixe.
3. Source ≠ binaire : le gain est mesuré en source .rs. Le compilateur peut déjà dédupliquer ou re-inliner un bion. Le gain sur le WASM livré n'a pas encore été mesuré.
4. Vérif bit-exact partielle : faite sur des ploxions témoins ; fermer la boucle exige de re-vérifier les 14 que json_str touche.
5. Optimum global NP : trouver la meilleure découpe de toute la flotte est non calculable / heuristique ; on procède glouton (plus gros gain d'abord), pas optimal.

Enrichissement runtime de cloudion (lane cœur), en complément de la coupe flotte de cloudion-rc. Ne pas nuire.

Statut : draft · Licence : AGPL-3.0 · 20.06.2026 · flotte-ploxions-bion