Currently, Nostrclient ties identifiers and links to the LNbits hosting sub-domain (e.g., lnbits.example.com), which makes it difficult to properly separate LNbits (hosted on a subdomain) to allow the Relay name to be configurable, much like the LNbits Nosterrelay extension does, removing tight coupling of the relays name to the LNbits hosting domain (e.g., wss://lnbits.example.com).
This lack of a "Public Identity Domain" configuration also forces users into complex reverse proxy and header-rewriting setups especially when using both Tor and HTTPS, especially in Nginx Proxy Manager (NPM), in order to provide a reliable, stable public identity. One that is highly reliant on Secure Certificates issued and managed in NPM for encryption, decryption, authorization, and especially authentication to various LNbits components being proxied to other relay types in Nosterrelay Extension or my Umbrel OS Private Relay Backup app.
A solution similar to the Nostrerelay, Nostr NIP-05, and LNURLP-PayLinks. extensions, to specify an explicit domain field to separate service location and public identity sub-domain and compliment LNBits Nostr Wallet Connect (NWC) Extension configuration with Nostrclient for dedicated NWC payment relay, minus Nostr social traffic relay data
POTENTIAL BUG: Tight-coupling may be contributing to a repeatable bug using the Nosterclient 'Test this endpoint' feature which I receive in both Primal and Amethyst Nostr clients as unencrypted strings, per attached screenshots and LNbits log snippet. I suspect it may also relate to complex reverse proxy and header-rewriting setups in NPM preventing the certs decryption from reaching Primal and Amethyst with a decrypted message vs an encrypted string as payload?
nosterclient-lnbits-logs.txt
Public Identity Domain for subdomains was originally referenced in open issue: lnbits/lnbits#3696 which resulted in closed issue lnbits/lnurlp#119 for LNURLP Extension
🙏
Currently, Nostrclient ties identifiers and links to the LNbits hosting sub-domain (e.g., lnbits.example.com), which makes it difficult to properly separate LNbits (hosted on a subdomain) to allow the Relay name to be configurable, much like the LNbits Nosterrelay extension does, removing tight coupling of the relays name to the LNbits hosting domain (e.g., wss://lnbits.example.com).
This lack of a "Public Identity Domain" configuration also forces users into complex reverse proxy and header-rewriting setups especially when using both Tor and HTTPS, especially in Nginx Proxy Manager (NPM), in order to provide a reliable, stable public identity. One that is highly reliant on Secure Certificates issued and managed in NPM for encryption, decryption, authorization, and especially authentication to various LNbits components being proxied to other relay types in Nosterrelay Extension or my Umbrel OS Private Relay Backup app.
A solution similar to the Nostrerelay, Nostr NIP-05, and LNURLP-PayLinks. extensions, to specify an explicit domain field to separate service location and public identity sub-domain and compliment LNBits Nostr Wallet Connect (NWC) Extension configuration with Nostrclient for dedicated NWC payment relay, minus Nostr social traffic relay data
POTENTIAL BUG: Tight-coupling may be contributing to a repeatable bug using the Nosterclient 'Test this endpoint' feature which I receive in both Primal and Amethyst Nostr clients as unencrypted strings, per attached screenshots and LNbits log snippet. I suspect it may also relate to complex reverse proxy and header-rewriting setups in NPM preventing the certs decryption from reaching Primal and Amethyst with a decrypted message vs an encrypted string as payload?
nosterclient-lnbits-logs.txt
Public Identity Domain for subdomains was originally referenced in open issue: lnbits/lnbits#3696 which resulted in closed issue lnbits/lnurlp#119 for LNURLP Extension
🙏