58 lines
2.4 KiB
Markdown
58 lines
2.4 KiB
Markdown
# Pourquoi publier sur plusieurs relais ne crée pas de doublons
|
|
|
|
## Comment fonctionne l'identité d'un événement Nostr
|
|
|
|
Dans Nostr, chaque événement est **uniquement identifié** par :
|
|
|
|
1. **Son ID** : un hash SHA256 calculé à partir de :
|
|
- `kind` (type d'événement)
|
|
- `created_at` (timestamp)
|
|
- `pubkey` (clé publique de l'auteur)
|
|
- `tags` (tableau de tags)
|
|
- `content` (contenu de l'événement)
|
|
|
|
2. **Sa signature** : signature cryptographique de l'ID par la clé privée de l'auteur
|
|
|
|
## Pourquoi pas de doublons ?
|
|
|
|
### 1. Identité unique
|
|
Le même contenu génère **exactement le même ID**. Si vous publiez le même événement (même contenu, même timestamp, mêmes tags) sur 100 relais, c'est **exactement le même événement** avec le même ID.
|
|
|
|
### 2. Stockage par ID dans les relais
|
|
Les relais stockent les événements dans une base de données indexée par **ID d'événement**. Si un relais reçoit un événement avec un ID qu'il a déjà, il :
|
|
- **Ignore** l'événement (déjà stocké)
|
|
- **Ne crée pas de doublon**
|
|
|
|
### 3. Déduplication automatique
|
|
Quand un utilisateur s'abonne à plusieurs relais :
|
|
- Il peut recevoir le même événement de plusieurs sources
|
|
- Mais c'est **le même événement** (même ID)
|
|
- Les clients Nostr dédupliquent automatiquement basé sur l'ID
|
|
|
|
## Exemple concret
|
|
|
|
```
|
|
Événement publié sur relay1, relay2, relay3 :
|
|
- ID: abc123...
|
|
- Signature: def456...
|
|
- Contenu: "Mon article..."
|
|
```
|
|
|
|
Résultat :
|
|
- **Relay1** stocke : `abc123...` → "Mon article..."
|
|
- **Relay2** stocke : `abc123...` → "Mon article..."
|
|
- **Relay3** stocke : `abc123...` → "Mon article..."
|
|
|
|
C'est **le même événement** stocké 3 fois pour redondance, pas 3 événements différents.
|
|
|
|
## Avantages de publier sur plusieurs relais
|
|
|
|
1. **Redondance** : si un relais tombe, l'événement reste disponible sur les autres
|
|
2. **Performance** : les utilisateurs proches de différents relais obtiennent une latence réduite
|
|
3. **Résilience** : protège contre la censure si un relais supprime l'événement
|
|
4. **Découverte** : augmente les chances que votre contenu soit trouvé
|
|
|
|
## Conclusion
|
|
|
|
**Publier le même événement sur plusieurs relais est la pratique recommandée dans Nostr.** Cela ne crée pas de doublons car les relais utilisent l'ID comme clé unique. C'est similaire à uploader le même fichier sur plusieurs serveurs : c'est le même fichier, pas des copies différentes.
|