From 9ea4965c05be1bacff734db2bc07e4ca92056375 Mon Sep 17 00:00:00 2001 From: Nicolas Cantu Date: Sat, 27 Dec 2025 21:29:57 +0100 Subject: [PATCH] docs: Fusion et simplification documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Fusion tous documents commissions en technical.md - Suppression documents redondants : - architecture.md, commissions.md, commission-system.md - commission-implementation.md, split-and-transfer.md - implementation-summary.md, content-delivery-verification.md - Documentation fidèle au code actuel - remaining-tasks.md mis à jour avec état réel - Documentation centralisée et sans répétitions --- .../STRICT_CONFIG_SUMMARY.md | 0 docs/architecture.md | 68 ------- docs/commission-implementation.md | 148 -------------- docs/commission-system.md | 119 ----------- docs/commissions.md | 42 ---- docs/content-delivery-verification.md | 142 ------------- docs/implementation-summary.md | 132 ------------ docs/remaining-tasks.md | 186 ++--------------- docs/split-and-transfer.md | 191 ------------------ docs/technical.md | 92 +++++++++ fixKnowledge/2025-12-22-lint-type-fixes.md | 20 -- .../2025-12-23-optional-props-lint-types.md | 27 --- lib/platformTracking.ts | 4 +- 13 files changed, 109 insertions(+), 1062 deletions(-) rename STRICT_CONFIG_SUMMARY.md => docs/STRICT_CONFIG_SUMMARY.md (100%) delete mode 100644 docs/architecture.md delete mode 100644 docs/commission-implementation.md delete mode 100644 docs/commission-system.md delete mode 100644 docs/commissions.md delete mode 100644 docs/content-delivery-verification.md delete mode 100644 docs/implementation-summary.md delete mode 100644 docs/split-and-transfer.md create mode 100644 docs/technical.md delete mode 100644 fixKnowledge/2025-12-22-lint-type-fixes.md delete mode 100644 fixKnowledge/2025-12-23-optional-props-lint-types.md diff --git a/STRICT_CONFIG_SUMMARY.md b/docs/STRICT_CONFIG_SUMMARY.md similarity index 100% rename from STRICT_CONFIG_SUMMARY.md rename to docs/STRICT_CONFIG_SUMMARY.md diff --git a/docs/architecture.md b/docs/architecture.md deleted file mode 100644 index e32d504..0000000 --- a/docs/architecture.md +++ /dev/null @@ -1,68 +0,0 @@ -# Architecture technique - -**Auteur** : Équipe 4NK - -## Vue d'ensemble - -Zapwall est une plateforme décentralisée basée sur le protocole Nostr pour la publication et la monétisation de contenu. Le système utilise Lightning Network pour les paiements et Bitcoin mainnet pour le sponsoring. - -## Services principaux - -### Nostr (`lib/nostr.ts`) -- Gestion du pool de connexions aux relays -- Publication et récupération d'événements -- Gestion des profils utilisateurs -- Création de zap requests - -### Paiements (`lib/payment.ts`, `lib/paymentPolling.ts`) -- Création d'invoices Lightning via Alby/WebLN -- Vérification des paiements via zap receipts (NIP-57) -- Polling pour confirmation des paiements -- Envoi automatique du contenu privé après paiement - -### Commissions (`lib/platformCommissions.ts`) -- Configuration centralisée des commissions -- Calcul des splits (auteur/plateforme) -- Validation des montants - -### Tracking (`lib/platformTracking.ts`, `lib/sponsoringTracking.ts`) -- Publication d'événements de tracking sur Nostr -- Suivi des livraisons de contenu -- Suivi des paiements de sponsoring - -### Intégrations externes -- **mempool.space** (`lib/mempoolSpace.ts`) : Vérification des transactions Bitcoin -- **Lightning addresses** (`lib/lightningAddress.ts`) : Récupération depuis profils Nostr - -## Flux de paiement article - -1. Lecteur clique sur "Unlock for 800 sats" -2. Création d'invoice Lightning (via Alby/WebLN) -3. Publication de zap request sur Nostr -4. Lecteur paie l'invoice -5. Polling pour vérifier le zap receipt -6. Envoi automatique du contenu privé (message chiffré NIP-04) -7. Tracking de la livraison avec commissions - -## Flux de sponsoring - -1. Utilisateur demande sponsoring (0.046 BTC) -2. Service calcule split (0.042/0.004 BTC) -3. Retourne deux adresses Bitcoin -4. Utilisateur crée transaction avec deux sorties -5. Vérification via mempool.space -6. Tracking sur Nostr - -## Stockage - -- **IndexedDB** : Contenu privé chiffré (AES-GCM) -- **localStorage** : Métadonnées d'articles, invoices -- **Nostr** : Tous les contenus publics et événements de tracking - -## Sécurité - -- Chiffrement end-to-end pour contenu privé (NIP-04) -- Validation stricte des montants -- Tracking complet sur Nostr pour audit -- Pas de fallback implicite - diff --git a/docs/commission-implementation.md b/docs/commission-implementation.md deleted file mode 100644 index fb2b051..0000000 --- a/docs/commission-implementation.md +++ /dev/null @@ -1,148 +0,0 @@ -# Session d'implémentation du système de commissions - -**Date** : Décembre 2024 -**Auteur** : Équipe 4NK - -## Contexte - -Cette session a été initiée pour répondre à la question : "les commissions de la plateforme sont elles bien implémentées et systématiques/incontournables?" - -## Problème identifié - -Après analyse du code, il a été constaté que les commissions de la plateforme **n'étaient pas implémentées de manière systématique et incontournable** : - -1. **Articles (800 sats)** : L'invoice était créée directement pour l'auteur (800 sats) sans split automatique -2. **Sponsoring (0.046 BTC)** : Pas d'implémentation du split -3. **Avis (70 sats)** : Pas d'implémentation de la rémunération avec split - -## Solution implémentée - -### 1. Configuration centralisée des commissions - -**Fichier créé** : `lib/platformCommissions.ts` - -- Définit toutes les commissions de manière centralisée -- Articles : 800 sats (700 auteur, 100 plateforme) -- Avis : 70 sats (49 lecteur, 21 plateforme) -- Sponsoring : 0.046 BTC (0.042 auteur, 0.004 plateforme) -- Fonctions de calcul et vérification des splits - -### 2. Validation des montants - -**Fichiers modifiés** : -- `lib/articleInvoice.ts` : Vérifie que le montant est 800 sats lors de la création -- `lib/articlePublisher.ts` : Vérifie le montant avant publication -- `lib/payment.ts` : Vérifie le montant avant paiement - -**Garanties** : -- Impossible de publier un article avec un montant incorrect -- Impossible de payer un article avec un montant incorrect -- Erreurs explicites si le montant ne correspond pas - -### 3. Tracking des commissions - -**Fichier modifié** : `lib/platformTracking.ts` - -- Interface `ContentDeliveryTracking` étendue avec `authorAmount` et `platformCommission` -- Tags `author_amount` et `platform_commission` dans les événements Nostr -- Permet à la plateforme de vérifier toutes les commissions via Nostr - -### 4. Logs structurés - -**Fichier modifié** : `lib/paymentPolling.ts` - -- Logs détaillés avec montants de commission -- Vérification que le split est correct -- Alertes si le montant ne correspond pas - -### 5. Configuration de la plateforme - -**Fichier modifié** : `lib/platformConfig.ts` - -- Ajout de `PLATFORM_LIGHTNING_ADDRESS` pour les commissions Lightning - -### 6. Service de split de paiement - -**Fichier créé** : `lib/paymentSplit.ts` - -- Service pour gérer les splits de paiement -- Prêt pour l'implémentation future du split automatique Lightning - -## Garanties d'incontournabilité - -### 1. Validation à la publication -- L'auteur ne peut pas publier avec un montant incorrect -- Le système rejette automatiquement les montants invalides - -### 2. Validation au paiement -- Le lecteur ne peut pas payer un montant incorrect -- Le système vérifie le montant avant d'accepter le paiement - -### 3. Tracking systématique -- Tous les paiements sont enregistrés avec les commissions -- La plateforme peut vérifier tous les paiements via Nostr - -### 4. Logs structurés -- Tous les paiements génèrent des logs avec les commissions -- Facilite l'audit et la vérification - -## Limitations actuelles - -### Split automatique Lightning - -**Problème** : WebLN ne supporte pas BOLT12 avec split automatique. - -**Solution actuelle** : -- L'invoice est créée pour le montant total (800 sats) -- La plateforme reçoit le montant total -- La plateforme doit ensuite transférer la part de l'auteur (700 sats) - -**Solution future** : -- Utiliser un nœud Lightning de la plateforme avec split automatique -- Utiliser un service de split Lightning (LNURL-pay avec split) -- Implémenter un système de transfert automatique après paiement - -### Sponsoring - -**Statut** : À implémenter -- Le sponsoring utilise Bitcoin mainnet -- Nécessite un système de split mainnet -- Plus complexe que Lightning - -### Avis - -**Statut** : À implémenter -- Même problème que les articles (split Lightning) -- Nécessite le même système de split - -## Fichiers créés - -1. `lib/platformCommissions.ts` - Configuration centralisée des commissions -2. `lib/paymentSplit.ts` - Service de split de paiement -3. `features/commission-system.md` - Documentation du système de commissions -4. `features/commission-implementation-session.md` - Cette documentation - -## Fichiers modifiés - -1. `lib/platformConfig.ts` - Ajout de PLATFORM_LIGHTNING_ADDRESS -2. `lib/platformTracking.ts` - Ajout du tracking des commissions -3. `lib/articleInvoice.ts` - Validation du montant à la création -4. `lib/articlePublisher.ts` - Validation du montant avant publication -5. `lib/payment.ts` - Validation du montant avant paiement -6. `lib/paymentPolling.ts` - Logs avec informations de commission - -## Résultat - -Les commissions sont maintenant : -- ✅ **Configurées** de manière centralisée -- ✅ **Validées** à chaque étape (publication, paiement) -- ✅ **Traçables** via Nostr -- ✅ **Loggées** pour audit - -Le split automatique Lightning nécessitera un nœud Lightning de la plateforme ou un service externe, mais les commissions sont garanties et traçables. - -## Questions résolues - -1. ✅ Les commissions sont-elles bien implémentées ? **Oui, maintenant** -2. ✅ Sont-elles systématiques ? **Oui, validées à chaque étape** -3. ✅ Sont-elles incontournables ? **Oui, impossible de contourner les validations** diff --git a/docs/commission-system.md b/docs/commission-system.md deleted file mode 100644 index 51026a3..0000000 --- a/docs/commission-system.md +++ /dev/null @@ -1,119 +0,0 @@ -# Système de commissions - Implémentation - -**Date** : Décembre 2024 -**Auteur** : Équipe 4NK - -## Objectif - -Implémenter un système de commissions systématique et incontournable pour garantir que la plateforme reçoit toujours sa commission sur tous les paiements. - -## Commissions configurées - -### Articles -- **Total** : 800 sats -- **Auteur** : 700 sats -- **Plateforme** : 100 sats - -### Avis (rémunération) -- **Total** : 70 sats -- **Lecteur** : 49 sats -- **Plateforme** : 21 sats - -### Sponsoring -- **Total** : 0.046 BTC (4,600,000 sats) -- **Auteur** : 0.042 BTC (4,200,000 sats) -- **Plateforme** : 0.004 BTC (400,000 sats) - -## Implémentation - -### 1. Configuration centralisée - -**Fichier** : `lib/platformCommissions.ts` - -- Définit toutes les commissions de manière centralisée -- Fonctions de calcul et vérification des splits -- Validation des montants - -### 2. Validation des montants - -**Fichiers modifiés** : -- `lib/articleInvoice.ts` : Vérifie que le montant est 800 sats lors de la création -- `lib/articlePublisher.ts` : Vérifie le montant avant publication -- `lib/payment.ts` : Vérifie le montant avant paiement - -**Garanties** : -- Impossible de publier un article avec un montant incorrect -- Impossible de payer un article avec un montant incorrect -- Erreurs explicites si le montant ne correspond pas - -### 3. Tracking des commissions - -**Fichier** : `lib/platformTracking.ts` - -- Enregistre les commissions dans les événements de tracking -- Tags `author_amount` et `platform_commission` dans les événements Nostr -- Permet à la plateforme de vérifier toutes les commissions - -### 4. Logs et traçabilité - -**Fichier** : `lib/paymentPolling.ts` - -- Logs détaillés avec montants de commission -- Vérification que le split est correct -- Alertes si le montant ne correspond pas - -## Garanties d'incontournabilité - -### 1. Validation à la publication -- L'auteur ne peut pas publier avec un montant incorrect -- Le système rejette automatiquement les montants invalides - -### 2. Validation au paiement -- Le lecteur ne peut pas payer un montant incorrect -- Le système vérifie le montant avant d'accepter le paiement - -### 3. Tracking systématique -- Tous les paiements sont enregistrés avec les commissions -- La plateforme peut vérifier tous les paiements via Nostr - -### 4. Logs structurés -- Tous les paiements génèrent des logs avec les commissions -- Facilite l'audit et la vérification - -## Limitations actuelles - -### Split automatique Lightning - -**Problème** : WebLN ne supporte pas BOLT12 avec split automatique. - -**Solution actuelle** : -- L'invoice est créée pour le montant total (800 sats) -- La plateforme reçoit le montant total -- La plateforme doit ensuite transférer la part de l'auteur (700 sats) - -**Solution future** : -- Utiliser un nœud Lightning de la plateforme avec split automatique -- Utiliser un service de split Lightning (LNURL-pay avec split) -- Implémenter un système de transfert automatique après paiement - -### Sponsoring - -**Statut** : À implémenter -- Le sponsoring utilise Bitcoin mainnet -- Nécessite un système de split mainnet -- Plus complexe que Lightning - -### Avis - -**Statut** : À implémenter -- Même problème que les articles (split Lightning) -- Nécessite le même système de split - -## Prochaines étapes - -1. ✅ Système de commissions configuré -2. ✅ Validation des montants -3. ✅ Tracking des commissions -4. ⏳ Implémenter split automatique Lightning (nécessite nœud Lightning) -5. ⏳ Implémenter split pour sponsoring -6. ⏳ Implémenter split pour avis diff --git a/docs/commissions.md b/docs/commissions.md deleted file mode 100644 index 3d7cf73..0000000 --- a/docs/commissions.md +++ /dev/null @@ -1,42 +0,0 @@ -# Système de commissions - -**Auteur** : Équipe 4NK - -## Configuration - -Les commissions sont centralisées dans `lib/platformCommissions.ts` : - -- **Articles** : 800 sats total (700 auteur, 100 plateforme) -- **Avis** : 70 sats total (49 reviewer, 21 plateforme) -- **Sponsoring** : 0.046 BTC total (0.042 auteur, 0.004 plateforme) - -## Implémentation - -### Articles -- Validation du montant à chaque étape -- Tracking avec `author_amount` et `platform_commission` -- Récupération automatique de l'adresse Lightning de l'auteur -- Transfert automatique déclenché (nécessite nœud Lightning) - -### Sponsoring -- Vérification des transactions Bitcoin via mempool.space -- Validation des sorties (auteur + plateforme) -- Tracking sur Nostr avec confirmations - -### Avis -- Mise à jour de l'événement Nostr avec tags `rewarded` et `reward_amount` -- Récupération automatique de l'adresse Lightning du reviewer -- Transfert automatique déclenché (nécessite nœud Lightning) - -## Tracking - -Tous les paiements sont trackés sur Nostr via des événements personnalisés : -- **Kind 30078** : Livraisons de contenu -- **Kind 30079** : Paiements de sponsoring - -Ces événements permettent un audit complet et une traçabilité totale. - -## Limitations actuelles - -Les transferts Lightning automatiques nécessitent un nœud Lightning de la plateforme. Actuellement, les transferts sont loggés et peuvent être exécutés manuellement. - diff --git a/docs/content-delivery-verification.md b/docs/content-delivery-verification.md deleted file mode 100644 index 6a5e423..0000000 --- a/docs/content-delivery-verification.md +++ /dev/null @@ -1,142 +0,0 @@ -# Vérification de l'envoi du contenu privé - -**Auteur** : Équipe 4NK - -## Objectif - -Garantir que le contenu privé est bien envoyé au destinataire après confirmation du paiement. - -## Système de vérification multi-niveaux - -### 1. Publication sur le relay Nostr - -Lors de l'envoi du contenu privé : -- Le message est chiffré avec NIP-04 (chiffrement entre l'auteur et le destinataire) -- L'événement est publié sur le relay Nostr (kind: 4) -- L'ID de l'événement est retourné pour traçabilité - -**Vérification** : `publishEvent()` retourne l'événement publié avec son ID unique. - -### 2. Vérification sur le relay - -Après publication, le système vérifie que le message est bien présent sur le relay : -- Requête au relay avec l'ID du message -- Filtrage par auteur, destinataire et article -- Timeout de 5 secondes pour la vérification - -**Vérification** : `verifyPrivateMessagePublished()` confirme la présence du message sur le relay. - -### 3. Logs structurés - -Tous les événements sont journalisés avec : -- ID du message -- ID de l'article -- Clé publique du destinataire -- Clé publique de l'auteur -- Timestamp ISO -- Statut de vérification - -**Traçabilité** : Les logs permettent de suivre chaque envoi et de diagnostiquer les problèmes. - -## Garanties d'envoi - -### Niveau 1 : Publication réussie -- ✅ L'événement est signé et publié -- ✅ L'ID du message est retourné -- ✅ Le message est visible sur le relay - -### Niveau 2 : Vérification sur relay -- ✅ Le message est retrouvé sur le relay avec les bons filtres -- ✅ Les tags correspondent (auteur, destinataire, article) -- ✅ Le message est accessible - -### Niveau 3 : Récupération par le destinataire -- ✅ Le destinataire peut récupérer le message avec sa clé privée -- ✅ Le message est déchiffrable -- ✅ Le contenu correspond à l'article - -## Points de contrôle - -### 1. Avant l'envoi -- Vérification que le contenu privé est stocké -- Vérification que la clé privée de l'auteur est disponible -- Vérification que le paiement est confirmé (zap receipt) - -### 2. Pendant l'envoi -- Chiffrement du contenu avec NIP-04 -- Création de l'événement avec les bons tags -- Publication sur le relay - -### 3. Après l'envoi -- Vérification que l'événement est publié -- Vérification que le message est sur le relay -- Logs de confirmation - -## Gestion des erreurs - -### Erreurs possibles -1. **Contenu non trouvé** : Le contenu privé n'est pas stocké - - Log : `Stored private content not found for article` - - Action : Vérifier le stockage local - -2. **Clé privée indisponible** : La clé de l'auteur n'est pas disponible - - Log : `Author private key not available` - - Action : Vérifier la connexion Nostr - -3. **Publication échouée** : L'événement n'a pas pu être publié - - Log : `Failed to publish private message event` - - Action : Vérifier la connexion au relay - -4. **Vérification échouée** : Le message n'est pas sur le relay - - Log : `Private message not found on relay` - - Action : Réessayer ou vérifier la connexion - -## Traçabilité - -### Logs locaux (console navigateur) - -Chaque envoi génère des logs avec : -- **messageEventId** : ID unique du message sur Nostr -- **articleId** : ID de l'article concerné -- **recipientPubkey** : Clé publique du destinataire -- **authorPubkey** : Clé publique de l'auteur -- **timestamp** : Date et heure ISO de l'événement -- **verified** : Statut de vérification sur le relay - -### Événements de tracking sur Nostr - -Pour que la plateforme puisse suivre tous les envois, chaque envoi de contenu génère un événement de tracking publié sur Nostr : - -- **Kind** : 30078 (événement de tracking personnalisé) -- **Auteur** : L'auteur de l'article (qui envoie le contenu) -- **Tag `p`** : La clé publique de la plateforme (pour requêter tous les événements) -- **Tags** : - - `article` : ID de l'article - - `author` : Clé publique de l'auteur - - `recipient` : Clé publique du destinataire - - `message` : ID du message privé envoyé - - `amount` : Montant du paiement en sats - - `verified` : Statut de vérification (true/false) - - `timestamp` : Timestamp Unix - - `zap_receipt` : ID du zap receipt (si disponible) -- **Content** : JSON avec toutes les informations de tracking - -La plateforme peut interroger tous ces événements en filtrant par `#p` avec sa clé publique pour obtenir une vue complète de tous les envois de contenu. - -## Utilisation - -### Pour l'auteur -L'auteur peut vérifier que son contenu a bien été envoyé en consultant les logs de la console du navigateur. - -### Pour la plateforme -La plateforme peut suivre tous les envois via les logs structurés et identifier les problèmes de livraison. - -### Pour le destinataire -Le destinataire peut récupérer le contenu via `getPrivateContent()` qui interroge le relay Nostr. - -## Améliorations futures - -- Système de notification pour l'auteur en cas d'échec -- Retry automatique en cas d'échec de publication -- Dashboard de suivi des envois pour les auteurs -- Confirmation de réception par le destinataire diff --git a/docs/implementation-summary.md b/docs/implementation-summary.md deleted file mode 100644 index b7e4290..0000000 --- a/docs/implementation-summary.md +++ /dev/null @@ -1,132 +0,0 @@ -# Résumé final de l'implémentation - -**Date** : Décembre 2024 -**Auteur** : Équipe 4NK - -## État d'implémentation - -### ✅ COMPLÈTEMENT IMPLÉMENTÉ - -#### 1. Système de commissions -- ✅ Configuration centralisée (`lib/platformCommissions.ts`) -- ✅ Validation des montants à chaque étape -- ✅ Tracking sur Nostr avec tags de commission -- ✅ Logs structurés pour audit - -#### 2. Split pour articles -- ✅ Validation montant 800 sats (700/100) -- ✅ Tracking avec `author_amount` et `platform_commission` -- ✅ Récupération adresse Lightning auteur -- ✅ Transfert automatique déclenché (logs) - -#### 3. Split pour sponsoring -- ✅ Service `SponsoringPaymentService` avec calcul split -- ✅ Validation montant 0.046 BTC (0.042/0.004) -- ✅ **Intégration mempool.space** pour vérification transactions -- ✅ Vérification des sorties Bitcoin (auteur + plateforme) -- ✅ Tracking sur Nostr avec `SponsoringTrackingService` - -#### 4. Split pour avis -- ✅ Service `ReviewRewardService` avec commission (49/21 sats) -- ✅ Récupération adresse Lightning reviewer -- ✅ Transfert automatique déclenché (logs) -- ✅ **Mise à jour événement Nostr** avec tags `rewarded` et `reward_amount` -- ✅ Parsing des tags dans `parseReviewFromEvent` - -#### 5. Services d'intégration -- ✅ **Mempool.space** : Vérification transactions Bitcoin -- ✅ **Lightning addresses** : Récupération depuis profils Nostr -- ✅ **Tracking** : Événements Nostr pour audit complet - -### ⏳ EN ATTENTE D'INFRASTRUCTURE - -#### Transferts Lightning réels -- ⏳ Nécessite nœud Lightning de la plateforme -- ⏳ Nécessite API pour créer et payer des invoices -- ⏳ Nécessite queue de transferts pour gestion asynchrone - -**État actuel** : Les transferts sont loggés et tracés, mais nécessitent un nœud Lightning pour être exécutés automatiquement. - -## Fichiers créés dans cette session - -1. `lib/mempoolSpace.ts` - Intégration mempool.space API -2. `lib/lightningAddress.ts` - Récupération adresses Lightning -3. `lib/sponsoringTracking.ts` - Tracking sponsoring sur Nostr -4. `features/remaining-tasks.md` - Documentation des tâches -5. `features/final-implementation-summary.md` - Ce résumé - -## Fichiers modifiés - -1. `lib/sponsoringPayment.ts` - Intégration mempool.space -2. `lib/reviewReward.ts` - Mise à jour avis et récupération adresses -3. `lib/paymentPolling.ts` - Récupération adresse Lightning auteur -4. `lib/nostrEventParsing.ts` - Parsing tags `rewarded` et `reward_amount` -5. `types/nostr.ts` - Ajout `lud16` et `lud06` dans `NostrProfile` - -## Fonctionnalités opérationnelles - -### Articles -- ✅ Validation montant (800 sats) -- ✅ Tracking commissions (700/100) -- ✅ Récupération adresse Lightning auteur -- ✅ Logs de transfert automatique -- ⏳ Transfert réel (nécessite nœud Lightning) - -### Sponsoring -- ✅ Validation montant (0.046 BTC) -- ✅ Calcul split (0.042/0.004 BTC) -- ✅ **Vérification transaction via mempool.space** -- ✅ Tracking sur Nostr -- ✅ Vérification confirmations - -### Avis -- ✅ Validation montant (70 sats) -- ✅ Tracking commissions (49/21) -- ✅ Récupération adresse Lightning reviewer -- ✅ **Mise à jour événement Nostr avec tags rewarded** -- ✅ Logs de transfert automatique -- ⏳ Transfert réel (nécessite nœud Lightning) - -## Intégrations externes - -### mempool.space ✅ -- **URL** : https://mempool.space/fr/ -- **API** : `https://mempool.space/api/tx/{txid}` -- **Fonctionnalités** : - - Récupération transactions Bitcoin - - Vérification sorties et montants - - Vérification confirmations - - Attente confirmation avec polling - -### Lightning addresses ✅ -- **Standard** : NIP-19 (lud16, lud06) -- **Source** : Profils Nostr (kind 0) -- **Cache** : 1 heure TTL -- **Fallback** : null si non disponible - -## Prochaines étapes (infrastructure) - -### 1. Nœud Lightning -- Configurer un nœud Lightning pour la plateforme -- Intégrer API pour créer et payer des invoices -- Gérer les canaux et la liquidité - -### 2. Queue de transferts -- Créer une queue pour les transferts en attente -- Traiter les transferts en batch -- Gérer les retry en cas d'échec - -### 3. Monitoring -- Dashboard pour suivre les transferts -- Alertes en cas d'échec -- Statistiques de commissions - -## Conclusion - -**Toutes les fonctionnalités de split et de tracking sont implémentées et opérationnelles.** - -Les seules limitations sont liées à l'infrastructure : -- Transferts Lightning réels nécessitent un nœud Lightning -- Les transferts sont actuellement loggés et peuvent être exécutés manuellement - -Le système est **prêt pour la production** une fois le nœud Lightning configuré. diff --git a/docs/remaining-tasks.md b/docs/remaining-tasks.md index 2d38a3e..a5cbf4e 100644 --- a/docs/remaining-tasks.md +++ b/docs/remaining-tasks.md @@ -1,182 +1,26 @@ -# Tâches restantes - Système de commissions +# Tâches restantes -**Date** : Décembre 2024 **Auteur** : Équipe 4NK -## État actuel +## Infrastructure nécessaire -✅ **Implémenté** : -- Configuration centralisée des commissions -- Validation des montants à chaque étape -- Tracking des commissions sur Nostr -- Services de split (articles, avis, sponsoring) -- Services de transfert automatique (structure) +### Transferts Lightning automatiques -⏳ **À compléter** : -1. Intégration mempool.space pour vérification transactions Bitcoin -2. Récupération adresses Lightning depuis profils Nostr -3. Mise à jour événements Nostr pour avis rémunérés -4. Tracking sponsoring sur Nostr -5. Transferts Lightning réels (nécessite nœud Lightning) - -## Tâches détaillées - -### 1. Intégration mempool.space ✅ IMPLÉMENTÉ - -**Objectif** : Vérifier que les transactions Bitcoin de sponsoring contiennent les deux sorties correctes. - -**API mempool.space** : -- Endpoint : `https://mempool.space/api/tx/{txid}` -- Documentation : https://mempool.space/api - -**Implémenté** : -- ✅ Service `MempoolSpaceService` pour récupérer une transaction depuis mempool.space -- ✅ Vérification que la transaction a deux sorties : - - Sortie 1 : `split.authorSats` vers `authorMainnetAddress` - - Sortie 2 : `split.platformSats` vers `PLATFORM_BITCOIN_ADDRESS` -- ✅ Vérification du nombre de confirmations -- ✅ Gestion des erreurs et retry -- ✅ Intégré dans `sponsoringPayment.ts` - -**Fichier** : `lib/mempoolSpace.ts` ✅ - -### 2. Récupération adresses Lightning ✅ IMPLÉMENTÉ - -**Objectif** : Récupérer les adresses Lightning des auteurs/reviewers depuis leurs profils Nostr. - -**Standards Nostr** : -- NIP-19 : Lightning addresses dans les métadonnées de profil -- Format : `lud16` ou `lud06` dans le profil JSON -- Exemple : `{"lud16": "user@domain.com"}` - -**Implémenté** : -- ✅ Service `LightningAddressService` pour parser les métadonnées de profil -- ✅ Extraction de `lud16` ou `lud06` depuis les profils -- ✅ Cache des adresses récupérées -- ✅ Fallback si pas d'adresse disponible -- ✅ Intégré dans `paymentPolling.ts` et `reviewReward.ts` - -**Fichiers** : -- `lib/lightningAddress.ts` ✅ -- `types/nostr.ts` ✅ (ajout de `lud16` et `lud06`) - -### 3. Mise à jour événements Nostr pour avis ✅ IMPLÉMENTÉ - -**Objectif** : Mettre à jour l'événement Nostr d'un avis avec les tags `rewarded: true` et `reward_amount: 70`. - -**Implémenté** : -- ✅ Récupération de l'événement original de l'avis -- ✅ Ajout des tags `rewarded` et `reward_amount` -- ✅ Publication de l'événement mis à jour -- ✅ Gestion des erreurs si l'événement n'existe plus -- ✅ Vérification que l'avis n'est pas déjà rémunéré -- ✅ Parsing des tags dans `parseReviewFromEvent` - -**Fichiers** : -- `lib/reviewReward.ts` ✅ (méthode `updateReviewWithReward` implémentée) -- `lib/nostrEventParsing.ts` ✅ (parsing des tags `rewarded` et `reward_amount`) - -### 4. Tracking sponsoring sur Nostr ✅ IMPLÉMENTÉ - -**Objectif** : Publier des événements de tracking pour les paiements de sponsoring. - -**Implémenté** : -- ✅ Service `SponsoringTrackingService` pour publier les événements -- ✅ Tags similaires aux articles : `author_amount`, `platform_commission` -- ✅ Vérification de transaction via mempool.space avant tracking -- ✅ Informations de confirmation et nombre de confirmations -- ✅ Intégré dans `sponsoringPayment.ts` - -**Fichiers** : -- `lib/sponsoringTracking.ts` ✅ (nouveau service) -- `lib/sponsoringPayment.ts` ✅ (méthode `trackSponsoringPayment` implémentée) - -### 5. Transferts Lightning réels (PRIORITÉ BASSE - nécessite infrastructure) - -**Objectif** : Effectuer réellement les transferts Lightning vers les auteurs/reviewers. - -**Prérequis** : -- Nœud Lightning de la plateforme -- API pour créer et payer des invoices -- Gestion des erreurs et retry +**État actuel** : Les transferts sont loggés dans `lib/automaticTransfer.ts` mais nécessitent un nœud Lightning pour être exécutés automatiquement. **À implémenter** : -- Intégration avec l'API du nœud Lightning -- Création d'invoices pour les transferts -- Paiement automatique des invoices -- Queue de transferts en attente +- Configuration nœud Lightning de la plateforme +- API pour créer et payer des invoices Lightning +- Queue de transferts pour gestion asynchrone - Retry en cas d'échec +- Monitoring et alertes -**Fichier** : `lib/automaticTransfer.ts` (modifier les méthodes de transfert) +**Fichiers concernés** : `lib/automaticTransfer.ts` -## Plan d'implémentation +## Fonctionnalités complétées -### Phase 1 : Vérification transactions ✅ TERMINÉ -1. ✅ Créer `lib/mempoolSpace.ts` -2. ✅ Implémenter récupération transaction -3. ✅ Implémenter vérification sorties -4. ✅ Intégrer dans `sponsoringPayment.ts` - -### Phase 2 : Adresses Lightning ✅ TERMINÉ -1. ✅ Créer `lib/lightningAddress.ts` -2. ✅ Parser profils Nostr pour `lud16`/`lud06` -3. ✅ Intégrer dans `paymentPolling.ts` et `reviewReward.ts` - -### Phase 3 : Mise à jour avis ✅ TERMINÉ -1. ✅ Implémenter `updateReviewWithReward` dans `reviewReward.ts` -2. ✅ Parser tags `rewarded` et `reward_amount` dans `parseReviewFromEvent` - -### Phase 4 : Tracking sponsoring ✅ TERMINÉ -1. ✅ Créer `lib/sponsoringTracking.ts` -2. ✅ Implémenter tracking dans `sponsoringPayment.ts` -3. ⏳ Mise à jour `total_sponsoring` sur présentation (structure préparée) - -### Phase 5 : Transferts réels (long terme - nécessite infrastructure) -1. ⏳ Configurer nœud Lightning -2. ⏳ Implémenter API d'intégration -3. ⏳ Créer queue de transferts -4. ⏳ Monitoring et alertes - -## Notes techniques - -### mempool.space API - -**Récupérer une transaction** : -``` -GET https://mempool.space/api/tx/{txid} -``` - -**Réponse** : -```json -{ - "txid": "...", - "vout": [ - { - "value": 4200000, - "scriptpubkey_address": "bc1q..." - }, - { - "value": 400000, - "scriptpubkey_address": "bc1q..." - } - ], - "status": { - "confirmed": true, - "block_height": 123456, - "block_hash": "..." - } -} -``` - -### Lightning addresses dans Nostr - -**Format profil** : -```json -{ - "name": "Author", - "lud16": "author@getalby.com", - "lud06": "lnurl..." -} -``` - -**NIP-19** : Les adresses Lightning peuvent être dans les métadonnées de profil (kind 0). +✅ Intégration mempool.space (`lib/mempoolSpace.ts`) +✅ Récupération adresses Lightning (`lib/lightningAddress.ts`) +✅ Mise à jour événements Nostr pour avis (`lib/reviewReward.ts`) +✅ Tracking sponsoring (`lib/sponsoringTracking.ts`) +✅ Vérification livraison contenu (`lib/contentDeliveryVerification.ts`) diff --git a/docs/split-and-transfer.md b/docs/split-and-transfer.md deleted file mode 100644 index c02aa7f..0000000 --- a/docs/split-and-transfer.md +++ /dev/null @@ -1,191 +0,0 @@ -# Implémentation du split et transfert automatique - -**Date** : Décembre 2024 -**Auteur** : Équipe 4NK - -## Contexte - -Cette session implémente les fonctionnalités manquantes pour compléter le système de commissions : -1. Split pour le sponsoring (Bitcoin mainnet) -2. Split pour les avis (Lightning) -3. Système de transfert automatique après paiement - -## Implémentations - -### 1. Split pour le sponsoring (Bitcoin mainnet) - -**Fichier créé** : `lib/sponsoringPayment.ts` - -**Fonctionnalités** : -- Service `SponsoringPaymentService` pour gérer les paiements de sponsoring -- Validation du montant (0.046 BTC total) -- Calcul du split (0.042 BTC auteur, 0.004 BTC plateforme) -- Génération des adresses Bitcoin pour la transaction -- Vérification des transactions Bitcoin (structure préparée) - -**Fonctionnement** : -1. L'utilisateur demande un paiement de sponsoring -2. Le service calcule le split et retourne les adresses -3. L'utilisateur crée une transaction Bitcoin avec deux sorties : - - Sortie 1 : 0.042 BTC vers l'adresse de l'auteur - - Sortie 2 : 0.004 BTC vers l'adresse de la plateforme -4. La plateforme vérifie que la transaction contient les deux sorties correctes -5. Le sponsoring est enregistré et tracé - -**Limitations actuelles** : -- La vérification de transaction nécessite un service blockchain (à implémenter) -- Le tracking nécessite une intégration avec un explorateur Bitcoin - -### 2. Split pour les avis (Lightning) - -**Fichier créé** : `lib/reviewReward.ts` - -**Fonctionnalités** : -- Service `ReviewRewardService` pour gérer les rémunérations d'avis -- Création d'invoice Lightning avec commission (70 sats total) -- Split automatique (49 sats reviewer, 21 sats plateforme) -- Transfert automatique de la part du reviewer -- Mise à jour de l'avis avec tag `rewarded: true` - -**Fonctionnement** : -1. L'auteur clique sur "Remercier" pour un avis -2. Le service crée une invoice Lightning de 70 sats -3. L'auteur paie l'invoice -4. Après confirmation du paiement : - - La plateforme reçoit 70 sats - - Le service déclenche le transfert automatique de 49 sats au reviewer - - La plateforme garde 21 sats de commission - - L'avis est mis à jour avec le tag `rewarded: true` - -**Limitations actuelles** : -- Le transfert automatique nécessite l'adresse Lightning du reviewer (à récupérer du profil) -- Nécessite un nœud Lightning de la plateforme pour effectuer les transferts - -### 3. Système de transfert automatique - -**Fichier créé** : `lib/automaticTransfer.ts` - -**Fonctionnalités** : -- Service `AutomaticTransferService` pour gérer les transferts automatiques -- Transfert de la part de l'auteur après paiement d'article -- Transfert de la part du reviewer après rémunération d'avis -- Tracking des transferts requis -- Logs structurés pour audit - -**Fonctionnement** : -1. Après confirmation d'un paiement, le service calcule le split -2. Il déclenche un transfert automatique vers l'auteur/reviewer -3. Le transfert est tracé et loggé -4. En cas d'échec, le transfert peut être fait manuellement plus tard - -**Intégration** : -- Intégré dans `lib/paymentPolling.ts` pour les articles -- Intégré dans `lib/reviewReward.ts` pour les avis - -**Limitations actuelles** : -- Nécessite un nœud Lightning de la plateforme pour effectuer les transferts -- Nécessite les adresses Lightning des auteurs/reviewers (à récupérer des profils) -- Pour l'instant, les transferts sont loggés mais pas exécutés automatiquement - -## Architecture - -### Flux de paiement article avec transfert automatique - -``` -1. Lecteur paie 800 sats → Invoice Lightning -2. Paiement confirmé via zap receipt -3. Contenu privé envoyé au lecteur -4. Tracking avec commissions (700/100) -5. Transfert automatique déclenché : - - 700 sats vers auteur (si adresse disponible) - - 100 sats gardés par plateforme -6. Transfert tracé et loggé -``` - -### Flux de rémunération avis avec transfert automatique - -``` -1. Auteur paie 70 sats → Invoice Lightning -2. Paiement confirmé via zap receipt -3. Transfert automatique déclenché : - - 49 sats vers reviewer (si adresse disponible) - - 21 sats gardés par plateforme -4. Avis mis à jour avec tag rewarded: true -5. Transfert tracé et loggé -``` - -### Flux de sponsoring avec split - -``` -1. Utilisateur demande sponsoring (0.046 BTC) -2. Service calcule split : - - 0.042 BTC → auteur - - 0.004 BTC → plateforme -3. Service retourne deux adresses Bitcoin -4. Utilisateur crée transaction avec deux sorties -5. Transaction broadcastée sur Bitcoin mainnet -6. Plateforme vérifie transaction (à implémenter) -7. Sponsoring enregistré et tracé -``` - -## Fichiers créés - -1. `lib/automaticTransfer.ts` - Service de transfert automatique -2. `lib/sponsoringPayment.ts` - Service de paiement sponsoring -3. `lib/reviewReward.ts` - Service de rémunération avis -4. `features/split-and-transfer-implementation.md` - Cette documentation - -## Fichiers modifiés - -1. `lib/paymentPolling.ts` - Intégration du transfert automatique pour articles - -## Prochaines étapes - -### Pour le transfert automatique Lightning - -1. **Récupérer les adresses Lightning** : - - Ajouter un champ `lightningAddress` dans les profils Nostr - - Récupérer depuis les métadonnées de profil (NIP-05, etc.) - - Stocker dans le cache local - -2. **Implémenter le transfert réel** : - - Intégrer avec un nœud Lightning de la plateforme - - Utiliser l'API du nœud pour créer et payer des invoices - - Gérer les erreurs et retry - -3. **Queue de transferts** : - - Créer une queue pour les transferts en attente - - Traiter les transferts en batch - - Gérer les échecs et retry - -### Pour le sponsoring - -1. **Vérification de transaction** : - - Intégrer avec un explorateur Bitcoin (Blockstream API, etc.) - - Vérifier que la transaction contient les deux sorties - - Vérifier les montants et adresses - -2. **Tracking sur Nostr** : - - Publier des événements de tracking pour les sponsoring - - Mettre à jour le tag `total_sponsoring` sur l'article de présentation - -### Pour les avis - -1. **Récupération adresse reviewer** : - - Récupérer depuis le profil Nostr du reviewer - - Stocker dans le cache - -2. **Mise à jour de l'avis** : - - Implémenter la mise à jour de l'événement Nostr avec tag `rewarded: true` - - Publier l'événement mis à jour - -## Résultat - -Les trois fonctionnalités sont maintenant implémentées avec : -- ✅ Calcul et validation des splits -- ✅ Services prêts pour l'intégration -- ✅ Tracking et logs structurés -- ⏳ Transferts automatiques (nécessitent nœud Lightning) -- ⏳ Vérification transactions Bitcoin (nécessitent service blockchain) - -Le système est prêt pour l'intégration avec les services externes nécessaires. diff --git a/docs/technical.md b/docs/technical.md new file mode 100644 index 0000000..a3bf97a --- /dev/null +++ b/docs/technical.md @@ -0,0 +1,92 @@ +# Documentation technique + +**Auteur** : Équipe 4NK + +## Architecture + +Zapwall est une plateforme décentralisée basée sur Nostr pour la publication et la monétisation de contenu. Le système utilise Lightning Network pour les paiements et Bitcoin mainnet pour le sponsoring. + +### Services principaux + +- **Nostr** (`lib/nostr.ts`) : Pool de connexions, publication/récupération d'événements, profils, zap requests +- **Paiements** (`lib/payment.ts`, `lib/paymentPolling.ts`) : Invoices Lightning via Alby/WebLN, vérification zap receipts (NIP-57), envoi automatique contenu privé +- **Commissions** (`lib/platformCommissions.ts`) : Configuration centralisée, calcul splits, validation montants +- **Tracking** (`lib/platformTracking.ts`, `lib/sponsoringTracking.ts`) : Événements Nostr (kind 30078/30079) pour audit +- **Intégrations** : + - `lib/mempoolSpace.ts` : Vérification transactions Bitcoin via mempool.space API + - `lib/lightningAddress.ts` : Récupération adresses Lightning depuis profils Nostr (lud16/lud06) + +### Stockage + +- **IndexedDB** : Contenu privé chiffré (AES-GCM) +- **localStorage** : Métadonnées articles, invoices +- **Nostr** : Contenus publics et événements de tracking + +## Système de commissions + +### Configuration (`lib/platformCommissions.ts`) + +- **Articles** : 800 sats (700 auteur, 100 plateforme) +- **Avis** : 70 sats (49 reviewer, 21 plateforme) +- **Sponsoring** : 0.046 BTC (0.042 auteur, 0.004 plateforme) + +### Implémentation + +**Articles** (`lib/paymentPolling.ts`, `lib/articleInvoice.ts`) : +- Validation montant 800 sats à chaque étape +- Tracking avec `author_amount` et `platform_commission` dans événements Nostr +- Récupération adresse Lightning auteur via `lightningAddressService` +- Transfert automatique déclenché (logs, nécessite nœud Lightning pour exécution) + +**Sponsoring** (`lib/sponsoringPayment.ts`, `lib/sponsoringTracking.ts`) : +- Validation montant 0.046 BTC +- Vérification transactions Bitcoin via `mempoolSpaceService` (sorties auteur + plateforme) +- Tracking sur Nostr (kind 30079) avec confirmations + +**Avis** (`lib/reviewReward.ts`) : +- Validation montant 70 sats +- Mise à jour événement Nostr avec tags `rewarded: true` et `reward_amount: 70` +- Récupération adresse Lightning reviewer +- Transfert automatique déclenché (logs, nécessite nœud Lightning) + +### Tracking + +Tous les paiements sont trackés sur Nostr : +- **Kind 30078** : Livraisons de contenu (`lib/platformTracking.ts`) +- **Kind 30079** : Paiements de sponsoring (`lib/sponsoringTracking.ts`) + +Les événements incluent `author_amount`, `platform_commission`, `zap_receipt` (si applicable), et sont signés par l'auteur avec tag `p` pour la plateforme. + +## Flux de paiement article + +1. Lecteur clique "Unlock for 800 sats" +2. Création invoice Lightning via Alby/WebLN (`lib/articleInvoice.ts`) +3. Publication zap request sur Nostr (NIP-57) +4. Lecteur paie l'invoice +5. Polling vérification zap receipt (`lib/paymentPolling.ts`) +6. Envoi automatique contenu privé (message chiffré NIP-04, `lib/articlePublisher.ts`) +7. Tracking livraison avec commissions (`lib/platformTracking.ts`) + +## Flux de sponsoring + +1. Utilisateur demande sponsoring 0.046 BTC (`lib/sponsoringPayment.ts`) +2. Service calcule split (0.042/0.004 BTC) +3. Retourne deux adresses Bitcoin (auteur + plateforme) +4. Utilisateur crée transaction avec deux sorties +5. Vérification via mempool.space (`lib/mempoolSpace.ts`) +6. Tracking sur Nostr (`lib/sponsoringTracking.ts`) + +## Vérification livraison contenu + +Le système vérifie l'envoi du contenu privé à trois niveaux : + +1. **Publication** : `publishEvent()` retourne l'ID de l'événement publié +2. **Vérification relay** : `verifyPrivateMessagePublished()` confirme présence sur relay (timeout 5s) +3. **Tracking** : Événement Nostr (kind 30078) avec `verified: true/false` + +Tous les événements sont loggés avec IDs, timestamps et statuts. + +## Limitations + +**Transferts Lightning automatiques** : Nécessitent un nœud Lightning de la plateforme. Actuellement, les transferts sont loggés dans `lib/automaticTransfer.ts` et peuvent être exécutés manuellement. Les adresses Lightning sont récupérées automatiquement depuis les profils Nostr. + diff --git a/fixKnowledge/2025-12-22-lint-type-fixes.md b/fixKnowledge/2025-12-22-lint-type-fixes.md deleted file mode 100644 index aa4bd9e..0000000 --- a/fixKnowledge/2025-12-22-lint-type-fixes.md +++ /dev/null @@ -1,20 +0,0 @@ -# Lint & type fixes (exactOptionalPropertyTypes) - -**Problem:** TypeScript strict optional props and nostr-tools API differences caused `npm run type-check` and `next lint` to fail. - -**Impact:** Build blocked (exact optional props errors, nostr-tools signing types), lint blocked (`max-lines-per-function`, `prefer-const`). - -**Root cause:** Code was written against older nostr-tools typings and passed `undefined` into optional props under `exactOptionalPropertyTypes`. - -**Corrections (code):** -- Normalized optional props handling (conditional spreads) across editor, fields, notifications, storage, markdown rendering. -- Added safe category handling for article drafts; tightened defaults and guards. -- Aligned signing with nostr-tools 1.17.0 (explicit `pubkey`/`created_at`, hash/sign helpers). -- Fixed async return contracts, removed unused params, and satisfied lint structure rules. -- Kept storage and notification payloads free of `undefined` fields; guarded link rendering. - -**Modifications (files):** `components/ArticleEditor*.tsx`, `components/ArticleField.tsx`, `components/UserArticles.tsx`, `components/CategorySelect.tsx`, `lib/{nostr,nostrRemoteSigner,nostrconnect,articlePublisher,articleStorage,markdownRenderer,notifications,zapVerification}.ts`, `hooks/useArticles.ts`, `hooks/useUserArticles.ts`, `types/nostr-tools-extended.ts`, `package.json` (nostr-tools 1.17.0). - -**Deployment:** No special steps; run `npm run lint && npm run type-check` (already clean). - -**Analysis:** Ensured strict optional handling without fallbacks, restored compatibility with stable nostr-tools API, and kept functions within lint boundaries. diff --git a/fixKnowledge/2025-12-23-optional-props-lint-types.md b/fixKnowledge/2025-12-23-optional-props-lint-types.md deleted file mode 100644 index 04478bc..0000000 --- a/fixKnowledge/2025-12-23-optional-props-lint-types.md +++ /dev/null @@ -1,27 +0,0 @@ -## Problème -Erreurs TypeScript `exactOptionalPropertyTypes` et avertissements ESLint `max-lines-per-function` sur les composants de sélection de séries (ArticleEditorForm, Profile, UserArticles). - -## Impacts -- Blocage du `tsc --noEmit` et du lint, empêchant le déploiement. -- Risque de régressions UI (sélection de série) si les props optionnelles sont mal typées. - -## Cause -Propagation de props optionnelles (`seriesOptions`, `onSelectSeries`, `selectedSeriesId`) sans inclure explicitement `undefined` dans les signatures avec `exactOptionalPropertyTypes: true`. - -## Root cause -Contrats de composants non alignés sur les exigences strictes TypeScript (exactOptionalPropertyTypes) et fonctions trop longues (>40 lignes) dans ArticleEditorForm et UserArticles. - -## Corrections -- Typage explicite des props optionnelles avec `| undefined` et propagation conditionnelle des props. -- Refactoring des fonctions longues : extraction des handlers (SeriesSelect) et découpage de `createLayoutProps`. - -## Modifications -- `components/ArticleEditor.tsx`, `components/ArticleEditorForm.tsx`, `components/ProfileArticlesSection.tsx`, `components/ProfileSeriesBlock.tsx`, `components/SeriesSection.tsx`, `components/SeriesList.tsx`, `components/SeriesCard.tsx`, `components/UserArticles.tsx`, `components/UserArticlesList.tsx`, `components/ProfileView.tsx`. -- Ajustements de typage et réduction des fonctions >40 lignes. - -## Modalités de déploiement -Pas d’action spécifique : lint et type-check passent (`npm run lint`, `npm run type-check`). Déployer via la pipeline habituelle. - -## Modalités d'analyse -- Vérifier `npm run lint` et `npm run type-check`. -- Tester la sélection/filtrage de série dans l’éditeur d’articles et sur la page profil (navigation série). diff --git a/lib/platformTracking.ts b/lib/platformTracking.ts index 74ddb97..a95ac2a 100644 --- a/lib/platformTracking.ts +++ b/lib/platformTracking.ts @@ -157,7 +157,7 @@ export class PlatformTrackingService { const zapReceiptTag = event.tags.find((tag) => tag[0] === 'zap_receipt')?.[1] const authorAmountTag = event.tags.find((tag) => tag[0] === 'author_amount')?.[1] const platformCommissionTag = event.tags.find((tag) => tag[0] === 'platform_commission')?.[1] - + const delivery: ContentDeliveryTracking = { ...data, } @@ -233,7 +233,7 @@ export class PlatformTrackingService { try { const data = JSON.parse(event.content) as ContentDeliveryTracking const zapReceiptTag = event.tags.find((tag) => tag[0] === 'zap_receipt')?.[1] - + const delivery: ContentDeliveryTracking = { ...data, }