NWAK Le microscope du protocole Nostr

Préface — Pourquoi ce manuel existe

NWAK, pour Nostr Web Army Knife, n’est pas un client Nostr. Ce n’est pas une timeline, ni un relay, ni un wallet. C’est un microscope : un outil qui te montre le protocole Nostr au niveau où il ne ment pas — celui de l’event JSON signé.

Là où les clients te montrent des “posts”, NWAK te montre des events : leur kind, leur pubkey, leurs tags, leur content, leur id, leur sig. Il enlève l’interface, les réactions, les likes, les fils, et ne garde que la mécanique cryptographique.

Ce manuel a un objectif simple : te donner une compréhension souveraine de Nostr. Tu ne verras plus jamais un event comme avant.

1. La grammaire du protocole Nostr

Un event Nostr est une phrase cryptographique. Pour le lire correctement, il faut en comprendre la grammaire interne :

• Sujet : pubkey — qui parle ?
• Verbe : kind — que fait cet event ?
• Compléments : tags — à quoi / à qui / à quel contexte se rattache‑t‑il ?
• Contexte : created_at — quand cette phrase a‑t‑elle été prononcée ?
• Message : content — quel est le contenu brut ?
• Preuve : sig — qui en prend la responsabilité cryptographique ?
• Empreinte : id — quelle est l’empreinte unique de cette phrase ?

Comprendre Nostr, c’est accepter qu’un event n’est pas un “post”, mais une structure cryptographique signée qui représente un message. NWAK te montre cette structure sans filtre.

2. Anatomie d’un event Nostr

Un event Nostr valide est un objet JSON strict, défini par NIP‑01. Les champs fondamentaux sont :

• kind — le type d’event (note, metadata, replaceable, Mostro, etc.)
• pubkey — la clé publique de l’émetteur
• created_at — le timestamp Unix
• tags — un tableau de tableaux, chaque tag étant une liste de chaînes
• content — le contenu brut (texte, JSON, données sérialisées)
• id — le hash SHA‑256 du contenu canonique de l’event
• sig — la signature ECDSA secp256k1 de l’id

Si un seul de ces éléments est incohérent (hash incorrect, signature invalide, structure JSON cassée), l’event cesse d’être un event Nostr valide. NWAK est l’outil qui te permet de vérifier cette cohérence, champ par champ.

3. NWAK — Le microscope du protocole

NWAK est une web‑app statique qui tourne entièrement dans ton navigateur. Pas de backend, pas de base de données, pas de tracking. Tu peux la cloner, la builder, l’héberger toi‑même. Elle te permet de :

• décoder des events (JSON, bech32, note, nevent, npub, nsec)
• encoder des structures dans les formats attendus par les relays
• calculer l’id d’un event selon NIP‑01
• signer un event avec une clé privée ou via NIP‑07
• inspecter tous les champs et tags d’un event
• comparer un event généré par un client avec un event “canonique”

Pour un cryptographe, NWAK est un laboratoire de signatures. Pour un développeur, c’est un débogueur universel. Pour un utilisateur souverain, c’est un outil de vérification : il ne fait plus confiance à un client, il vérifie ce qu’il signe.

4. Workflow souverain — De l’event brut à la publication

Voici le workflow complet, du JSON brut à la diffusion sur un relay, en utilisant NWAK comme centre de gravité.

Étape 1 — Construire l’event brut

Tu définis :

• kind — type d’event (par exemple 1 pour une note)
• content — ton message ou tes données
• tags — les relations (réponses, références, protocoles, etc.)
• created_at — timestamp Unix
• pubkey — ta clé publique

Étape 2 — Calculer l’ID

NWAK calcule l’id en appliquant la procédure NIP‑01 : sérialisation canonique, puis hash SHA‑256. Cet id est l’empreinte unique de l’event.

Étape 3 — Signer l’event

Tu signes l’id avec ta clé privée (nsec) via :

• une extension NIP‑07 (nos2x, Alby, etc.)
• un outil comme nsecBunker
• une librairie (nostr‑tools, etc.)
• ou directement dans NWAK si tu gères la clé manuellement

Étape 4 — Vérifier la cohérence

Tu vérifies dans NWAK que :

• l’id correspond bien au contenu
• la sig est valide pour cette pubkey
• les tags sont bien formés
• le kind est cohérent avec l’usage

Étape 5 — Publier sur un relay

Tu copies l’event signé et tu le publies via :

• WebsocketKing (ou équivalent)
• un client Nostr
• un script maison

Le message envoyé au relay est de la forme :

["EVENT", { ...event_signé... }]

Étape 6 — Confirmer la réception

Le relay répond typiquement :

["OK","<id>",true,""]

Cela signifie simplement : “j’ai reçu et accepté cet event”. Le relay ne “valide” pas ton message au sens applicatif : il le stocke ou le rejette selon ses règles.

5. Signer un event — Cas d’usage

Signer un event, c’est produire une preuve cryptographique que tu en es l’auteur. C’est l’acte d’identité fondamental dans Nostr. Quelques cas d’usage typiques :

5.1 Note simple (kind 1)

Tu écris un message texte, tu définis kind:1, tu signes, tu publies. C’est le cas le plus simple : une note publique.

5.2 Signature via NIP‑07

Un client ou une page web appelle window.nostr.signEvent(event). L’extension NIP‑07 affiche une demande de signature, signe l’event et renvoie l’objet complet. NWAK te permet de vérifier que ce qui a été signé correspond bien à ce que tu crois avoir signé.

5.3 Event Mostro (kind 38383)

Un ordre Mostro est un event avec une structure stricte (tags d, k, f, s, amt, fa, pm, premium, network, layer, z). La signature est indispensable : sans elle, l’ordre n’existe pas pour le daemon Mostro. NWAK permet d’inspecter et de vérifier ces events.

5.4 Replaceable events (NIP‑33)

Un replaceable event (profil, article, manifeste, configuration) partage un même tag d et un kind spécifique (par exemple 30000). Chaque mise à jour est un nouvel event signé qui remplace le précédent. NWAK te permet de vérifier que la structure et la signature sont correctes.

5.5 Messages privés (NIP‑59)

Un message privé est un event chiffré (par exemple kind 1059) avec un tag p pointant vers la pubkey du destinataire. Le contenu est chiffré, mais l’event reste signé et visible. NWAK permet d’inspecter la structure, même si le contenu reste illisible.

5.6 Signature hors navigateur

Tu peux signer des events avec des outils comme nostr-tools, des scripts maison ou des systèmes comme nsecBunker. NWAK devient alors l’outil de vérification externe : tu y colles l’event pour confirmer que tout est cohérent.

6. Publier un event — Cas d’usage

Publier un event, c’est l’envoyer à un ou plusieurs relays via WebSocket. Quelques scénarios typiques :

6.1 Publication simple

Tu envoies :

["EVENT",{ ...event_signé... }]

Le relay répond avec un ["OK", ...]. L’event est désormais stocké (ou non) selon la politique du relay.

6.2 Replaceable events

Pour un replaceable event (NIP‑33), le relay remplace l’ancienne version par la nouvelle, en se basant sur le couple kind + tag d + pubkey. NWAK te permet de vérifier que l’event publié est bien celui que tu voulais.

6.3 Events Mostro

Pour Mostro, tu publies sur wss://relay.mostro.network. Le daemon lit les events kind 38383, interprète les tags, et orchestre les échanges. NWAK est l’outil idéal pour inspecter ces events avant publication.

6.4 Messages privés

Tu publies un event chiffré (NIP‑59). Le relay ne voit que la structure : il stocke l’event sans comprendre le contenu. Seul le destinataire peut déchiffrer. NWAK te permet de vérifier que la structure est correcte.

6.5 Multi‑relays

Tu peux envoyer le même event signé à plusieurs relays. Nostr n’est pas un “serveur central”, mais un ensemble de mémoires distribuées. NWAK te garantit que l’event que tu diffuses est cohérent, quel que soit le relay.

7. Les illusions du protocole

Les clients Nostr créent des illusions utiles, mais dangereuses si tu veux comprendre le protocole. NWAK les fait tomber une par une.

• Illusion : “Je poste un message.”
  Réalité : tu signes un JSON et tu le diffuses.
• Illusion : “Les relays valident le contenu.”
  Réalité : ils stockent ou rejettent selon leurs règles, sans interpréter ton intention.
• Illusion : “Les DMs sont invisibles.”
  Réalité : les events privés sont chiffrés, mais visibles comme structures.
• Illusion : “Un event = un post.”
  Réalité : un event est une structure cryptographique qui peut représenter un post, un ordre, un profil, un contrat, un message, un état.

8. Cartographie mentale du protocole Nostr

Pour penser Nostr correctement, il est utile de le voir comme un empilement de couches :

• Couche cryptographique — clés, signatures, hash
• Couche événementielle — events, kinds, tags
• Couche relay — stockage, diffusion, politiques
• Couche client — interface, timeline, UX
• Couche souveraine — vérification, audit, introspection (NWAK)

NWAK se situe au centre de la couche souveraine : c’est l’outil qui te permet de voir ce que les autres couches font réellement.

9. Exemples d’events commentés

Quelques exemples d’events typiques que tu peux coller dans NWAK pour les analyser.

9.1 Event Mostro (ordre)

{
  "kind": 38383,
  "created_at": 1778202000,
  "tags": [
    ["d", "cash-eur-100-fr-2026"],
    ["k", "buy"],
    ["f", "EUR"],
    ["s", "pending"],
    ["amt", "300000"],
    ["fa", "100"],
    ["pm", "Cash (rdv via Nostr)"],
    ["premium", "0"],
    ["network", "mainnet"],
    ["layer", "lightning"],
    ["z", "order"]
  ],
  "content": "",
  "pubkey": "<pubkey>",
  "id": "<id>",
  "sig": "<signature>"
}

Chaque tag a un rôle précis. NWAK te permet de vérifier que l’id et la sig sont cohérents avec ce contenu.

9.2 Event replaceable (NIP‑33)

{
  "kind": 30000,
  "created_at": 1778202000,
  "tags": [
    ["d", "profil-fr"],
    ["name", "Famas"],
    ["l", "fr"]
  ],
  "content": "{\"bio\":\"Texte souverain\"}",
  "pubkey": "<pubkey>",
  "id": "<id>",
  "sig": "<signature>"
}

9.3 Event minimal (note)

{
  "kind": 1,
  "created_at": 1778202000,
  "tags": [],
  "content": "Hello Nostr",
  "pubkey": "<pubkey>",
  "id": "<id>",
  "sig": "<signature>"
}

10. Erreurs fréquentes et diagnostics

NWAK est particulièrement utile pour diagnostiquer les erreurs suivantes :

• Signature invalide — la sig ne correspond pas à l’id et à la pubkey.
• ID incorrect — le hash ne correspond pas au contenu réel de l’event.
• Timestamp incohérent — created_at trop ancien ou trop futur.
• Tags mal formés — tags non conformes aux NIP (taille, structure, valeurs).
• Kind incorrect — usage d’un kind inadapté au protocole utilisé.
• Replaceable mal structuré — absence ou incohérence du tag d.
• Event Mostro incomplet — tags obligatoires manquants.
• Encodage bech32 incorrect — npub / nsec / nevent mal encodés.

Dans tous ces cas, NWAK sert de référence : ce qu’il considère comme valide est, par définition, conforme au protocole.

11. Cas d’usage avancés

• Vérifier un event Mostro — coller l’event, inspecter les tags, vérifier la signature.
• Comprendre un NIP — prendre un exemple d’event dans la spec, le passer dans NWAK, observer comment l’id est calculé.
• Déboguer un client maison — comparer ce que ton code génère avec ce que NWAK considère valide.
• Vérifier ce que tu signes via NIP‑07 — auditer les events générés par une extension.
• Auditer un event reçu — vérifier la signature, la structure, les tags, la cohérence globale.

12. Guide REQ — Requêtes essentielles

Quelques requêtes Nostr (REQ) utiles pour explorer le réseau en parallèle de NWAK.

Lire un event précis

["REQ","debug-1",{
  "ids":["<id>"]
}]

Lire tous les events d’un pubkey

["REQ","debug-2",{
  "authors":["<pubkey>"]
}]

Filtrer par kind

["REQ","debug-3",{
  "kinds":[1]
}]

Filtrer par tag

["REQ","debug-4",{
  "#d":["<valeur>"]
}]

Lire un replaceable event (NIP‑33)

["REQ","debug-5",{
  "kinds":[30000],
  "authors":["<pubkey>"]
}]

Lire un message privé (NIP‑59)

["REQ","debug-6",{
  "kinds":[1059],
  "authors":["<pubkey>"]
}]

Lire un order Mostro

["REQ","debug-7",{
  "kinds":[38383],
  "#z":["order"]
}]

13. Nostr en 2030 — NWAK comme outil de vérité

Nostr n’est pas un réseau social : c’est une infrastructure d’identité, de diffusion et de souveraineté. Les clients actuels changeront, les UX évolueront, les relays apparaîtront et disparaîtront. Ce qui restera, ce sont les events signés.

Dans cette perspective, NWAK garde une place centrale : c’est l’outil qui permet de vérifier, d’auditer, de comprendre. Tant que Nostr existera, il y aura besoin d’un microscope pour regarder ses events. NWAK est ce microscope.

Accès à l’application NWAK

Interface officielle :

https://nwak.fiatjaf.com

Dépôt GitHub (source officielle) :

https://github.com/fiatjaf/nwak