story-research-zapwall/docs/platform-sync-issue-analysis.md

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 :

{
  "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 :

// 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.