Pourquoi nous avons ouvert le code des applications District AI, et ce que vous pouvez en faire

Lorsque vous installez notre application, vous lui confiez votre microphone, votre caméra et vos notifications, et vous la connectez à votre espace de travail, avec chacun de ses appels et chacune de ses transcriptions. Jusqu'ici, vous deviez nous croire sur parole quant à ce qu'elle en fait. Ce n'est plus nécessaire : le code source des applications District AI pour iPhone, iPad, Android et Linux est public, sous licence Apache 2.0, dans les trois dépôts mêmes à partir desquels nous compilons et livrons les applications.

Pourquoi nous avons publié les applications

Les applications sont la seule partie de District AI qui fonctionne sur un appareil qui vous appartient. Tout le reste tourne sur nos serveurs, et pour ceux-ci, nous publions ce dont un client a besoin pour nous vérifier : l'endroit où chaque type de données est conservé et chaque entreprise externe qui nous aide à les traiter. La même règle vaut pour les applications et, pour un logiciel installé sur votre téléphone ou votre ordinateur, la réponse la plus directe est le code lui-même.

Les promesses de la politique de sécurité de chaque application deviennent donc des choses que vous pouvez lire plutôt que de devoir nous croire sur parole :

• L'application Android ne demande aucune autorisation d'accès aux textos, aux contacts, au journal d'appels ni à la localisation, et ses notifications ne contiennent que des identifiants, jamais le contenu d'un message ni un numéro de téléphone.
• L'application iOS ne garde sa connexion que dans le trousseau (Keychain) de l'appareil, d'où une sauvegarde ne peut pas l'emporter vers un autre appareil.
• L'application Linux se connecte par votre propre navigateur et ne voit jamais votre mot de passe. Elle garde sa connexion dans le trousseau du bureau, jamais dans un fichier ordinaire, et en Flatpak, elle demande le réseau, l'affichage, le processeur graphique, le son et les avis de mise en veille du système, et rien d'autre.
• Une version compilée à partir du dépôt iOS ou Android ne signale aucun plantage, à moins que quelqu'un ne fournisse les réglages nécessaires au moment de la compilation. L'application Linux ne contient aucun signalement des plantages.

Compilées et publiées à découvert

Ce sont les dépôts à partir desquels nous livrons, avec leurs tickets, leurs journaux des modifications et leurs politiques de sécurité à découvert. Chaque application est désormais compilée et publiée par un flux de travail GitHub Actions de son propre dépôt, lancé par une étiquette de version protégée, et une étiquette qui ne se trouve pas sur la branche principale ou qui ne correspond pas à la version de l'application est refusée. Les versions iOS et Android y sont signées avec des clés que le flux de travail emprunte à notre compte Google Cloud le temps d'une exécution : aucune clé de signature ni aucun identifiant de boutique n'est donc conservé dans les dépôts ni sur GitHub, et seul l'environnement de publication de ce dépôt peut les demander. L'envoi d'une version à l'examen d'Apple ou de Google Play attend toujours notre approbation explicite. Chaque paquet Linux porte une attestation signée de la compilation qui l'a produit, que vous pouvez vérifier avec l'outil en ligne de commande de GitHub.

Les versions offertes aujourd'hui dans les boutiques ont été compilées à partir des mêmes dépôts avant l'arrivée de ces flux de travail, sur le poste d'un responsable, et la version publiée de chaque dépôt nomme le commit dont provient sa version en boutique : la compilation 4102 de l'App Store pour iOS 1.2, et la version 1.0 offerte sur Google Play pour Android.

Ce qui est à code source ouvert, et ce qui ne l'est pas

Les trois applications sont publiées sous licence Apache 2.0. Vous pouvez les lire, les compiler, les modifier et nous renvoyer vos modifications. Les noms, les logos et les icônes d'application District AI et Distronode sont des marques de commerce et ne font pas partie de cette licence : une application que vous compilez et distribuez porte donc son propre nom, sa propre icône et son propre identifiant.

Le service District AI avec lequel les applications communiquent n'est pas à code source ouvert. Tout ce que les applications affichent vient de ce service : une version compilée à partir du code source a donc toujours besoin d'un compte District AI pour se connecter. Les applications ne sont pas pour autant de simples exemples : chaque dépôt est le code source complet de son application, celui-là même dont sont faits les versions des boutiques et les paquets.

Précisons enfin que les trois applications sont en anglais, tout comme leurs dépôts.

Sans compte chez nous

Aujourd'hui, chacune de ces applications a besoin d'un compte District AI pour se connecter, parce que c'est le service qui répond aux appels et qui conserve les transcriptions, les messages et les contacts que les applications affichent. Nous voulons que les applications fonctionnent aussi sans compte chez nous.

Nous n'avons pas encore établi à quoi cela ressemblerait, ni si c'est faisable. Il pourrait s'agir de relier une application à un serveur que vous exploitez vous-même, ou à des services que vous utilisez déjà, et certaines de ces pistes pourraient ne pas fonctionner du tout. Ce à quoi les applications devraient se relier est une question pour les gens qui les utiliseraient ainsi : nous la posons donc avant de construire quoi que ce soit. Si c'est votre cas, dites-le-nous dans la discussion : quelle application vous utiliseriez, à quoi vous la relieriez et pour quoi faire. La discussion est en anglais, mais vous pouvez y écrire en français.

Ce que contiennent les trois dépôts

District AI pour iOS est une seule application universelle SwiftUI pour iPhone et iPad. L'essentiel de sa logique se trouve dans un paquet central, DistrictCore (les modèles, le client de l'API, et les machines à états de la connexion et des appels), qui se compile et se teste sous Linux aussi bien que sur un Mac. Des tests d'interface couvrent les écrans hors connexion, et aucun certificat ni profil de provisionnement n'est versé au dépôt.

District AI pour Android est écrite en Kotlin et Jetpack Compose. C'est un téléphone logiciel autogéré qui passe et reçoit des appels par le cadre de téléphonie d'Android (Telecom), et le dépôt ne contient aucune clé de signature, aucun identifiant de boutique ni aucun jeton de signalement des plantages.

District AI pour Linux est écrite en Rust, en plusieurs modules (des crates), avec l'application GTK 4 et libadwaita au sommet. Rien sous l'application ne dépend de GTK : le client de l'API, la connexion et l'état de l'application se compilent et se testent donc sur une machine sans affichage. Les appels utilisent LiveKit et la propre compilation, par le projet, de la bibliothèque libwebrtc de LiveKit, qui exclut les codecs H.264 et H.265 ainsi que FFmpeg, et l'intégration continue les teste contre son propre serveur média : audio dans les deux sens, chiffrement de bout en bout et reconnexion.

Les mêmes réponses de référence, dans les trois. Chaque dépôt contient des réponses de référence : des réponses enregistrées à partir du service District AI par la suite de tests du service lui-même, avec des données fictives. Les tests de chaque application les décodent de façon stricte : un champ que le service envoie et que l'application ne modélise pas fait donc échouer ses tests au lieu de passer inaperçu. Cette rigueur ne vaut que pour les tests : une application installée continue de fonctionner quand le service ajoute un champ. L'application Linux contient l'ensemble de l'application Android et un ensemble propre au bureau, avec une somme de contrôle pour chaque fichier.

La politique de sécurité de l'application Android répond aussi à la première question que soulève un outil de détection de secrets. Deux types de valeurs du dépôt ressemblent à des identifiants confidentiels : la configuration client Firebase que toute application Firebase intègre à son paquet d'installation, et des clés de chiffrement de bout en bout dans trois réponses de référence, produites par la suite de tests du service à partir d'entrées fixes, qui ne protègent aucune salle. La politique énumère chacune d'elles et explique pourquoi elle s'y trouve, et l'analyse de secrets du dépôt n'accepte que ces valeurs précises : une vraie clé ajoutée à côté est donc toujours signalée.

Ce que vous pouvez en faire

Compiler et tester, sans compte. Pour iOS, swift test dans Packages/DistrictCore exécute les tests du paquet central sans simulateur, sans réseau et sans compte, et xcodebuild compile l'application pour le simulateur, signature désactivée. Pour Android, ./gradlew assembleDebug produit une version de débogage et ./gradlew testDebugUnitTest exécute les tests unitaires de chaque module. Pour Linux, cargo build --release --locked compile l'application, et cargo test --workspace --exclude district-app exécute les tests de tout ce qui se trouve sous l'interface. Chaque README donne les commandes exactes et ce qu'il faut installer d'abord.

Un client bien à vous. Vous pouvez modifier une application et livrer votre propre version en respectant les règles des forks : votre propre nom, votre propre icône et votre propre identifiant et, sur iOS, votre propre équipe de signature. Les notifications poussées ne suivent pas : sur iOS, elles sont liées à l'équipe de la version de l'App Store, et un fork Android qui envoie des notifications poussées a besoin de son propre projet Firebase. Une version Linux compilée à partir du code source n'a pas d'appels tant que vous ne la compilez pas avec eux, ce qui exige clang 21 ou plus récent, comme l'indique son fichier CONTRIBUTING.md. La connexion exige toujours un compte District AI.

L'API, telle qu'elle répond vraiment. Les réponses de référence sont le témoignage le plus direct de la façon dont l'API de District AI répond : des corps de réponse produits par la suite de tests du service à partir de ses véritables gestionnaires de routes, avec des données fictives.

Des pièces pour votre propre application d'appels. La licence Apache 2.0 vous permet de reprendre du code dans votre propre projet, pourvu que la licence et ses avis l'accompagnent. L'application Android garde sa couche LiveKit derrière une interface CallEngine, dans un module distinct. L'application iOS regroupe son code CallKit, PushKit et LiveKit dans un seul dossier, Platform. L'application Linux a son moteur d'appels dans une crate distincte, district-call, et sa connexion OAuth 2.0 avec PKCE dans une autre, district-auth.

Où trouver les applications

L'application iOS, pour iPhone et iPad, se trouve sur l'App Store, et l'application Android sur Google Play. L'application Linux se trouve sur la page Releases du dépôt district-linux, en paquet .deb pour Ubuntu 24.04, Debian 13 et versions ultérieures, et en paquet Flatpak pour toute distribution qui prend en charge Flatpak, tous deux pour x86_64.

Où poser une question, contribuer et signaler

Les contributions se font sur GitHub, à district-ios, district-android et district-linux. Les questions vont dans l'onglet Discussions de chaque dépôt, les bogues dans ses tickets et les modifications dans des demandes de fusion, et le fichier CONTRIBUTING.md de chaque dépôt indique ce qu'une demande de fusion doit remplir avant d'être examinée. Un problème de sécurité se signale en privé, par le signalement privé de vulnérabilités de GitHub, comme l'indique chaque fichier SECURITY.md, et jamais dans un ticket public.

Chaque application a aussi un miroir en lecture seule sur GitLab, comme bridgewatch, qui offre un deuxième endroit où lire le code : district-ios, district-android et district-linux.

Par où commencer

Chaque application a sa propre page : District AI pour iOS, District AI pour Android et District AI pour Linux. Notre page Code source ouvert présente les cinq projets que nous publions, dont bridgewatch et District Scheduler. Pourquoi nous publions, et pourquoi nous renvoyons nos correctifs aux projets sur lesquels nous bâtissons : c'est l'objet de notre billet précédent.