From 8559a004e86008a37ae59c029e7fe8627345a890 Mon Sep 17 00:00:00 2001 From: Alex Gleason Date: Fri, 13 Jun 2025 22:09:06 -0500 Subject: [PATCH] Simplify "Nostr Implementation Guidelines" again --- CONTEXT.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/CONTEXT.md b/CONTEXT.md index dc1dc95..cb72d32 100644 --- a/CONTEXT.md +++ b/CONTEXT.md @@ -110,16 +110,12 @@ This project comes with custom hooks for querying and publishing events on the N ### Nostr Implementation Guidelines -**⚠️ Important: These guidelines must be followed for all Nostr-related implementations to ensure proper interoperability.** - -- **Always** use the `nostr__read_nips_index` tool before implementing any Nostr features to see what kinds are currently in use across all NIPs. +- Always use the `nostr__read_nips_index` tool before implementing any Nostr features to see what kinds are currently in use across all NIPs. - If any existing kind or NIP might offer the required functionality, use the `nostr__read_nip` tool to investigate thoroughly. Several NIPs may need to be read before making a decision. - Only generate new kind numbers with the `nostr__generate_kind` tool if no existing suitable kinds are found after comprehensive research. Knowing when to create a new kind versus reusing an existing kind requires careful judgement. Introducing new kinds means the project won't be interoperable with existing clients. But deviating too far from the schema of a particular kind can cause different interoperability issues. -**The decision between existing NIPs and custom kinds is a critical architectural choice that directly impacts interoperability and adoption.** - #### Choosing Between Existing NIPs and Custom Kinds When implementing features that could use existing NIPs, follow this decision framework: