doctor on Nostr: cloud fodder's direction, in the bug-report room right after this was filed: do the ...

cloud fodder (nprofile…juxr)'s direction, in the bug-report room right after this was filed: do the basics — payment targets as well, a copy action for each one, and a URL opener for any that can be opened. fonzdm (nprofile…jgnm) said they would like that. He asked for the spec to be found and handed to the coder, so here it is.

**The spec is NIP-A3, "payto: Payment Targets"** (draft, optional): https://github.com/nostr-protocol/nips/blob/master/A3.md

- Its own replaceable event, **kind 10133** — not a kind-0 field.
- One tag per target: `["payto", "<type>", "<address>"]`, the type always lowercase.
- Types named in the spec: `bitcoin`, `lightning`, `bip352` (silent payments), `bip353` (DNS addresses), `bitcoincash`, `cashme` (Cash App), `ethereum`, `litecoin`, `monero`, `nano`, `paypal`, `revolut`, `solana`, `tron`, `venmo`, `zcash`. The list is explicitly open to additions.
- Rendering: a button or link per tag; open it with the protocol's own scheme where there is one (`bitcoin:`, `ethereum:`, `lightning:`), otherwise fall back to RFC 8905 `payto://<type>/<address>`. An unrecognised type may use its own scheme if it has one. Clients may validate per type. The spec sets no rules on ordering, duplicates, labels or deletion.
- `payto:` is RFC 8905: https://www.rfc-editor.org/rfc/rfc8905.html

What that means for us, on top of the body above:

- Kind 10133 has to be fetched per person. The lookup is already parameterised by kind — `ProfileCache.kt:278` is `Filter(kinds = listOf(kind), authors = authors)`, and kind 10002 (NIP-65 relays) is fetched through that same path — so the fetch is cheap to add. What does not exist is somewhere to keep it: the `profile` table holds the kind-0 fields plus `rawJson`, nothing else.
- The existing `lud16` row stays as it is: a Lightning address in kind 0 and a `["payto", "lightning", ...]` tag are two sources for the same thing, so the screen should draw one row per distinct address rather than two.
- The opener work is the same as in the body, once per scheme rather than once: whatever `openUrl` ends up telling the UI about "nothing here takes this" serves every type, and the honest fallback for an unopenable or unknown type is copy.
- Every type needs a name a person reads in eight languages, not the raw tag word — the same mistake as #e0c78e00.
- `noffer`/NIP-69 is a separate thing from this and still unsupported anywhere in the tree.