Neil, I am so appreciative that you approach things that way. This week I realized that Bark supports BOLT-12 offers and Lightning Addresses out of the box and was super impressed. I had avoided looking into those so far because I assumed it would be a massive headache to support. Huge win there.
So here’s the latest update, which is all about sending:
I expected it to be a big task to create really rich send experience, and it really is a lot with all the different payment formats we have, as well as handling multiple layers.
Goal here was to create a super simple send experience, no matter what payment information is thrown at the Send view:
Entry points
- Contact
- Clipboard, scan or URI click
- Manual entry
Address formats:
- Ark
- BOLT-11 Lightning invoice
- BOLT-12 Lightning offer
- Bitcoin
- Lightning address
Address pointers to resolve
- BIP-(3)21 URI
- BIP-353 human-readable address (points to a BIP-21)
Other logic
- Detect known addresses
- Check for network (mis)match (mainnet, testnet, signet, regtest)
- Per address, validate sufficient balance and estimate fee
- Transaction notes & tagging
It will probably take another week to really refine and polish this.
Do you think what’s in the video is a good direction? What’s good/bad/missing? Is it overkill? Let me know.
Lots of my thinking is based on content from the Bitcoin Design Guide, like the
Sending, Payment request formats, and Human readable address pages. Plan is to refine some of the content based on my learnings from Arké.