[Enhancement] Ability to amend a connection after creation

[EdiWeeks]

Description
Ability to amend a connection after creation

Screenshots

Version
LNbits:1.2.1
NWC Service Provider: 1.0.2

@BenGWeeks

[tlindi]

Still the same LNbits v1.3.1 and nwcprovider v1.0.2

[BenGWeeks]

Also related to: #23

[DoktorShift]

@BenGWeeks Nice Enhancement request. It´s mainly a UX concern i can agree again.

But on a protocol level NWC is not designed to be mutable.

An NWC string can be seen like an API key / API connection: once created, it is fixed.

NIP-47, spec as of today, does not define any mechanism to update existing connection. At leat i am not aware of it.

Additionally, LNbits does not store the NWC string itself. The string is derived on demand.
So any “edit” that affects protocol-level parameters would always result in a new NWC string, which the user must copy and reinsert into the client app.

On protocol level, LNbits constructs the NWC string from these components:

1. npub / nsec keypair
2. relay information
3. secret
4. lud16 (soon)

Example:
nostr+walletconnect://b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c&lud16=example@domain.com

Changing any of these necessarily changes the resulting NWC string.

Attached on the LNbits server level (but not part of the protocol string itself) are:

• description
• permissions
• expiration time

These server-side attachments are discussable in terms of UX, because they do not directly alter the encoded NWC URI.
However, anything that affects the protocol-level components cannot be edited in place and will always require issuing a new connection string and reinserting it on the client side.

Because of this, “editable connections” is not a easy task. Some considerations and security aspects have to be made.