Understood, but on the Nostr level it just means relaying a slightly different address string, right? Seems simple, why do Nostr clients care about the Zap address format?

I understood Alby as only a custodial service, my mistake, I apologize. Still BOLT12 seems like the much simpler solution, or do I miss something here?

I fail to understand what prevents clients from simply giving users free choice over the Zap address type they enter.

nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 Where lies the challenge in implementing this:

https://github.com/damus-io/damus/issues/683 , why does BOLT12 have no priority on the roadmap?

Just allow any address string, why filter at all? Leave formatting checks to the wallets.

Custodial wallets will likely never offer a sensible KYC-free Zap solution. I would disable Zaps in your case until a suitable Nostr client adds BOLT12 Zap address support and you can directly receive Zap payments in a non custodial mobile LN wallet like Phoenix Wallet.

Cases like yours arguably show exactly why it never made much sense to ship custodial Zaps in the first place and hopefully provide some motivation to add BOLT12 support in Nostr clients rather sooner than later.

Haha, I get it

It can actually help to intently look at the process and face the reality head on.

I like apathy for it, more than indifference tonally. I think I keep circling around something between calculatedness, callousness and coldness. Also hate, while popularly construed as sign of attachment, seems like a classically true and valid choice.

I have only heard the line in the "Into the Wild" film. Did people know this as a common saying before that?

I submit 'objectiveness', explained as faithlessness towards someone or something. The absence or rejection of any personal impulse.

To what occasion?

I found the entire season of Those About to Die really engaging, despite some occasionally forced contrivances. At least the characters had some tangible edge and ambitions. I would prefer to see similarly interesting entertainment from outside the studio system, but I still appreciate finding halfway decent storytelling anywhere today.

Also, the RogerEbert site has a pretty fair review on the show.

bech32 describes the nsec-npub key format right?

Does the format generally allow to create one time derivation keys, similar to eg. the WebAuthn keys, in a reasonably easy way?

Could bech32 keys practically conventional identifiers like phone numbers and IP addresses, would it make sense to "bech32 all the things"?

it's so easy to laugh

it's so easy to hate

it takes guts to be gentle and kind

Just from a user perspective I would want this so much.

Also in combination with at least one versatile, open source "security key" electronics design suitable for fitting into everyday wearables, eg. pendants, rings.

Have been wondering whether FIDO keys like TKey and OpenSK offer some starting point there.

Or make the suggestions a full, scrollable list instead of a truncated selection.

What speaks against enabling to type @ + npub for tagging?

That way users can make sure they tag the intended profile in all cases.

I tested this in Primal earlier, they convert the pure npub strings into tags. I just prefer running Damus out of the current iOS clients.

Alright, I fail to see a way to tag a user through their npub in nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955, and just typing "fiatjaf" comes up with way too many suggestions, none of them the actual fiatjaf

trying the user tag again in another format

@npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6

Which aspect looks unfeasible?

To me it makes sense when npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6 argues that protocol level unique basic note, event, IDs maintain simplicity, so pointing notes at other notes for replacement seems like a sensible next step.

Perhaps you want to check out this discussion of the issue on the Nostr repo page. https://github.com/nostr-protocol/nips/issues/1036

At least superficially I find the idea of replace event tags pointing to a previous ID convincing.