Nostr note validation added to nip01

This commit is contained in:
2025-08-19 06:59:04 -04:00
parent 1da4f6751e
commit 77d92dbcf9
17 changed files with 811 additions and 36 deletions

129
todo.md
View File

@@ -1,51 +1,110 @@
### __Tier 1: Foundational & High-Priority NIPs (The Essentials)__
# Nostr Event Validation Implementation Checklist
These are fundamental features that most Nostr applications rely on.
## Implementation Plan: NIP-001 Event Validation
| NIP | Description | `nostr_core_lib` Status | `nak` / `nostr-tools` Status | Recommendation | | :-- | :--- | :--- | :--- | :--- | | __NIP-04__ | __Encrypted Direct Messages__ | ❌ __Missing__ | ✅ __Supported__ | __High Priority.__ Essential for private communication. The `encrypt` / `decrypt` functions are a must-have. | | __NIP-05__ | __Mapping to DNS-based Names__ | ❌ __Missing__ | ✅ __Supported__ | __High Priority.__ Needed for user-friendly identifiers (e.g., `user@domain.com`). We should add a function to verify these. | | __NIP-07__ | __`window.nostr` for Web Browsers__ | ❌ __Missing__ | ✅ __Supported__ | __Medium Priority (for C).__ This is browser-specific, but we should consider adding helper functions to format requests for browser extensions that implement NIP-07. | | __NIP-11__ | __Relay Information Document__ | ❌ __Missing__ | ✅ __Supported__ | __High Priority.__ Crucial for client-side relay discovery and capability checking. A function to fetch and parse this JSON is needed. | | __NIP-21__ | __`nostr:` URI Scheme__ | ❌ __Missing__ | ✅ __Supported__ | __Medium Priority.__ Useful for linking to profiles, events, etc. from outside Nostr clients. We should add parsing and generation functions. | | __NIP-57__| __Lightning Zaps__ | ❌ __Missing__ | ✅ __Supported__ | __High Priority.__ Zaps are a cornerstone of value-for-value on Nostr. We need functions to create and verify zap request events (Kind 9734) and zap receipt events (Kind 9735). |
### 1. Create Test Suite `tests/nip01_validation_test.c` (FIRST - Test-Driven Development)
- [x] Use `nak` command line tool to generate valid test events
- [x] Create test vectors with known valid events
- [x] Test valid event validation (should pass)
- [x] Test invalid structure cases:
- Missing required fields
- Wrong field types
- Invalid hex string lengths
- Invalid timestamps
- Invalid kind values
- Invalid tag structures
- [x] Test invalid cryptographic cases:
- Wrong event ID
- Invalid signature
- Mismatched pubkey
- [x] Test edge cases and boundary conditions
- [x] Follow TESTS POLICY: Show expected vs actual values, print full JSON events
---
### 2. Add Error Codes to `nostr_core/nostr_common.h`
- [x] Add validation-specific error codes after existing NIP error codes (line ~21):
```c
#define NOSTR_ERROR_EVENT_INVALID_STRUCTURE -30
#define NOSTR_ERROR_EVENT_INVALID_ID -31
#define NOSTR_ERROR_EVENT_INVALID_PUBKEY -32
#define NOSTR_ERROR_EVENT_INVALID_SIGNATURE -33
#define NOSTR_ERROR_EVENT_INVALID_CREATED_AT -34
#define NOSTR_ERROR_EVENT_INVALID_KIND -35
#define NOSTR_ERROR_EVENT_INVALID_TAGS -36
#define NOSTR_ERROR_EVENT_INVALID_CONTENT -37
```
### __Tier 2: Advanced & Ecosystem NIPs (Expanding Capabilities)__
### 3. Update Error String Function in `nostr_core/nostr_common.c`
- [ ] Add cases for new error codes in `nostr_strerror()` function
These features enable more complex interactions and integrations.
### 4. Add Function Declarations to `nostr_core/nip001.h`
- [x] Add validation function declarations after existing function:
```c
// Event validation functions
int nostr_validate_event_structure(cJSON* event);
int nostr_verify_event_signature(cJSON* event);
int nostr_validate_event(cJSON* event);
```
| NIP | Description | `nostr_core_lib` Status | `nak` / `nostr-tools` Status | Recommendation | | :-- | :--- | :--- | :--- | :--- | | __NIP-25__ | __Reactions__ | ❌ __Missing__ | ✅ __Supported__ | __Medium Priority.__ Relatively simple to implement (Kind 7 events) and common in social clients. | | __NIP-26__ | __Delegated Event Signing__| ❌ __Missing__| ✅ __Supported__| __Medium Priority.__ Allows for one key to authorize another to sign events, useful for temporary or restricted keys. | | __NIP-44__ | __Versioned Encryption (v2)__ | ❌ __Missing__ | ✅ __Supported__ | __High Priority (along with NIP-04).__ Newer standard for encryption. We should aim to support both, but prioritize NIP-44 for new applications. | | __NIP-46__ | __Nostr Connect (Remote Signing)__| ❌ __Missing__ | ✅ __Supported__ | __Low Priority (for C library).__ More of an application-level concern, but we could provide structures and helpers to facilitate communication with signing "bunkers". | | __NIP-47__ | __Nostr Wallet Connect__ | ❌ __Missing__ | ✅ __Supported__| __Low Priority (for C library).__ Similar to NIP-46, this is primarily for app-level integration, but helpers would be valuable. | | __NIP-58__ | __Badges__ | ❌ __Missing__ | ✅ __Supported__ | __Medium Priority.__ Defines how to award and display badges (Kind 30008/30009 events). | | __NIP-94__ | __File Metadata__ | ❌ __Missing__ | ✅ __Supported__| __Medium Priority.__ For events that reference external files (images, videos), providing metadata like hashes and URLs. | | __NIP-98__ | __HTTP Auth__| ❌ __Missing__ | ✅ __Supported__| __High Priority.__ Allows services to authenticate users via a Nostr event, a powerful tool for integrating Nostr identity with web services. |
### 5. Implement Functions in `nostr_core/nip001.c`
- [ ] **`nostr_validate_event_structure()`** - Structure validation:
- Check required fields exist: id, pubkey, created_at, kind, tags, content, sig
- Validate field types (strings, numbers, arrays)
- Validate hex string formats (id: 64 chars, pubkey: 64 chars, sig: 128 chars)
- Validate created_at is valid timestamp
- Validate kind is valid integer (0-65535)
- Validate tags is array of string arrays
- Validate content is string
---
- [ ] **`nostr_verify_event_signature()`** - Cryptographic verification:
- Generate serialized event string: `[0,<pubkey>,<created_at>,<kind>,<tags>,<content>]`
- Calculate SHA-256 hash of serialized event
- Convert hash to hex string and compare with event.id
- Verify Schnorr signature using existing `nostr_schnorr_verify()` from utils.h
- Use hex conversion functions from utils.h
### __Tier 3: Specialized & Less Common NIPs (Future Considerations)__
- [ ] **`nostr_validate_event()`** - Complete validation:
- Call `nostr_validate_event_structure()` first
- If structure valid, call `nostr_verify_event_signature()`
- Return appropriate error codes
| NIP | Description | `nostr_core_lib` Status | `nak` / `nostr-tools` Status | Recommendation | | :-- | :--- | :--- | :--- | :--- | | __NIP-18__| __Reposts__ | ❌ __Missing__ | ✅ __Supported__| __Low Priority.__ Simple to implement (Kind 6 events) but less critical than other features. | | __NIP-28__| __Public Chat Channels__| ❌ __Missing__ | ✅ __Supported__| __Low Priority.__ Defines event kinds for creating and managing public chat channels. | | __NIP-39__| __External Identities__ | ❌ __Missing__ | ✅ __Supported__| __Low Priority.__ For linking a Nostr profile to identities on other platforms like GitHub or Twitter. | | __NIP-42__ | __Relay Authentication__ | ❌ __Missing__| ✅ __Supported__| __Medium Priority.__ For paid relays or those requiring login. Essential for interacting with the full relay ecosystem. | | __NIP-43__| __Musig2 (Multisig)__ | ❌ __Missing__ | ✅ __Supported__| __Low Priority.__ A very powerful but niche feature. Complex to implement correctly. |
### 6. Update Build System
- [ ] Ensure new test compiles with existing build.sh
- [ ] Test compilation of all new code
---
### 7. Integration Testing
- [ ] Test with real Nostr events from network
- [ ] Test with events created by existing `nostr_create_and_sign_event()`
- [ ] Verify compatibility with existing relay functions
### __Proposed Roadmap__
## Technical Implementation Details
Based on this analysis, I recommend the following roadmap, prioritized by impact and foundational need:
### Required Dependencies (Already Available):
- `nostr_sha256()` from `nostr_core/utils.h`
- `nostr_schnorr_verify()` from `nostr_core/utils.h`
- `nostr_hex_to_bytes()` from `nostr_core/utils.h`
- `nostr_bytes_to_hex()` from `nostr_core/utils.h`
- cJSON library for JSON parsing
1. __Immediate Next Steps (High-Impact Basics):__
### Validation Logic Based on NIP-01 and nostr-tools Reference:
1. **Structure Validation**: Fast checks on JSON structure and basic format
2. **Cryptographic Validation**: Expensive signature verification only after structure passes
3. **Two-tier approach**: Allows early exit on malformed events
- __Implement NIP-04 & NIP-44:__ Encrypted messaging is a huge gap.
- __Implement NIP-11:__ Fetching and parsing relay info documents.
- __Implement NIP-05:__ DNS-based name verification.
- __Implement NIP-57:__ Create and verify Zap events.
- __Implement NIP-98:__ HTTP Auth for web services.
### Error Handling Strategy:
- Return specific error codes for different validation failures
- Enable caller to understand exactly what failed
- Maintain consistency with existing error code patterns
2. __Phase 2 (Ecosystem & Social Features):__
## Files to Modify:
- `nostr_core/nostr_common.h` (add error codes)
- `nostr_core/nostr_common.c` (update error strings)
- `nostr_core/nip001.h` (add function declarations)
- `nostr_core/nip001.c` (implement functions)
- `tests/nip01_validation_test.c` (create new file)
- __Implement NIP-25:__ Reactions.
- __Implement NIP-26:__ Delegation.
- __Implement NIP-42:__ Relay Authentication.
- __Implement NIP-21:__ `nostr:` URI handling.
- __Implement NIP-58:__ Badges.
3. __Phase 3 (Advanced & Specialized Features):__
- __Implement NIP-18:__ Reposts.
- __Implement NIP-43:__ Musig2 (this is a big one).
- Add helpers for NIP-07, NIP-46, and NIP-47.
What are your thoughts on this assessment and proposed roadmap? We can adjust the priorities based on your goals for the library. Once we have a plan you're happy with, I can start implementing the first features when you're ready to switch to
Act Mode (⌘⇧A).
## Testing Priority:
1. Structure validation with malformed events
2. Cryptographic validation with tampered events
3. Valid event validation end-to-end
4. Integration with existing event creation functions
5. Performance testing with large numbers of events