#[0]​ I wonder if the NWC connection string should include your lightning address as an optional argument? Then damus could automatically add that to their profile when they connect a wallet.

DJ is in the house! 🐶🐾🫂🎶🎶🎶 nostr:note14czclgk2uxm8s8a8wkxyvq06t4t7czff6gezgheanv6pnn0je54scwj9d5

Boycott!😂

Thank you. I implemented my own already. I just wonder who else is joining the party.

Happy to collaborate - or at least make sure it’s compatible.

Did you have a plan for invoice generation? Generate new invoice per 402/Content? I’d like to support ZAPs and be non-custodial ideally. I thought about supporting inbound webhook a from users local lightning nodes - basically they forward payment success messages which unlocks the content.

I have a concern around privacy - because you leak the pubkey - and ideally you’d only want to provide a pubkey if you’re paying or think you’ve paid.

I’ve written two basic example rust projects that I’ll try open source this week.

1. BTCPay server webhook that can update a database on invoice payment.

2. Nostr 402 Payment Required paywall server that uses NIP-98 HTTP Auth after payment to authorise access. It likely can generate lightning invoices before payment too.

The basic idea is that if you ZAP or pay an invoice, the same URL can return the desired content if you sign a Nostr message that proves your private key which can be used to check prior payment.

Ideally we can support some kind of Nostr client app UX, where content can refresh post-payment.

It would be really nice if we had a way for select third parties to publish zap events for you without giving them your nsec key

1. If someone wants to put `Only-Zaps` into their client, and if their users want to turn it on, it's a free nostr.

2. I like likes. I'll continue to support them in more-speech, and continue to send them. It's a free nostr.

3. Bandwidth:

a. If every event causes Nl likes, then total bandwidth is E*(Nl+1). That could get high.

b. If every event causes Nz zap receipts, then total bandwidth is E*(Nz+1). Still high.

c. If Nz ~= Nl then there is no savings in throughput.

d. Zap receipts can be more expensive to process than likes. (e.g. more-speech does not signature check kind:7)

3. Bandwidth solutions: If we are really concerned about the bandwidth of kind:7 (likes), then we could invent some kind of piggyback scheme in which likes are held by the client and tacked on to the next outgoing note. e.g. a "likes" tag that takes an array of liked event ids. Clients could even limit these to once per hour or so. -- IF we were worried about bandwidth.

who wants to help me publish a google chrome extension today?

it's already written but using manifest version 2 and apparently google rugged people using manifest version 2 (as in, you cannot publish it...)

250k sat bounty that expires end of day 2023-04-19 UTC.

please repost for visibility

Do you know if it’s possible to side load an extension in chrome; I mean, distributing the extension and allowing people to easily install it without it, being published on the store

When I use my Alby ln address 0xtr@oxtr.dev, the site just goes blank and a very generic react-dom error is printed to the console. This also happens to alby lnurls. Seems to work just fine with both WoS ln addresses and lnurls however.

#[1] hmmm when I'm not on a nostr-tab, I can switch between Outgoing/Incoming but on the nostr-tab, there are only the outgoing transactions... that doesn't make sense to me

#[3]​ got it to work just fine with WoS LNURL and ln address so currently I’ve only had problems with #[4]​ ln address and lnurl. I’ll look more into this tomorrow and see if I can help out with a PR.

Also been meaning to ask if you were considering an option to “refill” Alby custodial balance with onchain sats? Could be a useful feature for the newbies.