J'ai construit un système de vérification audio pour ne plus avoir à faire confiance à personne.

#obsidianneural #iagnrative #opensource #musique

Je suis fatigué de dépendre des géants du web. Pas par idéologie creuse — par expérience concrète. Quand votre infrastructure musicale repose sur un seul fournisseur d'inférence, vous n'avez pas un outil. Vous avez une dette envers une entreprise dont les CGU, les tarifs et la disponibilité peuvent changer du jour au lendemain.

OBSIDIAN Neural est un plugin VST3/AU de génération audio en temps réel. Il tourne sur un réseau distribué de GPUs — des machines appartenant à des gens réels, rémunérées équitablement, sans intermédiaire opaque. Mais distribué, ça veut aussi dire : comment savoir que la machine en face fait vraiment ce qu'elle prétend faire ?

Le problème : la confiance dans un réseau distribué

Imaginons que vous rejoignez le réseau en tant que provider. Vous branchez votre GPU, vous générez de l'audio. À la fin du mois, vous recevez une part équitable des revenus.

Maintenant imaginez que quelqu'un triche. Il prétend faire tourner le modèle, mais en réalité il relaie les requêtes ailleurs — ou pire, il renvoie du bruit aléatoire. Il touche quand même sa part.

Dans un système centralisé, c'est le problème de la plateforme. Vous faites confiance à la plateforme.

Moi, je ne veux pas être une plateforme à laquelle on fait confiance. Je veux un réseau où la confiance n'est pas nécessaire parce qu'elle est vérifiable.

La solution : un proof-of-work audio

L'idée s'inspire des mécanismes de consensus des blockchains — pas pour faire du Web3, mais pour le principe : un nœud doit prouver qu'il travaille vraiment.

Comment ça marche

À intervalles aléatoires (entre 1h et 5h, pour qu'on ne puisse pas anticiper), le serveur central tire :

un prompt parmi 64 prompts de référence ("steady kick drum loop 120bpm", "warm Rhodes chord", etc.)
un seed aléatoire

Il envoie ça à un sous-ensemble de providers via POST /verify. Chaque provider doit générer l'audio et le renvoyer.

Le serveur calcule ensuite une empreinte mel — un vecteur de 128 valeurs représentant la distribution spectrale moyenne du son. Puis il compare chaque empreinte à la référence via similarité cosinus.

Si la similarité est inférieure à 0,98 : échec. Trois échecs consécutifs : ban automatique.

L'étalon physique

Le point critique du système, c'est la référence. Si la référence est calculée comme la moyenne du groupe, un groupe de providers qui trichent ensemble peuvent se valider mutuellement — une attaque de coalition.

Pour éviter ça, il y a un nœud de référence physique — une machine de confiance dont les empreintes sont la vérité absolue. Avant chaque round, ce nœud génère plusieurs samples avec des prompts et seeds variés. Ces empreintes sont chiffrées avec une clé Fernet dédiée avant d'être stockées en base — une fuite de la DB n'expose rien d'exploitable.

Pendant le round, un sample est tiré aléatoirement parmi ceux en banque. Les providers ne savent pas lequel sera utilisé. Ils ne peuvent pas anticiper.

Round de vérification
│
├── Nœud de référence disponible ?
│   ├── OUI → génère des samples → chiffre → stocke en banque
│   │         → tire un sample au hasard → référence absolue
│   └── NON → banque de samples existante → tirage aléatoire
│             └── banque vide → round annulé (pas de ban)
│
└── Providers sélectionnés
    ├── Attend que chaque provider finisse son job en cours
    ├── Lock atomique (is_disposable = false)
    ├── Envoie POST /verify en parallèle
    ├── Calcule similarité cosinus vs référence
    └── Unlock dans tous les cas (finally)

Pourquoi aléatoire ?

Parce qu'un test prévisible n'est pas un test. Si les providers savent quand et avec quel prompt ils seront testés, ils peuvent jouer le jeu uniquement pendant les vérifications. L'aléatoire sur l'intervalle, le prompt, le seed et le sample tiré rend ça structurellement difficile.

Et pendant le test, les jobs de prod ?

Un provider sous vérification est marqué is_disposable = false. Il disparaît du pool de génération. Les jobs de prod passent sur les autres nodes disponibles ou basculent sur fal.ai en fallback. Le test ne bloque pas le réseau.

Pourquoi c'est aussi un positionnement politique

Je construis ça parce que j'en ai marre de la logique extractive des grandes plateformes cloud.

Quand vous utilisez un service GPU centralisé, vous enrichissez une infrastructure qui décide seule de ses tarifs, de ses priorités, de ce qu'elle accepte ou non comme usage. Vous n'avez aucun levier.

OBSIDIAN Neural est une tentative de construire une alternative : un réseau où les gens qui font tourner les machines sont aussi ceux qui en bénéficient. Revenus redistribués équitablement. Transparence totale — les rapports financiers, les logs de génération et la liste des providers sont publics et accessibles sans compte.

Ce n'est pas une coopérative juridique. C'est un logiciel open source avec une économie intégrée. La différence : les règles sont dans le code, pas dans un contrat que personne ne lit.

Ce que je vous demande

1. Challengez le système.

Le proof-of-work audio est une idée jeune. Il y a probablement des angles d'attaque que je n'ai pas vus. Si vous êtes chercheur en sécurité, musicien qui code, dev qui s'ennuie un vendredi soir — je veux savoir comment vous casseriez ça.

→ Serveur central

→ Provider node

2. Rejoignez le réseau.

Si vous avez un GPU qui dort la nuit, vous pouvez le brancher. Vous êtes rémunéré à part égale avec les autres providers. Tout est vérifié, rien n'est opaque.

→ Voir les données publiques du réseau

→ Me contacter

3. Partagez si le concept vous parle.

Pas pour la croissance — pour trouver les bonnes personnes. Ceux qui construisent des alternatives, qui pensent que l'infrastructure musicale ne devrait pas appartenir à trois entreprises américaines.

La stack technique (pour les curieux)

Composant	Technologie
Plugin	VST3 / AU (C++)
Serveur central	FastAPI (Python)
Empreintes audio	librosa — mel spectrogram 128 bins
Comparaison	scipy — similarité cosinus
Chiffrement samples	cryptography — Fernet
Base de données	PostgreSQL + SQLAlchemy
Provider kit	Python + httpx
Fallback inférence	fal.ai