nostr: never advertise a rendezvous we are not registered at

[Bitflash-sh]

The bug

BtfActiveRelay() fell back to vBtfMeetingRelays[0] whenever registration had not completed yet:

CRITICAL_BLOCK(cs_activeRelay)
    if (!strBtfActiveRelay.empty())
        return strBtfActiveRelay;
if (!vBtfMeetingRelays.empty())
    return vBtfMeetingRelays[0];   // a relay we are NOT registered at

strBtfActiveRelay is only set by BtfSetActiveRelay(), called from ThreadBtfAccept after registration actually succeeds (net.cpp). But ThreadNostrSeed and ThreadBtfAccept are started in parallel:

if (_beginthread(ThreadNostrSeed, 0, NULL) == -1)          // publishes descriptors
...
if (_beginthread(ThreadBtfAccept, 0, NULL) == -1)          // performs registration

So at boot the fallback is what PublishDescriptor() writes into meeting_node. Worse, ThreadNostrSeed opens with a one-time self-test that publishes the descriptor to every relay in the list before the seed loop starts — so the bad value gets fanned out network-wide.

Every peer that resolves such a descriptor dials a rendezvous the node was never registered at. When the first seed happens to be down, that is a guaranteed wasted dial for every peer that reads it. 92.246.128.180 — first in the seed list — was down for part of today, which is how this surfaced.

The "rendezvous-pending" guard already in PublishDescriptor was dead code: BtfActiveRelay() could not return empty while the seed list was non-empty.

The fix

• BtfActiveRelay() returns only the relay ThreadBtfAccept confirmed, empty until then.
• PublishDescriptor() skips publishing while it is empty. The seed loop republishes every pass, so the only cost is the delay until registration succeeds.
• The self-test waits up to 60s for registration, so it still measures the publish/resolve chain instead of losing the race against it.

Second fix, same file

The WebSocket handshake reader did a bare break on oversized headers:

resp += c;
if (resp.size() > 4096) break;
}
if (resp.find(" 101 ") == string::npos)
    return error("Nostr: handshake refused by %s", host.c_str());

The status line is read first, so " 101 " still matched and the function returned success — with the socket parked in the middle of the header block. The caller then handed that socket to the frame parser, which read leftover HTTP as WebSocket frames. Now it errors out, and the cap is 8192 because relays behind Cloudflare send large header blocks.

Not done here, on purpose

I was going to drop relay.damus.io and relay.nostr.band from the public relay list, since both spam the log. Checking first:

• relay.nostr.band — TCP connect fails from two different networks. Genuinely down.
• relay.damus.io — works. Sending byte-for-byte the same handshake this code builds returns HTTP/1.1 101 Switching Protocols.

So the damus failures are ours to explain, not a reason to delete the relay. Left the list alone.

Testing

Full Windows build green (MSYS2 UCRT64). Touches only Nostr discovery — no consensus, wallet, or P2P message handling.

[Bitflash-sh]

Field evidence for this, from trying to test something else.

Two fresh nodes on one machine, node B dialing node A by .btf. B resolved A
fine and then failed every single dial:

[net] trying m2lgnyqunvfmzg3z4w4nl7aaywdpmksbsmmdb5nfye4hyl6pm4wuiua.btf
[net] ConnectNodeBtf: tunnel to m2lgny...btf via 92.246.128.180:8434 failed
[nostr] (199 similar in 3s, last: Nostr: discovered .btf peer m2lgny...btf)

A's descriptor advertised 92.246.128.180:8434 — vBtfMeetingRelays[0], the
fallback. A's own log contains no ThreadBtfAccept started and no rendezvous
registration at all, so it was never reachable there. Its self-test still
reported success, because publish/resolve/verify all work fine on a descriptor
that points nowhere:

[nostr] Nostr: .btf self-resolve OK via wss://nos.lol (meeting_node=92.246.128.180:8434, ...)

B burned 199 rediscoveries and a continuous dial loop on a node that could not
be reached. That is the cost this PR removes, measured.

There is a second effect worth folding in. ThreadBtfAccept picks its relay
at random:

iRelay = (size_t)GetRand(relays.size());

while the fallback always hands out vBtfMeetingRelays[0]. So even when
registration does succeed, the published meeting node is likely the wrong one
until the seed loop republishes — with three seeds plus discovered relays, most
of the time. The window this PR closes is therefore much wider than "briefly at
boot": it is "until the next republish, usually pointing at the wrong relay".

Separately, and not addressed here: a node whose ThreadBtfAccept never runs
still publishes descriptors and still looks healthy to itself. Worth its own
look — I have not established why A's thread did not start.