Un problème concret, une solution technique

À l'origine de Current se trouve une difficulté pratique : au sein d'un collectif de DJ, l'échange de fichiers vidéo volumineux – enregistrements de sets, contenus promotionnels – est une opération quotidienne. Les solutions existantes, comme la copie physique via câble USB-C ou le recours au stockage cloud payant, sont perçues comme lentes, coûteuses ou peu adaptées aux besoins du groupe, d'autant que les fichiers sont souvent capturés sur des appareils qui ne sont pas la propriété de la personne qui les édite. Même la messagerie instantanée compresse les vidéos de manière agressive, rendant le partage pour relecture insatisfaisant.

L'auteur du projet avait connaissance de sendme, un outil en ligne de commande reposant sur le protocole iroh-blobs et développé par l'équipe de n0-computer. sendme permet d'envoyer un fichier d'un ordinateur à un autre, sans configuration complexe. Mais son interface en terminal le rend inaccessible aux non-initiés, et il ne fonctionne pas sur un téléphone, alors que de nombreux fichiers sont produits depuis un appareil mobile.

Architecture logicielle multicouche

Current se présente comme une interface web et native pour le protocole iroh-blobs, celui-là même qui alimente sendme. Le projet comporte plusieurs composants :

  • current_core : une crate Rust qui encapsule iroh-blobs, suit l'état des transferts et expose des liaisons FFI (Foreign Function Interface).
  • @current/core : un paquet Bun qui enrobe current_core après sa compilation en WebAssembly.
  • @current/web : un site web construit avec TanStack Start qui utilise @current/core pour effectuer les transferts.
  • Current-macOS et Current-iOS : une interface Swift UI multiplateforme construite au-dessus de current_core, dont la sortie est annoncée comme imminente.

Les défis techniques relevés

Le développement de current_core a posé plusieurs problèmes techniques, dont le plus notable est la gestion d'une interface FFI complexe, devant fonctionner à la fois sur l'architecture aarch64 et sur WebAssembly. L'interface doit notamment permettre un suivi détaillé de la progression des transferts – pour que l'utilisateur sache si le transfert fonctionne et combien de temps il reste – ainsi que l'annulation des transferts en cours.

Pour unifier l'API FFI entre ces cibles, le développeur a choisi d'utiliser BoltFFI, une bibliothèque qui promet de meilleures performances que wasm-bindgen et, surtout, de réduire la charge de maintenance en évitant de maintenir deux API FFI distinctes avec leurs liaisons respectives en TypeScript et Swift. L'API obtenue expose des structures comme Sender, Receiver et Endpoint, ainsi que des traits tels que TransferCallbacks et SenderCallbacks qui doivent être implémentés dans le code hôte (Swift, TypeScript).

L'API publiée dans le billet de blog montre une gestion asynchrone poussée : les méthodes publish_paths (réservée aux cibles non-WASM) et publish_streams (utilisable côté WASM via une source de flux) permettent de publier des fichiers ou des flux et de générer un ticket que le destinataire utilise pour lancer la réception. La fonction receive existe en deux versions : l'une, pour le code natif, écrit le fichier sur le disque ; l'autre, pour WebAssembly, remet un handle de transfert au code appelant.

Un développement assisté mais non « vibe-codé »

Le billet précise que des outils d'intelligence artificielle générative ont été utilisés pour la réalisation du logiciel, mais que le texte de l'article – un retour d'expérience technique – a été rédigé sans LLM. L'auteur oppose cette approche au « vibe-coding », terme désignant une pratique où le code est essentiellement généré par IA sans compréhension humaine.

Annoncé comme le premier d'une série, cet article détaille l'architecture générale et les premiers choix techniques. Les prochains billets devraient approfondir des aspects spécifiques, comme la gestion des appels de fonction asynchrones entre Rust et les langages hôtes.

Un outil en devenir

Pour l'heure, la version web de Current est accessible et permet d'envoyer des fichiers de n'importe quelle taille entre navigateurs. Les applications macOS et iOS, construites en Swift UI autour du même noyau Rust, sont présentées comme étant « très bientôt » disponibles. L'objectif final est de proposer une alternative légère, gratuite et sans serveur centralisé aux services de cloud classiques, en s'appuyant sur la pile technique Rust/WebAssembly et le protocole pair-à-pair iroh-blobs.