summaryrefslogtreecommitdiffstats
path: root/internal/storage/storage.go
Commit message (Collapse)AuthorAgeFilesLines
* feat: add storage stats and average latency metricsbndw3 days1-2/+34
| | | | | | | | | | | | | | | | | | | | | | Track and display storage and performance metrics that were previously showing zeros. Storage metrics: - Add GetStats() method to storage returning event count and DB size - Store database file path for size calculation - Update metrics every 30 seconds via goroutine in main.go - Display event count and DB size (MB) in dashboard Performance metrics: - Calculate average latency from histogram sum/count metrics - Display as milliseconds in dashboard - Formula: (duration_sum / duration_count) * 1000 Missing metrics (deferred): - Connections: requires connection lifecycle tracking (gRPC + WebSocket) - Deletions: count would need API change to ProcessDeletion Dashboard now shows accurate storage stats and request latency!
* fix: optimize SQLite connection pooling for single-writer architecturebndw3 days1-0/+6
| | | | | | | | | | | | | | | | | | | | | Remove misleading max_connections config option and properly configure SQLite connection pooling in the storage layer. Changes: - Set MaxOpenConns(1) for optimal SQLite performance - Set MaxIdleConns(1) to keep connection alive - Set ConnMaxLifetime(0) to never close connection - Remove max_connections and max_lifetime from DatabaseConfig - Update docs to clarify SQLite's single-writer architecture Rationale: SQLite is an embedded database with a single-writer lock. Multiple connections cause lock contention and reduce performance. WAL mode allows concurrent reads from the same connection, making connection pooling unnecessary and counterproductive. This change makes the configuration clearer and ensures optimal SQLite performance by using a single long-lived connection.
* refactor: simplify deletion handling (remove NIP-09 processing)bndw3 days1-12/+0
| | | | | | | | | | Remove deletion processing logic in favor of simpler approach: - Remove deletions table from schema - Delete deletions.go and deletions_test.go - Remove ProcessDeletion from EventStore interface - Kind 5 events now stored like any other event (no special handling) - Update storage test to expect 2 tables instead of 3 - All 41 tests passing
* feat: implement NIP-09 (deletions) and NIP-11 (relay info)bndw3 days1-2/+2
| | | | | | | | | | | | | | | | | | | | | | NIP-11 (Relay Information Document): - Serves relay metadata at GET / with Accept: application/nostr+json - Returns name, description, supported NIPs, limitations - CORS headers for browser compatibility NIP-09 (Event Deletion): - Kind 5 events delete events referenced in 'e' tags - Only authors can delete their own events - Soft delete (marks deleted=1) - Records deletion in deletions table - Works across all protocols (gRPC, Connect, WebSocket) Fixed deletions schema: - deleted_event_id as PRIMARY KEY (not deletion_event_id) - Allows one deletion event to delete multiple events 3 new tests, 44 total tests passing Supported NIPs now: 1, 9, 11
* feat: add SQLite storage layer with binary-first event persistencebndw4 days1-0/+150
Storage implementation: - Concrete type with constructor (consumer-side interfaces) - Event storage: protobuf + zstd-compressed canonical JSON - Schema: events, deletions, replaceable_events, auth_challenges, rate_limits - WAL mode, STRICT typing, optimized indexes - Methods: StoreEvent, GetEvent, GetEventWithCanonical, DeleteEvent Dependencies: - modernc.org/sqlite v1.45.0 (pure Go SQLite driver) - github.com/klauspost/compress v1.18.4 (zstd compression) 366 lines, 10 tests passing