# Implémentation NIP-98 pour authentification nostrcheck.me

## Date
2025-01-27

## Objectif
Implémenter l'authentification NIP-98 pour permettre l'upload de médias vers nostrcheck.me qui nécessite une authentification.

## Motivations
- nostrcheck.me retourne 401 Unauthorized sans authentification
- NIP-98 est le standard d'authentification HTTP pour Nostr
- Permettre l'utilisation de nostrcheck.me comme endpoint NIP-95

## Impacts
- **Utilisateurs** : Peuvent maintenant uploader vers nostrcheck.me s'ils sont connectés avec une extension Nostr (Alby, nos2x, etc.)
- **Fonctionnalité** : Un endpoint supplémentaire disponible pour les uploads
- **Sécurité** : L'authentification utilise la signature Nostr standard

## Modifications

### Fichiers créés
- **`lib/nip98.ts`** : Implémentation de NIP-98 pour générer des tokens d'authentification HTTP

### Fichiers modifiés
- **`lib/nip95.ts`** : Détection automatique de nostrcheck.me et génération du token NIP-98
- **`pages/api/nip95-upload.ts`** : Ajout du header Authorization avec le token NIP-98

### Fonctionnalités implémentées

#### Génération du token NIP-98 (`lib/nip98.ts`)
- Création d'un événement Nostr de type 27235 (NIP-98 HTTP Auth)
- Tags requis :
  - `u` : URL complète de la requête
  - `method` : Méthode HTTP (POST)
  - `payload` : Hash SHA256 du body (optionnel, non implémenté pour l'instant)
- Signature de l'événement via `nostrRemoteSigner` (support Alby/nos2x)
- Encodage base64 de l'événement signé

#### Intégration dans le flux d'upload (`lib/nip95.ts`)
- Détection automatique si l'endpoint est nostrcheck.me
- Vérification de la disponibilité de NIP-98 (utilisateur connecté)
- Génération du token pour l'URL finale (nostrcheck.me)
- Passage du token à l'API proxy via paramètre de requête

#### Support dans l'API proxy (`pages/api/nip95-upload.ts`)
- Récupération du token depuis les paramètres de requête
- Ajout du header `Authorization: Nostr <token>` aux requêtes HTTP
- Préservation du token lors des redirections HTTP

## Modalités de déploiement
1. Les modifications sont dans le code source
2. Rebuild de l'application : `npm run build`
3. Redémarrage du service Next.js
4. Aucune migration de données nécessaire

## Modalités d'analyse
Pour vérifier que l'authentification fonctionne :

1. **Vérifier la connexion Nostr** :
   - L'utilisateur doit être connecté avec Alby, nos2x ou une autre extension NIP-07
   - Vérifier que `nostrRemoteSigner.isAvailable()` retourne true

2. **Tester l'upload vers nostrcheck.me** :
   - Activer nostrcheck.me dans les settings
   - Tenter un upload d'image/vidéo
   - Vérifier que le token NIP-98 est généré (logs console)
   - Vérifier que le header Authorization est présent dans la requête

3. **Vérifier les logs serveur** :
   - Chercher les logs de redirection si applicable
   - Vérifier que le header Authorization est transmis
   - Vérifier la réponse de nostrcheck.me (devrait être 200 au lieu de 401)

4. **En cas d'erreur** :
   - Vérifier que l'utilisateur est bien connecté
   - Vérifier que le compte nostrcheck.me est créé avec la même clé
   - Vérifier les logs pour les erreurs de signature

## Notes
- Le token NIP-98 est généré côté client (navigateur) car il nécessite la clé privée
- Le token est passé à l'API proxy via paramètre de requête (sécurisé car HTTPS)
- Le token est valide uniquement pour l'URL et la méthode spécifiées
- Le token inclut un timestamp et expire après un certain temps (selon la politique de nostrcheck.me)
- Pour l'instant, le hash du payload n'est pas calculé (peut être ajouté plus tard si nécessaire)
- Le kind 27235 est le kind standard pour NIP-98 HTTP Auth

## Références
- NIP-98 : https://github.com/nostr-protocol/nips/blob/master/98.md
- nostrcheck.me : https://nostrcheck.me/
- NIP-07 : https://github.com/nostr-protocol/nips/blob/master/07.md