fix(desktop): use strict kind:10050 for tier-1 AUTH classification

DesktopAuthCoordinator.selfApprovedRelaysFor was calling the lenient
User.dmInboxRelays() helper, whose NIP-65-read fallback silently
expanded the tier-1 auto-allow set to include every relay in the
user's read markers. That defeated the tier-2 prompt for any AUTH-
required relay the user happened to have in NIP-65 — such as
wss://pyramid.fiatjaf.com, which never surfaced a banner during
manual testing because the coordinator was auto-signing it as
tier-1.

Switch to dmInboxRelaysStrict() (added in the earlier pre-send
alignment fix) so tier-1 is truly kind:10050 only. The KDoc already
promised strictness ("write/read relays are NOT included") — this
just makes the code match.

Surfaced during manual T3 testing 2026-07-06 with an account whose
NIP-65 outbox included pyramid.fiatjaf.com.
This commit is contained in:
nrobi144
2026-07-09 07:33:43 +03:00
parent 33417d8a58
commit 8c844d76db
@@ -145,12 +145,18 @@ class DesktopAuthCoordinator(
}
private fun selfApprovedRelaysFor(pubKeyHex: String): Set<NormalizedRelayUrl> {
// Tier-1 = the user's own NIP-17 DM-inbox (kind:10050). Conservative
// Tier-1 = the user's own NIP-17 DM-inbox (kind:10050). Strict
// by design — write/read relays (NIP-65 kind:10002) are NOT included,
// because the user may have read-only relays they don't intend to
// identify themselves to via AUTH.
//
// MUST use dmInboxRelaysStrict (kind:10050 only) rather than the
// lenient dmInboxRelays helper, which falls back to NIP-65 read
// relays and would silently expand tier-1 to include every relay
// in the user's outbox. That defeats the tier-2 prompt for any
// relay in the user's normal read set.
val user = localCache.getOrCreateUser(pubKeyHex)
return user.dmInboxRelays()?.toSet() ?: emptySet()
return user.dmInboxRelaysStrict()?.toSet() ?: emptySet()
}
private suspend fun signWithPolicy(