# UserWallet – Usage Bloom dans le sync (3.6)

**Author:** Équipe 4NK  
**Date:** 2026-01-26

## Objectif

Utiliser optionnellement `GET /bloom` du relais dans le sync pour éviter des fetches de clés inutiles quand un relais n’a pas vu un hash (pas de faux négatifs).

## Impacts

- **Sync** : au début de chaque sync, fetch du Bloom par relais activé ; stockage dans `bloomByRelay`.
- **fetchKeys** : avant `getKeys(relay, hash)`, si on a un Bloom pour ce relais et `!bloom.has(hash)`, on ignore ce relais pour ce hash (le relais ne l’a pas vu).

## Modifications

- **`utils/bloom.ts`** : `fetchAndLoadBloom(relay)` → fetch `getBloom(relay)`, `BloomFilter.fromJSON`, retourne le filtre ou `null` si erreur (relais sans /bloom, etc.).
- **`services/syncService.ts`** : `fetchBlooms()` remplit `bloomByRelay` ; `sync()` appelle `fetchBlooms()` avant `runSyncLoop` ; `fetchKeys(hash)` saute `getKeys` pour un relais dont le Bloom indique l’absence du hash.
- **Dépendance** : `bloom-filters` (userwallet).

## Modalités de déploiement

Déploiement classique du front userwallet. Les relais sans `GET /bloom` sont ignorés pour le Bloom (pas de filtre, pas de skip).

## Modalités d’analyse

- Relais avec `/bloom` : sync fetch les Bloom, puis pour chaque hash on peut skip `getKeys` sur un relais qui ne l’a pas vu.
- Relais sans `/bloom` ou erreur : `fetchAndLoadBloom` retourne `null`, on ne skip jamais pour ce relais.

## Références

- `features/userwallet-contrat-login-reste-a-faire.md` (§ 3.6)
- `utils/relay.ts` (`getBloom`)