I do need enough to meet the minimum requirements for channels, practically speaking that’s probably 100k sats per channel. I am open to the idea of permissioned public testing networks, where I pay for “cycles” in the form of coins.

No chance to get a larger amount in my experience (except you contact the maintainers I guess).

Mutinynet has a great faucet, but you need a fork of core.

Please lmk if you find a more reliable sbtc source than those two horrible faucets😆

It’s kinda funny that there’s now legal betting on US election outcomes on CFTC-regulated markets through brokerage accounts but you can’t place the same bets at a casino.

It’s a desktop app for decentralized GitHub on Nostr. The amount of data is non-trivial in size (sometimes). Repos can be large. This is why we’re using merkle tree chunking for large files as well. I want the reduced RTT.

TFO*

The first point is that when I said "technically you don't" I meant that even if it seems crazy, there is no rule that says you *couldn't* implement systems where say you had a LN channel from earlier setup and you logged in with credentials that convert to a signing key.

Consider credit cards; the earliest security model which still exists, is magstripe and it's 100% insecure in the sense that you must trust the vendor's terminal not to skim your private data. The most recent version of this tech signs from a chip as well as using a PIN. While we have nothing like this for LN usage, I'd have to ask: is there a reason it couldn't work? I mentioned bolt cards, that's a step in that direction.

One reason that the credit card (old, insecure) model is more uncomfortable here is because LN is a self-custodial and privacy focused tech, i.e. more cash and not account/custodial; that's more autonomy but harder for resource-limited users, right.

The nicer thing about ecash based systems is the interop with LN so that you can have money passed between mints but that could end up quite complex/fragile (and arguably worse trust model than single mint!), while the more easily imagined case: merchant and customer use the same mint, means that you're back to the limitations that you'd have if some channel or channel topology had to be pre-existent beforehand (possible of course, but more limited than we'd like to imagine). With both a trust requirement, *and* "topology"/"coordination" requirement, I believe an awful lot of very clever setups could be made to work. Though I suspect an ecash mint would beat them all in terms of privacy model, that's where it shines. Doubt that the targeted users would prioritize that, though.

Second is right for sure. My point was that ecash is already custodial. You realistically have to have an account with someone, with LN technically you don't, and there are variations on the basic idea. People have come up with several somewhat offline, somewhat trustless LN payment methods, right. Like bolt cards etc.

Note that QUIC is useful on the web for helping to and the multi-connection/head-of-line blocking problem. But if you aren’t fetching a bunch of resources from the same server across different streams where you can use each resource individually on its own this doesn’t apply (and it requires integration work to make it apply).

TLS’ only issues aren’t just CAs being a mess, it’s also an anachronistic protocol that just isn’t how you’d design something today. 1.3 is better, sure, but it carries tons of legacy garbage and most clients still have fallbacks and logic for it.

I also dislike QUIC for being a lazy, poor version of TCP. Middleboxes suck sometimes but sometimes do useful things (eg on a plane TCP is terminated before it goes to the sat, improving latency and throughput compared to UDP things with retransmissions, middleboxes can use MSS clamping to avoid fragmentation, etc). QUIC largely failed to consider these things and just said “screw all middleboxes” (compare to eg tcpinc which got similar encryption properties without being lazy). QUIC exists to rebuild TCP in user-space cause kernels sometimes suck, but for those of us with an operating system newer than five years old that’s not a problem we have. Worse, sometimes your OS has specific useful features (eg MP-TCP) that you don’t want twenty apps to have to rewrite. FFS this is literally the point of having an OS! The only promise QUIC made that isn’t as trivial in TCP is FEC, but they gave up on it cause…I dunno why.

You could theoretically tailor TCP + TFO + Noise to achieve 1 RTT, but that sounds like a headache to implement. If any pre-made libraries are available with that setup, drop a link! 🔗

While it’s true that QUIC’s 0-RTT mode isn’t widely used due to replay attack risks, libp2p QUIC achieves 1 RTT with encryption, which is still faster than typical WebSockets over TLS (3 RTT).

What’s neat is that libp2p exchanges peer IDs during the QUIC handshake, meaning MITM attacks are mitigated if you’ve already retrieved the relay’s key from a trusted profile.

Why do you dislike QUIC/TLS so much if it’s free of CAs? How does it compare to TCP+TFO+Noise?

Right, i imagine them accessing an account on it with their pwd, credential.

On a terminal/screen the vendor controls?

The web client shouldn’t be fetching the invoice, it just passes the whole offer on to the wallet and asks it to pay. When the wallet completes it does a callback to the initiating app.

I don’t see how web clients could fetch offer invoices though, would have to use lnsocket/lnmessage and websocket proxies. With lnurl it’s much easier for web apps to fetch invoices.

Yep, came back after rereading to correct my mis-assumption.

Nonce could be implied or explicit here. You could use URL itself (or its hash) but good luck with canonicalizationissues :(

Not entirely sure *payer* proof is required here, but it's good practice.

I tried to make zaps a bolt12 thing at the start but I couldn’t figure this part out

This is for refunds? I think that's a different case, and should be baked into offers explicitly. Payer proofs are generally for blame and bragging...

I'm saying that the payer has internet access at that moment via the payee. With credit cards there's still a network access, just a private network.