1. Identité de cet appareil
L’identité cryptographique reste indépendante du réseau. Les clés privées sont locales et non extractibles.
Tu peux reprendre le nom visible dans Réglages → Général → Informations → Nom.
2. Appairage et confiance
3. Sceller un message
4. Ouvrir une enveloppe
Le contenu vérifié s’affichera ici.
Les effets réels exigent un adaptateur externe explicitement autorisé et idempotent. Le cœur SpiderLink reste indépendant de toute application métier.
5. PathFinder + Seamless Handover
SpiderLink maintient maintenant une session logique indépendante du Direct Link. Si WebRTC tombe, SpiderRelay garde la continuité et le Direct Link se reconstruit automatiquement dès que les deux appareils peuvent l’accepter.
6. SpiderRelay · secours Internet chiffré
Le relais transporte uniquement des enveloppes déjà chiffrées de bout en bout. Il ne possède aucune clé privée et ne devient jamais une autorité de confiance.
Le relais nécessite le binding Cloudflare D1 SPIDERLINK_DB. Sans lui, SpiderLink continue de fonctionner en Direct Link et en modes manuels.
7. Direct Link WebRTC
Chemin direct prioritaire et auto-réparé. Sa fermeture ne coupe plus SpiderLink : SpiderRelay assure la continuité, puis AutoLink reconstruit WebRTC automatiquement au retour au premier plan.
8. Continuité Safari ↔ PWA
SpiderLink ne copie jamais silencieusement une clé privée entre deux stockages isolés. La continuité passe par un certificat signé et un code humain.
9. Mode Test guidé intégré
Les consignes restent dans SpiderLink pour éviter de mettre la PWA en arrière-plan pendant les tests iOS. Le mode test demande aussi un Wake Lock quand iOS le permet afin d’éviter l’extinction de l’écran.
10. Action Engine · ActionID durable
Les commandes authentifiées possèdent un ActionID persistant distinct de l’EnvelopeID. Deux enveloppes différentes portant la même ActionID sont dédupliquées par le registre durable. Les états ambigus bloquent toute répétition automatique.
Pour un effet matériel réel, SpiderLink exigera un adaptateur idempotent capable de confirmer ou de réconcilier son effet. La PWA seule ne prétend pas rendre un matériel arbitraire transactionnel.
11. Universal Core · 35 usages + 12 fondations
Une seule application SpiderLink expose désormais le moteur universel : messagerie, autorisation, appareils, IoT, IT, domotique, automatisation, machines, fichiers, dead drops et API tierces. Les capacités physiques restent bloquées tant qu’un adaptateur explicitement autorisé n’est pas installé.
35 familles d’usage
12 fondations SpiderLink
12. Universal Network Lab · Mesh, approbations, dead drop, fichiers
Ces outils restent dans la même application mais sont clairement marqués laboratoire lorsqu’ils ne sont pas encore validés sur matériel physique.
13. Audit horodaté et traçabilité
Chaque événement enregistré possède désormais une date ISO, l’heure locale, un numéro de séquence d’audit et un hash lié au précédent. Les horodatages locaux ne prétendent pas être une autorité de temps externe, mais toute altération ultérieure du journal chaîné est détectable.
14. Validation consolidée · un seul bouton
Cette batterie enchaîne les deux grands blocs génériques de la release : Control Plane et Universal 47. Elle ne remplace pas le test physique entre deux appareils, mais évite une succession de micro-tests.
Statut de cette release
SpiderLink Unified Core v4.1.1-RC1 réunit le socle de transport éprouvé et les fonctions Universal Core sans dépendance à une application métier. Les fonctions qui agissent sur du matériel critique restent en mode contrat ou simulation jusqu’à l’installation d’un adaptateur spécifique audité. SpiderMesh est intégré au Network Lab mais n’est pas encore validé physiquement en multi-hop. TURN reste désactivé par défaut.