saulteafarmer/mkstack
1
0
Fork 0
mirror of https://gitlab.com/soapbox-pub/mkstack.git synced 2025-08-27 04:59:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Simplify "Nostr Implementation Guidelines" again

Browse Source
This commit is contained in:
Alex Gleason 2025-06-13 22:09:06 -05:00
parent df40d30f15
commit 8559a004e8
No known key found for this signature in database
GPG Key ID: 7211D1F99744FBB7
1 changed files with 1 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
CONTEXT.md
View File

@ -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: