Filtrage d'URL content-addressed Blossom

Problème

Le code qui extrait des URLs de vidéos depuis les événements Nostr (ou métadonnées similaires basées sur des tags) supprime silencieusement les URLs des serveurs Blossom et autres stockages content-addressed en filtrant sur des extensions de fichier comme .mp4. Ces serveurs utilisent des URLs basées sur des hash sans extensions (ex. https://blossom.example.com/{sha256}), causant l'échec de l'extraction d'URL et un retour à une URL CDN qui produit également un 404 pour du contenu non-CDN.

Contexte / Conditions de déclenchement

Les vidéos de certains serveurs ne sont jamais traitées (modérées, transcodées, etc.)
Le code d'extraction d'URL contient des motifs comme url.includes('.mp4') ou url.includes('/video/')
L'extraction du tag imeta Nostr nécessite .mp4 dans la chaîne d'URL
Le filtrage du tag r Nostr cherche .mp4 ou /video/ dans l'URL
Le retour CDN construit https://cdn.domain/{sha256}.mp4 mais le serveur serve à /{sha256}
Le stockage content-addressed (Blossom, passerelles IPFS) utilise des URLs sans extension
Les défaillances sont silencieuses — pas d'erreurs, les vidéos n'apparaissent juste jamais dans le pipeline de traitement

Solution

1. Supprimer le filtrage d'extension de l'extraction d'URL

Mauvais (supprime les URLs blossom) :

// extraction du tag imeta
if (param.startsWith('url ') && param.includes('.mp4')) {
  url = param.substring(4).trim();
}

// extraction du tag r
if (url.includes('.mp4') || url.includes('/video/')) {
  return url;
}

Bon (accepte toute URL) :

// extraction du tag imeta — accepter toute URL
if (param.startsWith('url ') && param.length > 4) {
  url = param.substring(4).trim();
}

// extraction du tag r — accepter toute URL http
if (url.startsWith('http')) {
  return url;
}

2. Pour les événements spécifiques à un type, faire confiance au kind

Si vous savez déjà qu'un événement est un événement vidéo (ex. kind 34236), toute URL dans ses tags est une URL vidéo. Ne re-validez pas le type de média par extension.

3. Utiliser le type MIME de imeta au lieu de l'extension

Si vous devez valider le type de média, utilisez le champ m dans les tags imeta :

for (const param of tag.slice(1)) {
  if (param.startsWith('m video/')) isVideo = true;
  if (param.startsWith('url ')) imetaUrl = param.substring(4).trim();
}

4. Corriger les URLs de retour CDN

// Mauvais : ajoute .mp4
let videoUrl = `https://${CDN_DOMAIN}/${sha256}.mp4`;

// Bon : chemin content-addressed (sans extension)
let videoUrl = `https://${CDN_DOMAIN}/${sha256}`;

Vérification

Vérifier que les vidéos provenant de serveurs blossom non-CDN apparaissent dans la file de modération/traitement
Vérifier que extractVideoUrlFromEvent retourne des URLs pour les événements avec tags imeta/r sans extension
Confirmer que les URLs de retour CDN se résolvent correctement sans l'extension .mp4

Exemple

Un événement Nostr kind 34236 avec tags :

["imeta", "url https://blossom.primal.net/abc123def456...", "m video/mp4", "x abc123def456..."]

Ancien code : url.includes('.mp4') → false → URL supprimée → retour CDN → 404 → vidéo jamais modérée

Nouveau code : accepte toute URL de imeta → https://blossom.primal.net/abc123def456... → HiveAI peut la récupérer → vidéo modérée

Notes

Cela s'applique à TOUT pipeline de traitement de médias, pas seulement la modération
Blossom (BUD-01) utilise des chemins /{sha256} ; certains serveurs ajoutent des en-têtes Content-Type
Les flux HLS (.m3u8), les vignettes WebP et autres formats n'auront également pas d'extension .mp4
Certains clients malveillants peuvent ne suivre aucune convention de chemin du tout
Le champ m (type MIME) dans imeta est la bonne façon de déterminer le type de média, pas le chemin de l'URL
Privilégier les URLs imeta par rapport aux URLs du tag r (imeta est plus spécifique/fiable)

blossom-content-addressed-url-filtering