Nostr Web Client

nostr:npub1h8nk2346qezka5cpm8jjh3yl5j88pf4ly2ptu7s6uu55wcfqy0wq36rpev

Once again I have to thank you.

This time for switching me on to ppq.ai in your ‘Welcome to Subscription Hell’ episode.

Honestly Dude, if I was the King of England, you’d be Sir Guy 🙏

Ppq.ai is the AI-lightning integration that I’ve been dreaming of (but better).

Privacy out of box, seamless integration with lightning, a stunning choice of AI models, intuitive UI, pay as you go, transparent and reasonable pricing …

This is the best use case for lightning since Nostr and really showcases this payment model. I am very fired up about where this is going to go. Next bull cycle starts now.

I’m not on Twitter, but please give my regards to Matt Ahlborg also. Great work!

Reply to this note

Please Login to reply.

Discussion

SatsAndSports 2w ago

I'm working on streaming micropayments, allowing many payments per second. It's basically a lightning channel, but using cashu instead of on-chain bitcoin

Lightning is great, but it doesn't work for tiny high-volume payments, like 1 sat per kilobyte of download or 1 sat per 1000 tokens, because of lightning fees and latency

Also, cashu - like Lightning - supports millisats which allows for tiny payments.

So you could connect to any service like this, such as a Nostr relay or ppq.ai or a Blossom server for media, set up a channel with 10000 sats and start making micropayments. You can end the session at any time, and the service can't steal the rest of the channel capacity. The service can exit with only the (milli)sats which you paid to it

I.e. both you and the service need to trust the mint, as is usual with cashu, but you and the service don't need to trust each other

https://njump.to/nevent1qqsdx58y6uwm27nevcwqqxv2daewffedn3pv56sy9xmr7mm2gdckuygpz9mhxue69uhkummnw3ezumrpdejz7q3qzthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnqxpqqqqqqzq0240c

semisol 2w ago

Why use Cashu, then? The service operator will most likely not trust any other mints and use exclusively their own as that is the only one that can be trusted.

Instead of having a fully custodial system in that case you could look into channels where wrongdoing could be proved, something like the now-dead spec for “hosted lightning channels”

SatsAndSports 2w ago

The service operator provides a list of mints that it trusts

"Fully custodial" doesn't really help when understanding cashu. While the mint can rug everybody yes, it is unable to rug *you* specifically, as it doesn't know who you are and it isn't able to link you to the server as it doesn't know who a given token was issued to

I don't know what you mean by "hosted lightning channel", I'll check it now. But without any link from you, I'll have to assume that it requires an onchain payment and therefore isn't practical when we might want to open channels to multiple servers every day and don't want to have to wait hours for confirmations

Feel free to implement that cashu-less alternative, I'd

semisol 2w ago

It does not need an onchain channel

It is basically a custodial protocol that allows *proving* wrongdoing with a scheme similar to LN channels

The problem is that the service operator won’t trust any mint other than their own, if they can

SatsAndSports 2w ago

How is that any better than cashu, from a risk-of-rug point of view?

The cashu folks are working on a proof of liabilities scheme to work alongside the obvious proof of reserves that mints could run (link below) . I haven't studied that yet, but I should and it might solve those problems

https://gist.github.com/callebtc/ed5228d1d8cbaade0104db5d1cf63939

SatsAndSports 2w ago

And it's not a problem if the service provider trusts only one mint. We just need one mint that is trusted by both parties, and the negotiation to find a trusted mint could be done automatically

semisol 2w ago

The probability of a common mint approaches zero with more users and more service providers.

With each service wanting self-custody, the user would have to approve every mint for every service one by one.

semisol 2w ago

PoL has been "coming" for a while now, and could have been implemented many times in the last 2.5 years it was proposed. I still have yet to see an implementation of it.

The problem with all of these systems in general is that they are inefficient after a few payments per day and unnecessarily complex to implement.

For a service, custodians are very hard to trust, and using Cashu or similar schemes have a lot of potential failure paths and edge cases that can be handled. And a service running their own mint would not want to offer withdrawals.

At that point, you may as well use a credit stored in a DB. There is a reason you see disposable account numbers everywhere and ecash based systems nowhere: It is pointless and a hassle for the average user and the service.

You can always create a new account number for each payment.

SatsAndSports 2w ago

"A service running their own mint would not want to offer withdrawals"

Maybe, but then why would anyone use that service?

"PoL has been coming for a while now"

Maybe. But so have its alternatives 😃.

What's your alternative, that works today?

"inefficient after a few payments per day"

Where did that come from? The channel I'm working on allows dozens of payments to be made per second, where the recipient can immediately verify the signature and, assuming the receiver trusts the mint, they can unilaterally exit at any time. Even without this channel, I don't see how cashu can only do "a few payments per day"

If we accept some rug risk, cashu appears to be great at optimising other things (privacy, ease of use, and speed)

If you can point to an existing scalable solution that has zero rug risk, that is easier to use - and to develop for - than Lightning, then I'd like to see it

I love Ark, it does a lot of things very well, but the privacy isn't great there