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

Emphasize "Nostr Implementation Guidelines" section

Browse Source
This commit is contained in:
Alex Gleason 2025-06-13 20:59:25 -05:00
parent 062545d061
commit df40d30f15
No known key found for this signature in database
GPG Key ID: 7211D1F99744FBB7
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
CONTEXT.md
View File

@ -110,12 +110,16 @@ This project comes with custom hooks for querying and publishing events on the N
### Nostr Implementation Guidelines ### Nostr Implementation Guidelines
- Before implementing features on Nostr, use the `nostr__read_nips_index` tool to see what kinds are currently in use across all NIPs. **⚠️ Important: These guidelines must be followed for all Nostr-related implementations to ensure proper interoperability.**
- If any existing kind or NIP might offer the required functionality, use the `nostr__read_nip` tool to investigate. Several NIPs may need to be read before making a decision.
- If there are no existing suitable kinds, new kind numbers can be generated with the `nostr__generate_kind` tool. - **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. 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 #### Choosing Between Existing NIPs and Custom Kinds
When implementing features that could use existing NIPs, follow this decision framework: When implementing features that could use existing NIPs, follow this decision framework: