Store LNURL in DID data when publishing Lightning

[macterra]

Summary

When publishLightning adds the #lightning service entry to the DID document, it should also store a bech32-encoded LNURL in the DID's data. This makes the payment endpoint discoverable in a standard format that any LNURL-aware client can use.

Motivation

The #lightning service entry in the DID document is an Archon-specific convention. By also publishing the LNURL (bech32 encoding of the service endpoint URL), the DID becomes interoperable with the broader LNURL ecosystem.

Proposed behavior

publishLightning would bech32-encode the Drawbridge invoice endpoint URL and store it in the DID's data:

{
  "lightning": {
    "lnurl": "lnurl1dp68gurn8ghj7..."
  }
}

The LNURL is derived from the same endpoint used in the #lightning service entry (e.g., http://<onion>:4222/api/v1/invoice/<did>).

Considerations

• The current .onion endpoint requires Tor — most standard Lightning wallets can't reach it. The LNURL will primarily be useful to other Tor-capable clients until a clearnet proxy (like archon-social LUD-16) is available.
• unpublishLightning should remove the LNURL data as well.
• A bech32 encoding library will be needed (e.g., bech32).

Related

• LUD-16 Lightning Address resolution for archon-social names archon-social#2 — LUD-16 resolution (clearnet path)
• Support LUD-16 Lightning Addresses in zapLightning #160 — Support LUD-16 Lightning Addresses in zapLightning
• feat: Lightning zap — send sats to a DID #155 — Lightning zap via Tor (current implementation)