Doolta

AXF

Un format ouvert et une boîte à outils pour gérer des identités numériques isolées et portables, entre shells, navigateurs et outils de développement.

Détails du projet

Problème réelBasculer entre un emploi principal, un client freelance, un projet personnel et un compte pseudonyme signifie en général jongler avec les règles de ~/.ssh/config, surcharger .gitconfig pour ne pas commiter avec le mauvais email, et faire tourner des fenêtres de navigateur séparées pour que cookies et historique ne se mélangent pas.
ContraintesRendre le changement d’identité explicite, reproductible et auditable : une commande pour entrer dans un contexte d’identité, une pour en sortir proprement. Identités stockées en documents JSON versionnables. Pas de démon, pas d’état caché.
Choix structurantsUne spécification JSON ouverte (l’Alter eXtensible Format) délibérément pensée comme OpenAPI pour les APIs ou OCI pour les conteneurs : une référence, plusieurs implémentations indépendantes. Ce dépôt fournit le SDK Go de référence, un runtime d’activation local exposé en CLI (axf up / axf down), des providers pour le shell, l’identité git, le profil navigateur et la sélection de clé SSH, ainsi qu’une couche de politique et d’audit (l’Alter Guard) sur le chemin d’activation.
Preuve aujourd'huiUn projet Go testé et audité en continu, pas seulement une esquisse de spécification : make test tourne avec le détecteur de races, make cover verrouille la couverture à 80 %, et make audit exécute govulncheck et golangci-lint. La spécification elle-même annonce clairement qu’elle est en draft v0 (runtime v1.1) et pas encore stable, la rigueur est appliquée avant que le format soit figé, pas après.
Offre associéeApproche sur mesure. Nous contacter.

Transformer une friction récurrente en format ouvert

AXF nomme un problème que beaucoup de personnes jonglant entre plusieurs contextes professionnels ou personnels ont déjà rencontré sans le nommer : le changement de contexte d’identité. Plutôt qu’un nouvel empilement de scripts shell improvisés, il donne à ce problème une commande pour entrer dans un contexte et une pour en sortir, à la demande, dans le shell courant, sans processus en arrière-plan.

Une spécification ouverte, pas un nouvel outil propriétaire

Le dépôt embarque un SDK Go de référence pour le modèle de données v0, un runtime CLI local, et des providers pour le shell, l’identité git, le profil navigateur et la sélection de clé SSH, mais l’artefact réellement construit est la spécification : un format pensé pour être implémenté par plus d’un outil, comme le sont OpenAPI ou OCI.

Honnête sur son propre stade d’avancement

La spécification est explicitement marquée draft, le runtime encore pré-1.0 dans l’esprit même en v1.1, et le README le dit directement plutôt que de survendre sa maturité. Ce qui est déjà en place, tests, seuil de couverture, audit continu de vulnérabilités et de lint, est bien réel, indépendamment de la maturité de la spécification.

Ce projet démontre le même réflexe visible partout ailleurs dans ce laboratoire : quand un problème mécanique et source d’erreurs se répète, chercher le modèle général qui le sous-tend avant de sortir un nouveau script ponctuel.