Have considered it since nostr apps have been slow to update to CLINK

I think we can add an adapter in the Linked Apps screen, will look more into it

Nice, that overlaps nicely with some of my disdain for L402... http introduces domains/ssl/reverse proxies etc and that's a big friction with p2p markets: https://stacker.news/items/1435085/r/justin_shocknet?commentId=1435245

I think some of the concerns you raise boil down more directly to credit vs. Lightning, Cashu just being an implementation of credit. CLINK (and the Lightning.Pub reference server for it) can also be used for credit since it can be used in reverse (for debits).

When using Lightning you're right that there's latency that would make sub-second exchanges impractical without direct peering. CLINK is better at this than Bolt12 since it's not using onion messages that add a slow and fragile round trip, but still the payment itself unless directly channel peered will often exceed the desired time and fee threshold.

The Cashu tokens may be claimable in a disconnect, but if the issuing is offline they're also worthless, so it's not really solving anything. If the service or client goes offline with CLINK, it's literally just request response, no different than an REST API... the receiver would fail to sweep or the sender would fail to emit the referenced transaction. Nothing in limbo.

In your scenario I'd do a hybrid approach with CLINK, a minutes worth of credit with the service which debits a local account per-second, and then the customer can either top-up that credit every minute OR the service sends a debit request to the payer to complete or deny every minute based on the prior minutes debits meeting their criteria.

Correct that L402 is retarded, it's a sheepish meme because of an abandoned HTTP status code

But Cashu is just as sheepish, Nostr as a Lightning transport doesn't need shitcoins

https://CLINKme.dev

I see you're still aiding the communist NGO's and confusing their takes with your own.

Hercules

> lot of testing work that happens on Core

It can be done on another repo that doesn't usurp the legacy, but would also need less testing if it didn't churn as much as a frivolous app... Bitcoin's value is derived from it being stable and resistant to change.

> compartmentalize

Indeed, it'd be better if Bitcoin was looked at as distributions moreso than implementations. Libbitcoin is an effort to make it libraries, HORNET, and at least one other I scrolled by recently... also BTCD is a great example of a stable alt-implementation that powers a ton of nodes, but as a library, via LND.

> Knots

Unfortunately controlled opposition that's making a clown show of otherwise justified Core resentment

> avoid chain splits

A default distribution in Core is actually a bigger risk, most updates are downloaded blind. This presents a risk of widely distributing a bad version that splits with older versions. With more diversified distributions, the impact of a bad update/alt would be small... more frequent issues with individual, less severe as they'd be irrelevant to the broader network... like a controlled burn.

Core exists at this point only to turn Bitcoin into a Politburo that can be captured by the Courtier

There's zero excuse for there to still be a "default" repo in Bitcoin that undiscerning people turn to on account of its legacy

The only Pro-Bitcoiner move the Core repo can make is to archive itself and force the uninitiated to actively choose a distribution #ArchiveCore

That's the Core position, Loops bip has overwhelming support and dissent is banned or shadow edited