Développeurs

Intègre Warren dans ton app

Un moteur en Rust, un SDK pour ton langage, et des vecteurs de test qui garantissent que toutes les implémentations parlent exactement le même protocole. Le tout open source.

Un seul moteur, plusieurs langages

Le protocole n'est implémenté qu'une seule fois, dans le moteur Rust. Chaque SDK embarque ce moteur et l'expose derrière une API naturelle pour son langage. Le SDK TypeScript fait exception : il réimplémente le protocole de son côté, et prouve qu'il reste compatible en rejouant les mêmes vecteurs de test que le moteur.

Rust

Le moteur de référence, celui que les autres SDK embarquent. Il gère l'identité, le tunnel QUIC, le multi-hop et un proxy local sans privilèges (SOCKS5, HTTP CONNECT, DNS dans le tunnel, IPv6, port forwarding). Testé en continu sur de vrais serveurs de sortie.

Dépôt : WarrenBrowse/warren-sdk-rs
Dart / Flutter

Intègre Warren dans une app Flutter, desktop et mobile. Le moteur Rust tourne dans le processus de l'app via flutter_rust_bridge et expose un proxy SOCKS5 local, sans privilèges. Le mode VPN système (TUN) est validé sur macOS ; les autres plateformes suivent.

Dépôt : WarrenBrowse/warren-sdk-dart
TypeScript

L'identité, la signature des requêtes et le dialogue avec l'API, réécrits en TypeScript pur : navigateur, Node, Electron. Les mêmes vecteurs de test garantissent la compatibilité avec le moteur Rust. Sous Node, le trafic du tunnel passe par le moteur natif (napi-rs) ; un navigateur seul ne peut pas ouvrir de tunnel QUIC, le SDK s'y limite donc à l'identité et à l'API.

Dépôt : WarrenBrowse/warren-sdk-ts
Python / Kotlin

Des bindings uniffi générés au-dessus du moteur Rust (crate warren-sdk-ffi) et validés en CI.

Dépôt : WarrenBrowse/warren-sdk-rs

Un protocole figé au bit près

Chaque format d'échange (identité, signatures, liste des serveurs de sortie, scellement multi-hop) est figé dans le dépôt warren-vectors, sous forme d'octets de référence que chaque implémentation doit reproduire exactement. La CI rejoue ces vecteurs en continu : un SDK qui s'écarte du format ne passe plus les tests.

Ce que le SDK sait faire

  • Identité non-custodiale : une phrase BIP39, une clé Ed25519 dérivée sur ton appareil, une adresse SS58 qui commence par wb. La clé privée ne quitte jamais ta machine.
  • Les requêtes API sont signées avec la clé du compte (aucun token à voler), et la liste des serveurs de sortie est vérifiée par signature.
  • Tunnel WarrenGuard complet : QUIC, TLS 1.3 en Raw Public Keys, obfuscation active par défaut.
  • Multi-hop scellé : le relais fait transiter le trafic sans pouvoir le lire (HPKE).
  • Proxy local sans privilèges : SOCKS5, HTTP CONNECT, DNS résolu dans le tunnel, IPv6.
  • Port forwarding : le SDK demande et libère des ports publics sur un serveur de sortie.

Licences et dépôts

Le moteur et les SDK sont publiés sous AGPL-3.0, l'application sous GPL-3.0. Les mêmes vecteurs de test valident n'importe quelle implémentation tierce.