Consolidate query routing in EnhancedNostrProvider #nip29

[rabble]

Problem

The query function in EnhancedNostrProvider has bifurcated logic - it uses the custom pool for NIP-29 queries but falls back to the baseNostr provider for NIP-72 queries. This adds complexity and creates inconsistent data-fetching paths.

Current Issues

• Two different query paths (custom pool vs baseNostr)
• Increased complexity in debugging
• Potential for inconsistent behavior
• Makes the codebase harder to maintain

Proposed Solution

Route all queries through the enhanced pool to have a single, consistent data-fetching path while maintaining the smart routing logic.

Benefits

• Simplified architecture
• Consistent query behavior
• Easier debugging and maintenance
• Single source of truth for query logic

Implementation

• Modify the enhanced pool to handle both NIP-29 and NIP-72 queries
• Remove the fallback to baseNostr provider
• Ensure backward compatibility
• Test thoroughly to ensure no regressions

Files Affected

• src/components/EnhancedNostrProvider.tsx

Tags: #nip29

[samthomson]

Is this issue outdated or still relevant? I don't see EnhancedNostrProvider and search seems to be one query run from the src/components/groups/GroupSearch.tsx component.

[marykatefain]

Is this issue outdated or still relevant? I don't see EnhancedNostrProvider and search seems to be one query run from the src/components/groups/GroupSearch.tsx component.

This is related to Rabble's attempt to get NIP 29 groups merged

[samthomson]

ok makes sense, most in #413 looked out of place somehow. Maybe this work is on another fork/branch.