ncantu 46bf9676a0 Install and enable all missing systemd services
**Motivations:**
- Ensure all application directories have systemd services enabled at boot
- Complete service installation for api-relay, filigrane-api, and clamav-api
- Fix dependencies and import issues preventing clamav-api from starting

**Root causes:**
- Three services (api-relay, filigrane-api, clamav-api) had service files but were not installed in systemd
- api-clamav had incorrect node-clamav version (0.12.1) that doesn't exist
- api-clamav dependencies were not installed (node_modules missing)
- ES module import syntax incompatible with CommonJS node-clamav package

**Correctifs:**
- Installed api-relay.service, filigrane-api.service, and clamav-api.service in /etc/systemd/system/
- Enabled all three services for automatic startup at boot
- Updated api-clamav/package.json: changed node-clamav version from ^0.12.1 to ^1.0.11
- Installed npm dependencies for api-clamav
- Fixed ES module import in api-clamav/src/routes/scan.js to use CommonJS-compatible syntax

**Evolutions:**
- All 7 application services now have systemd services enabled at boot
- Complete service coverage: anchorage-api, faucet-api, signet-dashboard, userwallet, api-relay, filigrane-api, clamav-api
- All services verified active and listening on their respective ports

**Pages affectées:**
- api-clamav/package.json
- api-clamav/src/routes/scan.js
- api-clamav/node_modules/ (new)
- api-clamav/package-lock.json (new)
- /etc/systemd/system/api-relay.service (new)
- /etc/systemd/system/filigrane-api.service (new)
- /etc/systemd/system/clamav-api.service (new)
2026-01-26 12:56:11 +01:00
..

UserWallet API Relay

Serveur de relais pour le système de login décentralisé UserWallet.

Fonctionnalités

  • Stockage des messages chiffrés (sans signatures ni clés)
  • Stockage séparé des signatures
  • Stockage séparé des clés de déchiffrement
  • Relais entre pairs (inter-relay)
  • Déduplication par hash
  • Endpoints REST pour GET/POST
  • Rate limiting (par IP)
  • CORS configurable
  • Logging structuré (Pino)
  • Métriques Prometheus (GET /metrics)
  • Compression des réponses (gzip)
  • Indexation par service_uuid pour GET /messages
  • Bloom filter des hash vus (GET /bloom)

Installation

npm install

Configuration

Variables d'environnement :

  • PORT : Port d'écoute (défaut: 3019)
  • HOST : Adresse d'écoute (défaut: 0.0.0.0)
  • STORAGE_PATH : Chemin de stockage (défaut: ./data)
  • PEER_RELAYS : Liste de relais pairs séparés par virgule (ex: http://relay1:3019,http://relay2:3019)
  • SAVE_INTERVAL_SECONDS : Sauvegarde périodique (défaut: 300, 0 = désactivé)
  • BODY_LIMIT : Taille max body JSON (défaut: 1mb)
  • REQUEST_TIMEOUT_MS : Timeout requête HTTP (défaut: 30000)
  • RATE_LIMIT_WINDOW_MS : Fenêtre rate limit (défaut: 60000)
  • RATE_LIMIT_MAX : Requêtes max par fenêtre et par IP (défaut: 200)
  • CORS_ORIGINS : Origines CORS autorisées, séparées par virgule (vide = toutes)
  • LOG_LEVEL : Niveau log Pino (défaut: info, debug en dev)
  • NODE_ENV : production | autre

Développement

npm run dev

Build

npm run build
npm start

Déploiement (systemd)

sudo cp api-relay.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable api-relay
sudo systemctl start api-relay

start.sh build puis lance node dist/index.js.

Endpoints

Health

  • GET /health - Vérification de santé

Messages

  • GET /messages?start=<timestamp>&end=<timestamp>&service=<uuid> - Récupérer les messages dans une fenêtre temporelle
  • POST /messages - Publier un message chiffré
  • GET /messages/:hash - Récupérer un message par hash

Signatures

  • GET /signatures/:hash - Récupérer les signatures pour un message
  • POST /signatures - Publier une signature

Clés

  • GET /keys/:hash - Récupérer les clés de déchiffrement pour un message
  • POST /keys - Publier une clé de déchiffrement

Métriques

  • GET /metrics - Métriques Prometheus (relay_storage_entries par kind)

Bloom

  • GET /bloom - Bloom filter (JSON) des hash vus. Les clients peuvent lutiliser pour éviter de demander des messages déjà connus.

Architecture

Le relais respecte la séparation stricte :

  1. Messages publiés sans signatures ni clés
  2. Signatures publiées séparément
  3. Clés publiées séparément

La déduplication par hash évite de relayer deux fois le même message.

Stockage

Stockage en mémoire avec persistance sur disque ({STORAGE_PATH}/messages.json). Sont persistés : messages, seenHashes, signatures, clés. Sauvegarde à larrêt (SIGINT/SIGTERM) et périodiquement si SAVE_INTERVAL_SECONDS > 0. En production, une base de données (SQLite, PostgreSQL, etc.) est recommandée.