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. 

 At least directly with lightning, it’s not immediately obvious how you could reveal a key that only allowed you to spend up to some limit. The normal setup in lightning is your key can sign for the whole 2-of-2 channel balance. With pre-setup you could have some extra output on the commitment transaction and a new sub-channel that you could give the recipient control over, but you’d need to have that set up in advance for the exact amount you want to send (and it’d be a fairly complicated protocol extension for everyone to support). Probably just use ecash for the initial minute and then pay with lightning for further minutes after you’re online. 

 Yeah. Your point about spending limits is a very good one, maybe an interesting area for research. Not being able to spend specific chunks of your balance is a limitation (though the model of discrete denominations is also problematic, in other ways!). Didn't people try to address that with cosigning for onchain? Could we do that for LN? Have an agent that cosigns your channel updates with ecdsa 2pc or musig when we finally get taproot ln (umm nested musig blah blah).

The scenario that seems really difficult is: customer arrives in new town/region and needs Internet access at a 'tienda' (or bodega to use the US vernacular!).

I think nontech answers like fd0's : nostr:nevent1qqsfkm5vamze9mnqdpnuf6ykehegl8mc85d8p9dwe9yu48ls62d2cwgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrxsyng4nj8fr2p5n8uc8nyqphmjddmcdvhs2eajcglvn23ce6jmypsgqqqqqqsz5vzal

.. are more likely to be what is chosen; though i think physical cards representing LN funds is a nice idea too, just that spendinglimit problem to fix ... If we want people to pay with tokens to bootstrap, the unfortunate reality is they'll tend to use the tokens of the strongest mafia in their jurisdiction (that's what makes bitcoin a little bit magical, it isn't a token ultimately redeemable with some authority). 

 Yea, you can do multisig channels (indeed nested musig) for lightning (well, 66%+1, not 50%+1, sadly), but you’re still doing the “I communicate with some third party over your internet before I pay you for it”.

But, yeah just giving people a tiny bit of internet works fine mostly. Even airplane WiFi with credit cards lets you access DNS before you buy…