151 lines
5.9 KiB
Markdown
151 lines
5.9 KiB
Markdown
# Analyse : Note non synchronisée
|
|
|
|
## Note concernée
|
|
|
|
- **ID** : `527d83e0af20bf23c3e104974090ccc21536ece72c24eb784b3642890f63b763`
|
|
- **Pubkey** : `3c1f1844a9e9df8caa71c6f6f16f3190337c1d57d7da58180f8f33206e2d7d11`
|
|
- **Created_at** : `1767681622` (6 janvier 2026)
|
|
- **Kind** : `1`
|
|
- **Tag service** : `["service", "zapwall.fr"]`
|
|
|
|
## Filtre utilisé
|
|
|
|
Le système envoie aux relais le filtre suivant :
|
|
|
|
```json
|
|
{
|
|
"kinds": [1],
|
|
"#service": ["zapwall.fr"],
|
|
"since": 1767571200,
|
|
"limit": 1000
|
|
}
|
|
```
|
|
|
|
- `kinds: [1]` : Notes (kind 1)
|
|
- `#service: ["zapwall.fr"]` : Tag `service` avec valeur `zapwall.fr`
|
|
- `since: 1767571200` : À partir du 5 janvier 2026 00:00:00 UTC
|
|
- `limit: 1000` : Maximum 1000 événements par relai
|
|
|
|
## Vérification de correspondance
|
|
|
|
La note **devrait** correspondre au filtre :
|
|
|
|
- ✅ **Kind** : La note est de kind `1`, correspond au filtre `kinds: [1]`
|
|
- ✅ **Tag service** : La note a le tag `["service", "zapwall.fr"]`, correspond au filtre `#service: ["zapwall.fr"]`
|
|
- ✅ **Date** : `created_at: 1767681622` (6 jan 2026) > `since: 1767571200` (5 jan 2026)
|
|
|
|
## Constat des logs
|
|
|
|
D'après les logs de synchronisation :
|
|
|
|
- **Aucun événement reçu** : Tous les relais retournent `received 0 total events, 0 with service='zapwall.fr'`
|
|
- **EOSE immédiat** : La plupart des relais envoient un signal EOSE (End of Stored Events) immédiatement après la connexion
|
|
- **Timeouts** : Certains relais timeout après 60 secondes sans retourner d'événements
|
|
|
|
## Causes possibles
|
|
|
|
### 1. Propagation limitée sur les relais
|
|
|
|
**Problème** : La note n'est peut-être pas propagée sur les relais utilisés par l'application.
|
|
|
|
**Solution** : Vérifier manuellement si la note est présente sur les relais :
|
|
- Utiliser un client Nostr (Amethyst, Damus, etc.)
|
|
- Interroger directement les relais avec le même filtre
|
|
- Vérifier si la note est visible sur d'autres plateformes
|
|
|
|
### 2. Support limité du filtre `#service`
|
|
|
|
**Problème** : Certains relais peuvent ne pas supporter correctement le filtre `#service` ou l'interpréter différemment.
|
|
|
|
**Solution** : Tester le filtre sur différents relais et vérifier si certains retournent des résultats.
|
|
|
|
### 3. Limitations des relais
|
|
|
|
**Problème** : Les relais peuvent avoir des limitations :
|
|
- Limite de temps pour les requêtes
|
|
- Limite de résultats même avec `limit: 1000`
|
|
- Indexation incomplète des tags
|
|
|
|
**Solution** : Réduire la fenêtre temporelle ou diviser les requêtes par période.
|
|
|
|
### 4. Timing de publication
|
|
|
|
**Problème** : Si la note a été publiée récemment, elle peut ne pas encore être indexée par tous les relais.
|
|
|
|
**Solution** : Attendre quelques minutes/hours et relancer la synchronisation.
|
|
|
|
### 5. Filtre trop restrictif
|
|
|
|
**Problème** : Le filtre `#service` peut être trop restrictif. Certains relais peuvent ne pas indexer ce tag correctement.
|
|
|
|
**Solution** : Envisager une approche alternative :
|
|
- Ne pas filtrer par `#service` dans la requête aux relais
|
|
- Filtrer côté client après réception des événements
|
|
- Utiliser un filtre par `pubkey` si la note provient d'un auteur connu
|
|
|
|
## Recommandations
|
|
|
|
### Court terme
|
|
|
|
1. **Vérifier la propagation** : Tester manuellement si la note est présente sur les relais principaux (relay.damus.io, relay.nostr.band, etc.)
|
|
2. **Augmenter les logs** : Ajouter plus de logs pour voir les événements reçus avant filtrage
|
|
3. **Tester sans filtre service** : Essayer une requête sans le filtre `#service` pour voir si des événements sont retournés
|
|
|
|
### Moyen terme
|
|
|
|
1. **Approche hybride** : Ne pas filtrer par `#service` côté relais, filtrer après réception
|
|
2. **Relais spécialisés** : Utiliser des relais spécialisés pour zapwall.fr si disponibles
|
|
3. **Indexation locale** : Mettre en place un cache/IndexedDB pour les événements déjà reçus
|
|
|
|
### Long terme
|
|
|
|
1. **Relai dédié** : Opérer un relai Nostr dédié pour la plateforme
|
|
2. **Propagation garantie** : S'assurer que toutes les notes publiées sont propagées sur plusieurs relais
|
|
|
|
## Code de debug
|
|
|
|
Pour tester manuellement si la note est présente sur un relai :
|
|
|
|
```javascript
|
|
// Tester avec un client Nostr
|
|
const filter = {
|
|
ids: ['527d83e0af20bf23c3e104974090ccc21536ece72c24eb784b3642890f63b763']
|
|
}
|
|
|
|
// Ou avec le filtre service
|
|
const filterService = {
|
|
kinds: [1],
|
|
'#service': ['zapwall.fr'],
|
|
since: 1767571200,
|
|
limit: 1000
|
|
}
|
|
```
|
|
|
|
## Solution appliquée
|
|
|
|
### Problème identifié
|
|
|
|
Le filtre `#service` n'est pas correctement supporté par certains relais (notamment relay.damus.io). Même si la note est présente sur le relai et correspond au filtre, le relai ne la retourne pas quand on filtre par `#service`.
|
|
|
|
### Correction
|
|
|
|
Modification de `lib/platformSync.ts` pour :
|
|
1. **Ne plus filtrer par `#service` côté relai** : Le filtre envoyé aux relais ne contient plus `"#service": ["zapwall.fr"]`
|
|
2. **Récupérer tous les kind 1** depuis `MIN_EVENT_DATE` avec le filtre `{ kinds: [1], since: 1767571200, limit: 1000 }`
|
|
3. **Filtrer côté client** : Après réception des événements, filtrer ceux qui ont `service='zapwall.fr'` avant de les traiter
|
|
|
|
Cette approche permet de :
|
|
- Récupérer la note même si le relai ne supporte pas bien le filtre `#service`
|
|
- Voir tous les événements reçus dans les logs pour debug
|
|
- Maintenir la même logique de filtrage, mais appliquée après réception
|
|
|
|
### Impact
|
|
|
|
- **Plus d'événements reçus** : Les relais retourneront plus d'événements (tous les kind 1 depuis la date)
|
|
- **Traitement côté client** : Le filtrage se fait maintenant dans le code JavaScript, ce qui est plus fiable
|
|
- **Meilleure visibilité** : Les logs montreront tous les événements reçus, permettant de confirmer si la note est bien présente
|
|
|
|
## Conclusion
|
|
|
|
Le problème était lié au support limité du filtre `#service` par certains relais. En ne filtrant plus côté relai et en filtrant après réception, la note devrait maintenant être correctement récupérée si elle est présente sur les relais utilisés.
|