The most frustrating thing about Lightning is that, no matter how well I set things up, a payment fails if the counterparty’s side is misconfigured. The second annoyance is that when a payment fails, it’s hard to tell right away whether the problem is on my side or the other party’s. A better solution is needed.

In the past, while building a Nostr-related app, I realized that Nostr's pub-sub model lets you act as a server without needing a domain or a fixed IP — and I thought that was incredibly useful.
Around the same time, looking at Lightning Address, I thought it was kind of lackluster, but figured it was unavoidable if you wanted a fixed receiving handle.
Then not long ago I finally saw CLINK. Why didn't I think of that?!

I think I’ll get fired at work this year. Being a developer doesn’t seem to suit me, so I’m considering doing manual labor.

I’m wondering whether there is a “pay‑to‑read” service on Nostr. On many platforms, if I click a link to read an article, I’m immediately prompted to log in, so I just close the page. A micro‑payment system could be a better solution for that.

Legacy social networks don’t have built‑in payment features, so it seems impossible there, but with Zap and Lightning becoming common on Nostr, it should be feasible, right?

Would it be difficult to implement the part that receives the payment and distributes it? I haven’t thought about it deeply yet. In my usage pattern, when I click a link to a long‑form article that interests me on Nostr, I’d probably be fine with a small payment request. Nostr makes it possible with a single click.