NIP-05 support

[dechristopher]

Description

This PR introduces support for NIP-05 (nostr.json), enabling Haven to serve a /.well-known/nostr.json endpoint to provide identity verification and routing information for users of the relay.

Changes Made

• Added nip05.go: Implemented a dedicated NIP-05 handler that:
  • Reads and parses a local nostr.json config file
  • Validates NIP-05 identifier names, hex public keys, and relay websocket URLs
  • Filters and responds dynamically to ?name= query parameters
  • Configures proper CORS (Access-Control-Allow-Origin: *) and application/json headers
• Updated Routing in main.go: Registered the /.well-known/nostr.json endpoint and hooked it up to the nip05Handler
• Configuration Enhancements:
  • Added NIP05ConfigFile property to the global Config struct (config.go)
  • Added NIP05_CONFIG_FILE="nostr.json" to .env.example
  • Automatically whitelist configured NIP-05 identities
• Added Template File: Included an empty nostr.json template by default with names, relays, and nip46 blocks
• Fixed logic for relay list reading when empty file path provided
  • Achieves backwards compatibility for old Haven deployments with .env missing WHITELISTED_NPUBS_FILE and BLACKLISTED_NPUBS_FILE)

How to Test:

1. Make sure your .env contains NIP05_CONFIG_FILE="nostr.json" or whatever your file path is
2. Populate the local nostr.json with a valid test user (e.g., {"names": {"alice": "<64-char-hex-pubkey>"}})
3. Start Haven
4. Hit the endpoint: GET /.well-known/nostr.json?name=alice
5. Verify that it successfully returns Alice's public key with a 200 OK status and the appropriate CORS headers
6. Include invalid identifiers to verify that it responds with a 400
7. Include missing identifiers to verify that it responds with a 404

[aaccioly]

Hi @dechristopher, thanks for all the effort you put into this PR. I would like to say upfront that, in different circumstances, NIP-05 would be a very cool addition to HAVEN; one that was requested many times by Haven's users.

Unfortunately, for several reasons, both Haven’s creator and I have decided to declare Haven feature complete and to accept only bug fixes for Haven in Bitvora's repository. No new features are being accepted in this repository at this time.

You can check out @barrydeen’s announcement here:
https://njump.to/nevent1qqsyunsp6s50cxjkah0lfhzn06yu3nj5z7r3hveth7k58kfrn5hunqqpzpmhxue69uhkummnw3ezumt0d5hsyg8zenmu7gzq8ulj5jj4kv50ph3muwz43f747vmr9ld2alrjdswgavpsgqqqqqqs3zgajy

If you are willing to experiment and contribute to something new by Haven’s original creator, maybe have a look at what he is working on here:
https://github.com/barrydeen/moar

I will soon add a message to the README so that the current status of Haven’s Bitvora repository is clearer to end users and contributors.

Despite not being able to accept your contribution in this repository, I would like to emphasise that Haven is still 100% MIT-licensed open source software and that all developers are welcome to fork it. In fact, I would highly encourage you to advertise your fork with NIP-05 support on Nostr, perhaps using the #haven hashtag so that other users get to know about it.

Who knows? It is just the nature of FOSS that one of Haven’s forks may evolve into the go-to next generation relay that everyone gravitates towards. It would certainly make me happy to see Haven evolve and find a life of its own through its community and a new group of developers willing to maintain it beyond the Bitvora era.