We could allow users to also use their Kosmos account to receive lightning payments (through the lightning address spec)
For this we either could allow users to connect their node or provide a custodial wallet (though something like LNDHub)
There are some Lightning address implementations we could use. For example:
@bumi and I talked about the best solutions for implementing this and came up with the rough solution:
Use LndHub for Lightning accounts for each kosmos.org account. This allows showing a QR code to connect BlueWallet with your Kosmos account wallet
Add a wallet page to https://accounts.kosmos.org, which uses the LndHub API to show e.g. the setup QR Code, or even allows to send and withdraw sats (later)
Move the static site on kosmos.org from 5apps to a VM. This has to be done for Webfinger anyway
Add a lightweight service for the Lightning Address HTTP flow, maybe just a Lua module for Nginx
The service could also create the actual LndHub wallet for a user only when the first request for the address is coming in. Could also just be done as a signup service in akkounts though.
I’m having a stab at setting this up. The next logical step is to add easy LN payments to Hyperchannel. Because with XMPP, you could automatically show that a JID can receive sats and even manage the sending workflow with that, without the user having to think about any of the underlying tech. Pretty awesome!
Just got struck by the obvious thing we somehow didn’t see: we can turn XMPP room JIDs into Lightning addresses, so you can send sats to a room/project! Then we can use XMPP room permissions for managing access to that wallet.
I have been using my Kosmos wallet to pay for things here in El Salvador for the last 2 days. Payments were always fast, and never failed.
However, when I tried to use the “refill with external wallet” option in Blue Wallet, which gives you an on-chain address for the LND node, lndhub didn’t pick up my transaction and update my balance. So maybe don’t use that feature, until we know what’s going on there.
I was thinking about email forwarding again.
And it seems my email provider is supporting “split deliveries” to forward emails if no account is configured. that means I can forward an email to a subdomain and for example use AWS SES to receive that email and then use Lambda to forward that email to the user’s email.
This uses AWS services (but thus is also cheap and requires minimum setup) but this could be implemented with any email provided that somehow supports incoming emails (e.g. webhooks for incoming emails)